Virtual Private Networks

What Problems do VPNs Solve ?

Historically a multi-site organisation requiring an in-house network leased some lines for their own exclusive use from a telecommunications provider. However, this was expensive and inflexible. This approach did not allow for network usage e.g. for travelling salesmen or for employees to work from home. Enabling home and travelling workers to connect into a company network from public networks is potentially less secure than if the company network including its security perimeter can be extended outwards to include all its insiders, wherever these individuals are located.

Being able to tunnel connections securely over the Internet is obviously a lot cheaper than using dedicated telecommunications capacity, as the cost of the physical network connections can be shared with other users.

Those needing to work securely over the Internet when located in countries where competitors or authorities in non-democratic states might monitor connections will want to keep their Internet activities from being eavesdropped.

Even for an individual, it is possible to have a secure VPN server hosted in a country with more favourable privacy laws and practices than the country in which the individual is residing, and to create a VPN connection on the computer in use so that all Internet traffic is secured between the individual and the hosted server, and appears, from the perspective of other hosts on the Internet, to originate or terminate at the hosted server. Using virtual machine technology the extra degree of privacy obtained by this means need not cost an individual any more than a high-end mobile- phone contract.

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 not Solve ?

  1. Weaknesses in the VPN implementation or configuration might give a false sense of security. More care might be exercised if no VPN were used. Having a VPN which isn't secure and thinking it is secure is probably worse than having no VPN.
  2. Authorities might have a legitimate right to search for and seize computing equipment and view files on disk, sent and received email messages and browser caches, e.g. if warranted, and in undemocratic countries the police or customs might get a warrant to do this after the seizure rather than before. If the filesystem is encrypted, not providing the encryption keys might be a criminal offence.
  3. Traffic analysis might be capable of obtaining information about conversations occuring even though the contents of the conversations are not decrypted. This can only be defeated by padding all conversational VPN packets to the same size and ensuring null packets are interspersed with real ones to hide the wheat amongst the chaff.
  4. All computer equipment radiates electromagnetic, electrostatic and power-line radiation while in use. Some of this radiation can disclose data to a very well-resourced attacker.
  5. If a VPN connected computer is used in a room bugged with secret microphones or cameras, information about keypresses or from the computer screen might be observable remotely through well-known surveillance techniques.
  6. A VPN may be routed through an over-restrictive firewall, e.g. to provide for network connectivity believed to be required by an organisation insider but restricted by that organisations' firewall policy. This VPN will reduce security by making the firewall policy ineffective.

VPN Principles of Operation

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 conceptually similar to the idea of 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 origin.

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.

VPN Technology 1: Microsoft's PPTP implementation

PPTN stands for Point to Point Tunneling Protocol

[3] states:

Cisco first implemented PPTP and later licensed the technology to Microsoft.

PPTP is popular because it is easy to configure and it was the first VPN protocol that was supported by Microsoft Dial-up Networking. All releases of Microsoft Windows since Windows 95 OSR2 are bundled with a PPTP client. The Routing And Remote Access Service for Microsoft Windows contains a PPTP server.

Until recently, Linux distributions lacked full PPTP support because MPPE was believed to be patent encumbered. Full MPPE support was added to the Linux 2.6.13 branch that is maintained by Andrew Morton. SuSE Linux 10 was the first Linux distribution to provide a complete working PPTP client. Official support for PPTP was added to the official kernel release in version 2.6.14 on October 28, 2005.

Mac OS X is bundled with a PPTP client. Cisco and Efficient Networks sell PPTP clients for older Mac OS releases. Palm PDA devices with Wi-Fi are bundled with the Mergic PPTP client.

Microsoft Windows Mobile 2003 and higher also support the PPTP protocol.

The upgrade path for PPTP on Microsoft platforms will be to either L2TP/IPsec or IPsec. The adoption of improved VPN technologies has been slow because PPTP is convenient and easy to configure, whereas L2TP/IPsec requires a shared key or machine certificates.

PPTN is considered to be very insecure [4].

VPN Technology 2: IPsec (Internet Protocol SECurity)

IPsec is an important VPN technology because of the amount of investment directed towards its standardisation, and because of its widespread support. IPsec is an integral part of the next generation Internet, IP Version 6. However, most current implementation work is to do with the use of IPsec together with the current Internet Protocol, IP version 4. As a security protocol integral with the IP network layer, this also allows for higher-performance kernel-based implementations, as an integral part of the OS networking stack.

Useful starting points on IPSec include Steve Friedl's Illustrated Guide to IPsec and the Wikipedia IPsec entry.

Whilst being very widely supported IPsec is also criticized due to its complexity [1].

VPN Technology 3: OpenVPN

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 and higher), Solaris, Open, Free and NetBSD and Mac OS X. A PocketPC port is being developed.

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).

As it is provided as a seperate userspace program, as opposed to requiring OS kernel modification, this allows for greater flexibility in use - arguably for a cost in performance.

It is believed to interwork more flexibly than IPsec through existing firewalls, as all traffic is tunneled over a UDP port, 1194 by default, though other tunneling settings are possible. Those controlling a firewall can decide whether to forward UDP port 1194 to a VPN host or not.

UDP datagrams are considered to be better matched for the purpose of IP packet tunneling than using a TCP connection, as 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 unneccessary packet correction and sequence reassembly overhead being duplicated, and 2 rate adaptations fighting each other.

Setting Up and Using an OpenVPN Connection

Preparation

The easiest way to do this 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 a floppy disk, or using the sftp protocol (WinSCP will transfer files to and from a ssh server on Linux using the SFTP secure file transfer protocol, which uses the same SSL/TLS cryptography layer as OpenVPN).

On (Debian or Ubuntu) Linux install OpenVPN:

apt-get install openvpn

A Windows version very similar to the Linux is downloadable, and a Windows GUI version is also available.

To generate a key and store this in ascii 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 1174 is forwarded to the computer on the firewall:

OpenVPN Firewall configuration screenshot

Experimental use of OpenVPN is possible 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 .

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 securely over the VPN

The test chosen was to use the mail relay on copsewood.net to send an outgoing email, using a telnet client session from letsystem.org . (Addresses below changed to reduce spam).

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: richh@copssewood.net
250 2.1.0 richh@copssewood.net... Sender ok
rcpt to: richar.kay@ticc.ac.uk
550 5.7.1 richar.kay@ticc.ac.uk... 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:

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: rich@copssewood.net
250 2.1.0 rich@copssewood.net... Sender ok
rcpt to: richar.kay@ticc.ac.uk
250 2.1.5 richar.kay@ticc.ac.uk... 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

Proof the message got through

screenshot of arrived email

Recommended Reading