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.
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.
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.
A digital signing scheme is typically used to enable verification of the VPN origin.
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.
PPTN stands for Point to Point Tunneling Protocol
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 .
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 .
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.
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:
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 .
openvpn --remote letsystem.org --dev tun1 --ifconfig 10.4.0.2 10.4.0.1 --secret vpnkey &
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
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 .
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: 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 :
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: 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