VPN Principles of operation: tunneling, encapsulation, encryption and authentication
VPN Technologies: Microsoft PPTP, IPsec, OpenVPN
Installing, configuring and testing an OpenVPN point to point connection
History and background of VPNs 1 Pre-Internet multi-site organisations operated private networks using leased lines. This approach was expensive and inflexible. It didn't extend company network boundaries to travelling representatives etc. Possible to dial in using modem banks, dial back gave some authentication. It became cheaper to use shared Internet than dedicated and ad-hoc dialup connections. VPNs enabled more flexible use of larger networks by removing network geography constraints from shared-insider LAN/Intranet associations and services. With cryptography as part of a VPN, a travelling saleseman could communicate with head office at lower risk from spying competitors etc.
History and background of VPNs 2 Even individuals with access to servers abroad can benefit from the security provided by VPN technologies, e.g. in connection with oppressive laws and state monitoring etc. Cost of a virtual server is similar to a high-end mobile phone contract. From the point of view of anyone monitoring a VPN connection, all network traffic to or from the client appears to originate from and terminate with the VPN server. VPNs may also be used to provide a secure overlay over other networks, e.g. a community WiFi network which relies on hardware which is outdated and does not support recent and secure WiFi WPA2 security protocols.
What problems do VPNs solve ?
Avoiding costs of fixed lines.
Extending security context of LAN across sites, regardless of geography, including to mobile users.
Authentication: knowing who your users are.
Encryption: preventing monitoring of use of insecure client server applications at the network level.
What security problems do VPNs not solve ?
Having a VPN which isn't secure and not knowing this is probably worse than having no VPN
Arrest and seizure of equipment. Cryptography is illegal in some countries.
Traffic analysis: monitoring of packet sizes, network usage times, endpoints of conversation etc.
Electromagnetic, video and audio surveillance where mobile equipment is used.
VPNs can be used to pierce firewalls, by encapsulating traffic prohibited by organisation policy within a firewalled perimeter which the firewall can't inspect or control.
Tunneling Typically a VPN consists of a set of point to point connections tunnelled over the Internet. The routers carrying this traffic over the Internet see each P2P connection externally as a sequence of packets routed between endpoints. Within the VPN each P2P connection is seen as an unrouted connection.
Encapsulation In order to achieve tunneling, the packets including payloads, to and from addresses, port numbers and other standard protocol packet headers are encapsulated as the payload of packets as seen by the external routers carrying the connection. This is similar conceptually to a stamped and addressed conventional mail envelope being placed inside another with more expensive postage and a different address. Packet headers seen externally will carry the addresses of the VPN endpoints and the port numbers used by the VPN client and server software.
Authentication A digital signing scheme is typically used to enable verification of the VPN principals. Note that both the client and the server need to authenticate each other. Message authentication codes, hashes or checksums are typically used to authenticate message contents.
Encryption To protect the privacy of the connection from external snooping, the payload of the packets visible externally will be encrypted. To enable routing over conventional networks, the packet headers of the encapsulating packets are not encrypted, but the packet headers of the encapsulated packets are encrypted along with their contents.
Microsoft's PPTP implementation
PPTP: Point to Point Tunneling Protocol
Popular and easy to configure, first VPN protocol that was supported by Microsoft Dial-up Networking.
Developed by Cisco, adopted by MS with Win95, and later versions of Windows, Linux >= 2.6.13, Macintosh, PalmOS etc.
MS PPTP is considered very insecure, see http://www.schneier.com/pptp-faq.html and http://www.schneier.com/paper-pptpv2.html
Replaced by L2TP/IPsec (Layer 2 Tunnelling Protocol/ Internet Protocol SECurity)
IPsec (Internet Protocol SECurity) 1 Important VPN technology because of the amount of investment directed towards IETF standardisation, and widespread support. Integral part of IPV6. However, most current implementation work is to do with the use of IPsec together with IPV4. As a security protocol integral with the IP network layer, it allows for high-performance kernel-based implementations compared to user-space VPNs.
Useful starting points on IPsec Steve Friedl's Illustrated Guide to IPsec: http://www.unixwiz.net/techtips/iguide-ipsec.html The Wikipedia IPsec entry: http://en.wikipedia.org/wiki/IPSec While being very widely supported, IPsec is also criticized due to its complexity, see: http://www.schneier.com/paper-ipsec.html
OpenVPN 1 OpenVPN is the name given to a program which implements a straightforward, simple and very effective approach to building VPNs. The OpenVPN program is developed on Linux, and has also been ported to Windows (2000/XP/Vista), Solaris, BSD (Open/Free/Net) and Mac OS X. OpenVPN is licensed under the GNU Public License, enabling any company or organisation to support and develop it. This also enables cryptographic review. OpenVPN is believed to be very secure as it uses the same cryptography as HTTPS, SSL/TLS (Secure Socket Layer and Transport Layer Security).
OpenVPN 2 As it is provided as a seperate userspace program, as opposed to within the OS kernel networking stack, this allows for greater flexibility in use - arguably for a cost in performance. OpenVPN interwork more flexibly than IPsec through existing firewalls, as all traffic is tunneled over a UDP port, 1194 by default, with other tunneling settings possible. Those controlling a firewall can decide whether to forward UDP port 1194 to a VPN host or not.
OpenVPN 3 UDP datagrams are considered better matched for the purpose of IP packet tunneling than using a TCP connection. This is because the use of TCP for a within VPN application would result in a TCP inner connection being encapsulated over a TCP outer connection, which would result in duplicated packet correction and sequence reassembly, and 2 rate adaptations fighting each other.
Configuring and using OpenVPN 1 On (Debian or Ubuntu) Linux install OpenVPN: aptitude install openvpn A Windows version very similar to the Linux one is downloadable: http://www.openvpn.net/ A Windows GUI version is also available: http://openvpn.se/
Configuring and using OpenVPN 2 The easiest way to secure the OpenVPN connection involves using a shared encryption key. This can be generated at one end of the connection and then transferred to the other using a secure channel, e.g. using physical media, or the SFTP protocol. WinSCP can transfer files to and from a SSH server on Linux using SFTP, which uses the same SSL/TLS cryptography layer as OpenVPN. A more scalable approach involving public/private keypairs and certificates might be used for more complex multi-host VPNs.
Configuring and using OpenVPN 3 To generate a key and store this in text file vpnkey: openvpn --genkey --secret vpnkey This key then has to be transferred securely to the computer to act as the other gateway or endpoint. The 2 computers need to be able to talk to each other over the Internet. If both are on dynamic addresses, or behind NAT firewalls, ensure that UDP port 1194 is forwarded to the computer on the firewall.
Configuring and using OpenVPN 4
Configuring and using OpenVPN 5 Experimental use of OpenVPN between computers using dynamic IP addresses is possible, but the connection will drop whenever an IP address changes. To solve this problem you are recommended to use one of the free dynamic DNS servers, or to run your own DNS server and have a domain point at each dynamically addressed computer and update the DNS record whenever the computer address changes. In the notes below I've used 2 domains: copsewood.net and letsystem.org for the endpoints.
Establishing the tunnel On copsewood.net: openvpn --remote letsystem.org --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --secret vpnkey & On letsystem.org: openvpn --remote copsewood.net --dev tun1 --ifconfig 10.4.0.1 10.4.0.2 --secret vpnkey &
Testing the tunnel root@saturn:/root# ping 10.4.0.1 PING 10.4.0.1 (10.4.0.1) 56(84) bytes of data. 64 bytes from 10.4.0.1: icmp_seq=1 ttl=64 time=0.043 ms 64 bytes from 10.4.0.1: icmp_seq=2 ttl=64 time=0.036 ms 64 bytes from 10.4.0.1: icmp_seq=3 ttl=64 time=0.036 ms --- 10.4.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 1998ms rtt min/avg/max/mdev = 0.036/0.038/0.043/0.006 ms root@saturn:/root# ping 10.4.0.2 PING 10.4.0.2 (10.4.0.2) 56(84) bytes of data. 64 bytes from 10.4.0.2: icmp_seq=1 ttl=64 time=36.2 ms 64 bytes from 10.4.0.2: icmp_seq=2 ttl=64 time=24.4 ms 64 bytes from 10.4.0.2: icmp_seq=3 ttl=64 time=26.6 ms 64 bytes from 10.4.0.2: icmp_seq=4 ttl=64 time=26.2 ms --- 10.4.0.2 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 24.429/28.391/36.247/4.612 ms
Setting up Routing On letsystem.org: echo 1 > /proc/sys/net/ipv4/ip_forward This allows letsystem.org to act as a router to its local network ( 192.168.1.0/24 ). On copsewood.net: route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.4.0.1 This sets up a route from copsewood.net to hosts on network 192.168.1.0/24
Using an application over the VPN 1 root@saturn:/root# telnet 10.4.0.2 25 Trying 10.4.0.2... Connected to 10.4.0.2. Escape character is '^]'. 220 copsewood.net ESMTP Sendmail 8.13.4/8.13.4/Debian-3sarge3; Fri, 12 Jan 2007 16:02:39 GMT; (No UCE/UBE) logging access from: [10.4.0.1](FAIL)-[10.4.0.1] HELO saturn 250 copsewood.net Hello [10.4.0.1], pleased to meet you mail from: email@example.com 250 2.1.0 firstname.lastname@example.org... Sender ok rcpt to: email@example.com 550 5.7.1 firstname.lastname@example.org... Relaying denied. IP name lookup failed [10.4.0.1] Sendmail wasn't happy about using an IP address that didn't lookup to a hostname. So I added a line to /etc/hosts on copsewood.net : letsystem.org 10.4.0.1 and tried again :
Using an application over the VPN 2 root@saturn:/root# telnet 10.4.0.2 25 Trying 10.4.0.2... Connected to 10.4.0.2. Escape character is '^]'. 220 copsewood.net ESMTP Sendmail 8.13.4/8.13.4/Debian-3sarge3; Fri, 12 Jan 2007 16:13:15 GMT; (No UCE/UBE) logging access from: letsystem.org(OK)-letsystem.org [10.4.0.1] HELO saturn 250 copsewood.net Hello letsystem.org [10.4.0.1], pleased to meet you mail from: email@example.com 250 2.1.0 firstname.lastname@example.org... Sender ok rcpt to: email@example.com 250 2.1.5 firstname.lastname@example.org... Recipient ok data 354 Enter mail, end with "." on a line by itself Subject: test using VPN for mail submission VPN . 250 2.0.0 l0CGDFx3019922 Message accepted for delivery quit