The network-manager-openvpn-gnome package contains an extension to Network Manager (see Section 8.2.4, “Automatic Network Configuration for Roaming Users”) that allows managing OpenVPN virtual private networks. This allows every user to configure OpenVPN connections graphically and to control them from the network management icon.
10.2.2. Virtual Private Network with SSH
There are actually two ways of creating a virtual private network with SSH. The historic one involves establishing a PPP layer over the SSH link. This method is described in a HOWTO document:
→ http://www.tldp.org/HOWTO/ppp-ssh/
The second method is more recent, and was introduced with OpenSSH 4.3; it is now possible for OpenSSH to create virtual network interfaces (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).
Both methods for creating a virtual private network over SSH are quite straightforward. However, the VPN they provide is not the most efficient available; in particular, it does not handle high levels traffic very well.
The explanation is that when a TCP/IP stack is encapsulated within a TCP/IP connection (for SSH), the TCP protocol is used two times, once for the SSH connection and once within the tunnel. This leads to problems, especially due to the way TCP adapts to network conditions by altering timeout delays. The following site describes the problem in more detaiclass="underline"
→ http://sites.inka.de/sites/bigred/devel/tcp-tcp.html
VPNs over SSH should therefore be restricted to one-off tunnels with no performance constraints.
10.2.3. IPsec
IPsec, despite being the standard in IP VPNs, is rather more involved in its implementation. The IPsec engine itself is integrated in the Linux kernel; the required user-space parts, the control and configuration tools, are provided by the ipsec-tools package. In concrete terms, each host's /etc/ipsec-tools.conf contains the parameters for IPsec tunnels (or Security Associations, in the IPsec terminology) that the host is concerned with; /etc/init.d/setkey script provides a way to start and stop a tunnel (each tunnel is a secure link to another host connected to the virtual private network). This file can be built by hand from the documentation provided by the setkey(8) manual page. However, explicitly writing the parameters for all hosts in a non-trivial set of machines quickly becomes an arduous task, since the number of tunnels grows fast. Installing an IKE daemon (for IPsec Key Exchange) such as racoon, strongswan or openswan makes the process much simpler by bringing administration together at a central point, and more secure by rotating the keys periodically.
In spite of its status as the reference, the complexity of setting up IPsec restricts its usage in practice. OpenVPN-based solutions will generally be preferred when the required tunnels are neither too many nor too dynamic.
CAUTION IPsec and NAT
NATing firewalls and IPsec do not work well together: since IPsec signs the packets, any change on these packets that the firewall might perform will void the signature, and the packets will be rejected at their destination. Various IPsec implementations now include the NAT-T technique (for NAT Traversal), which basically encapsulates the IPsec packet within a standard UDP packet.
SECURITY IPsec and firewalls
The standard mode of operation of IPsec involves data exchanges on UDP port 500 for key exchanges (also on UDP port 4500 if case NAT-T is in use). Moreover, IPsec packets use two dedicated IP protocols that the firewall must let through; reception of these packets is based on their protocol numbers, 50 (ESP) and 51 (AH).
10.2.4. PPTP
PPTP (for Point-to-Point Tunneling Protocol) uses two communication channels, one for control data and one for payload data; the latter uses the GRE protocol (Generic Routing Encapsulation). A standard PPP link is then set up over the data exchange channel.
10.2.4.1. Configuring the Client
The pptp-linux package contains an easily-configured PPTP client for Linux. The following instructions take their inspiration from the official documentation:
→ http://pptpclient.sourceforge.net/howto-debian.phtml
The Falcot administrators created several files: /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
Example 10.4. The /etc/ppp/ip-up.d/falcot file
# Create the route to the Falcot network
if [ "$6" = "falcot" ]; then
# 192.168.0.0/24 is the (remote) Falcot network
route add -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi
Example 10.5. The /etc/ppp/ip-down.d/falcot file
# Delete the route to the Falcot network
if [ "$6" = "falcot" ]; then
# 192.168.0.0/24 is the (remote) Falcot network
route del -net 192.168.0.0 netmask 255.255.255.0 dev $1
fi
SECURITY MPPE
Securing PPTP involves using the MPPE feature (Microsoft Point-to-Point Encryption), which is available in official Debian kernels as a module.
10.2.4.2. Configuring the Server
CAUTION PPTP and firewalls
Intermediate firewalls need to be configured to let through IP packets using protocol 47 (GRE). Moreover, the PPTP server's port 1723 needs to be open so that the communication channel can happen.
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.