tun
(for IP-level tunnels) and tap
(for Ethernet-level tunnels) interfaces are supported. In practice, tun
interfaces will most often be used except when the VPN clients are meant to be integrated into the server's local network by way of an Ethernet bridge.
pki/ca.crt
) will be stored on all machines (both server and clients) as /etc/ssl/certs/Falcot_CA.crt
. The server's certificate is installed only on the server (pki/issued/vpn.falcot.com.crt
goes to /etc/ssl/certs/vpn.falcot.com.crt
, and pki/private/vpn.falcot.com.key
goes to /etc/ssl/private/vpn.falcot.com.key
with restricted permissions so that only the administrator can read it), with the corresponding Diffie-Hellman parameters (pki/dh.pem
) installed to /etc/openvpn/dh.pem
. Client certificates are installed on the corresponding VPN client in a similar fashion.
/etc/openvpn/*.conf
. Setting up a VPN server is therefore a matter of storing a corresponding configuration file in this directory. A good starting point is /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz
, which leads to a rather standard server. Of course, some parameters need to be adapted: ca
, cert
, key
and dh
need to describe the selected locations (respectively, /etc/ssl/certs/Falcot_CA.crt
, /etc/ssl/vpn.falcot.com.crt
, /etc/ssl/private/vpn.falcot.com.key
and /etc/openvpn/dh.pem
). The server 10.8.0.0 255.255.255.0
directive defines the subnet to be used by the VPN; the server uses the first IP address in that range (10.8.0.1
) and the rest of the addresses are allocated to clients.
tun0
name. However, firewalls are often configured at the same time as the real network interfaces, which happens before OpenVPN starts. Good practice therefore recommends creating a persistent virtual network interface, and configuring OpenVPN to use this pre-existing interface. This further allows choosing the name for this interface. To this end, openvpn --mktun --dev vpn --dev-type tun
creates a virtual network interface named vpn
with type tun
; this command can easily be integrated in the firewall configuration script, or in an up
directive of the /etc/network/interfaces
file, or a udev rule can be added to that end. The OpenVPN configuration file must also be updated accordingly, with the dev vpn
and dev-type tun
directives.
10.8.0.1
address. Granting the clients access to the local network (192.168.0.0/24), requires adding a push route 192.168.0.0 255.255.255.0
directive to the OpenVPN configuration so that VPN clients automatically get a network route telling them that this network is reachable by way of the VPN. Furthermore, machines on the local network also need to be informed that the route to the VPN goes through the VPN server (this automatically works when the VPN server is installed on the gateway). Alternatively, the VPN server can be configured to perform IP masquerading so that connections coming from VPN clients appear as if they are coming from the VPN server instead (see Section 10.1, “Gateway”).
/etc/openvpn/
. A standard configuration can be obtained by using /usr/share/doc/openvpn/examples/sample-config-files/client.conf
as a starting point. The remote vpn.falcot.com 1194
directive describes the address and port of the OpenVPN server; the ca
, cert
and key
also need to be adapted to describe the locations of the key files.
AUTOSTART
directive to none
in the /etc/default/openvpn
file. Starting or stopping a given VPN connection is always possible with the commands systemctl start openvpn@name
and systemctl stop openvpn@name
(where the connection name matches the one defined in /etc/openvpn/name.conf
).
tun*
) on both sides of an SSH connection, and these virtual interfaces can be configured exactly as if they were physical interfaces. The tunneling system must first be enabled by setting PermitTunnel
to “yes” in the SSH server configuration file (/etc/ssh/sshd_config
). When establishing the SSH connection, the creation of a tunnel must be explicitly requested with the -w any:any
option (any
can be replaced with the desired tun
device number). This requires the user to have administrator privilege on both sides, so as to be able to create the network device (in other words, the connection must be established as root).
/etc/ipsec.conf
contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with. There are many configuration examples in /usr/share/doc/libreswan/
, but Libreswan's online documentation has more examples with explanations:
systemctl
; for example, systemctl start ipsec
will start the IPsec service.
/etc/ppp/options.pptp
, /etc/ppp/peers/falcot
, /etc/ppp/ip-up.d/falcot
, and /etc/ppp/ip-down.d/falcot
.
Example 10.2. The /etc/ppp/options.pptp
file
# PPP options used for a PPTP connection lock noauth nobsdcomp nodeflate
Example 10.3. The /etc/ppp/peers/falcot
file
# vpn.falcot.com is the PPTP server pty "pptp vpn.falcot.com --nolaunchpppd" # the connection will identify as the "vpn" user user vpn remotename pptp # encryption is needed require-mppe-128 file /etc/ppp/options.pptp ipparam falcot
pptpd
is the PPTP server for Linux. Its main configuration file, /etc/pptpd.conf
, requires very few changes: localip (local IP address) and remoteip (remote IP address). In the example below, the PPTP server always uses the 192.168.0.199
address, and PPTP clients receive IP addresses from 192.168.0.200
to 192.168.0.250
.
Example 10.6. The /etc/pptpd.conf
file
# TAG: speed # # Specifies the speed for the PPP daemon to talk at. # speed 115200 # TAG: option # # Specifies the location of the PPP options file. # By default PPP looks in '/etc/ppp/options' # option /etc/ppp/pptpd-options # TAG: debug # # Turns on (more) debugging to syslog # # debug # TAG: localip # TAG: remoteip # # Specifies the local and remote IP address ranges. # # You can specify single IP addresses separated by commas or you can # specify ranges, or both. For example: # # 192.168.0.234,192.168.0.245-249,192.168.0.254 # # IMPORTANT RESTRICTIONS: # # 1. No spaces are permitted between commas or within addresses. # # 2. If you give more IP addresses than MAX_CONNECTIONS, it will # start at the beginning of the list and go until it gets # MAX_CONNECTIONS IPs. Others will be ignored. # # 3. No shortcuts in ranges! ie. 234-8 does not mean 234 to 238, # you must type 234-238 if you mean this. # # 4. If you give a single localIP, that's ok - all local IPs will # be set to the given one. You MUST still give at least one remote # IP for each simultaneous client. # #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 #localip 10.0.1.1 #remoteip 10.0.1.2-100 localip 192.168.0.199 remoteip 192.168.0.200-250
/etc/ppp/pptpd-options
. The important parameters are the server name (pptp
), the domain name (falcot.com
), and the IP addresses for DNS and WINS servers.
Example 10.7. The /etc/ppp/pptpd-options
file
## turn pppd syslog debugging on #debug ## change 'servername' to whatever you specify as your server name in chap-secrets name pptp ## change the domainname to your local domain domain falcot.com ## these are reasonable defaults for WinXXXX clients ## for the security related settings # The Debian pppd package now supports both MSCHAP and MPPE, so enable them # here. Please note that the kernel support for MPPE must also be present! auth require-chap require-mschap require-mschap-v2 require-mppe-128 ## Fill in your addresses ms-dns 192.168.0.1 ms-wins 192.168.0.1 ## Fill in your netmask netmask 255.255.255.0 ## some defaults nodefaultroute proxyarp lock
vpn
user (and the associated password) in the /etc/ppp/chap-secrets
file. Contrary to other instances where an asterisk (*
) would work, the server name must be filled explicitly here. Furthermore, Windows PPTP clients identify themselves under the DOMAIN\\USER
form, instead of only providing a user name. This explains why the file also mentions the FALCOT\\vpn
user. It is also possible to specify individual IP addresses for users; an asterisk in this field specifies that dynamic addressing should be used.