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: localip # TAG: remoteip # Specifies the local and remote IP address ranges. # # These options are ignored if delegate option is set. # # Any addresses work as long as the local machine takes care of the # routing. But if you want to use MS-Windows networking, you should # use IP addresses out of the LAN address space and use the proxyarp # option in the pppd options file, or run bcrelay. # # You can specify single IP addresses seperated 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 the value of connections, # it will start at the beginning of the list and go until it # gets 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. # # (Recommended) #localip 192.168.0.1 #remoteip 192.168.0.234-238,192.168.0.245 # or #localip 192.168.0.234-238,192.168.0.245 #remoteip 192.168.1.234-238,192.168.1.245 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
# Enable connection debugging facilities. # (see your syslog configuration for where pppd sends to) #debug # Name of the local system for authentication purposes # (must match the second field in /etc/ppp/chap-secrets entries) name pptpd # Optional: domain name to use for authentication ## change the domainname to your local domain domain falcot.com # Authentication ## these are reasonable defaults for WinXXXX clients ## for the security related settings auth refuse-pap refuse-chap refuse-mschap # Require the peer to authenticate itself using MS-CHAPv2 [Microsoft # Challenge Handshake Authentication Protocol, Version 2] authentication. require-mschap-v2 # Require MPPE 128-bit encryption # (note that MPPE requires the use of MSCHAP-V2 during authentication) require-mppe-128 # Network and Routing ## 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.