VPN, or Virtual Private Network, technology is used to extend
private networks beyond the boundaries of their physical cabling – to securely
connect geographically separated networks using an unsecure medium, such as the
Internet. Today VPN technology is being increasingly used to allow workers to
connect to local network resources while away from the office. As I examined in
my post on virtualisation (http://blog.devicewire.com/blogs/devicewire/archive/2008/06/12/virtualisation-what-s-it-all-about.aspx),
the “stuff” that happens in the background to make this possible is transparent
to the user: the user enjoys the same experience whether they are in the office
or not.
Whilst this technology is not new, problems often arise when trying
to establish VPN connections from mobile devices, because of a lack of
understanding of what happens in the middle, between the user and the office.
In this article I will look more closely at this technical “stuff” –
the different means by which data can be intercepted, the mechanisms by which
data is secured, and common problems experienced, especially when establishing
VPN connections from mobile devices, and their solutions.
This subject is inherently technical in nature and ideally you
should have an understanding of the basic principles of TCP/IP. If you need a
quick refresher course, have a read of my earlier blog post, “How does TCP/IP
work?”, here:
http://blog.devicewire.com/blogs/devicewire/archive/2008/06/21/tcp-ip-an-introduction.aspx
Virtual Private Network technology makes it possible to securely
send data over an unsecured network. Data is encrypted at the source and sent
over the unsecure network, such as the Internet, and decrypted again at the
receiving end. Should any of the data be intercepted while in transit, it will
not be readable by any unintended recipient. This method of securely sending
data over an unsecure network is known as tunnelling.
Before I look at the components involved in a VPN connection and how
security is guaranteed, I will first look at the areas of concern a network
administrator faces when assessing the security of their network.
The need for security
Without security measures and controls in place, data may be subject
to “attack”. Some attacks can be “passive” (meaning that data is merely
monitored), others can be “active” (meaning that the data is deliberately
altered with intent to corrupt the data itself, or even attack the entire
target network). Attacks can take one of a number of forms:
·
Eavesdropping – the majority of network communications occur in an unsecured
manner, or in “cleartext”. Should an attacker gain access to the network, they
would be able to read any traffic crossing that network. This practice is
referred to as “sniffing” or “snooping”. This is the most common form of attack
and is the reason why encryption technology is being deployed even on small,
local networks.
·
Data Modification – once an attacker has gained access to a network, that person
would then be able not only to read data, but modify it in transit between
sender and receiver (increasing the quantity specified in an electronic
purchase, for example). This is also referred as a ‘man-in-the-middle attack’.
·
Identity / IP Address Spoofing – on an IP-based network, a computer is identified by its IP
address, and the resources that computer is permitted access to is based on its
IP address. Should an attacker be able to make their computer appear to have a
‘trusted’ IP address, it would be able to access any resources that a computer
genuinely possessing that address would be able to.
·
Password-based attacks – the password is the simplest form of authentication. Most systems
do not encrypt passwords as they are sent across the local network. Should an
eavesdropper gain access to a network they would be able to intercept password
information, and from that moment gain access to network resources as a trusted
user.
·
Denial-of-service attack – a DoS attack involves flooding the network with so much traffic
that it eventually crashes. The target of a DoS attack could equally be a
network, a single machine on that network, or even a specific service running
on that single machine.
Defence mechanisms
A VPN connection implements security in two ways – authentication
and encryption.
Authentication ensures that the data originates from the source
which it claims to come from.
Encryption prevents anyone from reading or copying data as it
travels across the network. Data encryption is used to protect data from
unauthorised users by encoding the content. For more information on how data is
encrypted, read my earlier blog post, “How do digital certificates work?” –
here:
http://blog.devicewire.com/blogs/devicewire/archive/2008/06/22/how-do-digital-certificates-work.aspx
VPN Infrastructure
There are 2 principle elements involved in a VPN connection. The
remote network deploys a VPN Server which acts as a gateway between the
internal network and the public Internet.
The remote user, or branch office, will have a VPN client which will
encrypt data sent to and decrypt data received from the VPN server. The client
may be a physical piece of hardware or a software application.
Typically the VPN server will be located behind a firewall in a
perimeter network. The ports that will need to be opened on the firewall will
vary depending on the VPN “tunnelling” protocol being used. The three most
common VPN protocols are:
·
PPTP (Point to
Point Tunnelling Protocol)
·
L2TP (Layer 2
Tunnelling Protocol)
·
IPSec (Internet
Protocol Security)
I will examine these protocols in more detail, but essentially they
work in the same way. TCP will split the data to be transmitted into individual
packets, consisting of a data payload and header
information, containing sequencing and error correction details. IP will then
add further information to the TCP packet containing addressing information of
both the sending and receiving machines.
The VPN protocol will take the TCP packet and add further
information to it. The entire packet is encrypted, making it unreadable to any
machine that does not have the decryption key. Further sequencing and error
correction data is added, and then the IP header is attached so that the VPN
packet can be routed across the network. Due to the large amount of additional
data that is added to the packet, VPN connections are correspondingly slower
than plaintext communications.
PPTP is the earliest of the three VPN protocols. It provides data
security by encrypting the contents of the packet, but it does not provide data
authentication by verifying the identity of the sender, nor does it verify the
integrity of the data to ensure that it has not been modified in transit, either
accidentally or deliberately.
L2TP addresses these weaknesses firstly by adding a message
digest to each packet to ensure that the data has not been modified in
transit. It also guarantees the identity of the sender by digitally signing
each packet with a certificate.
IPSec is the most commonly-used VPN protocol today and I will
examine this in more detail. IPSec works in a similar manner to L2TP in terms
of providing authentication and verification, but the strength of the
encryption mechanism used is stronger – asymmetric (or public key) encryption
being used.
Again, if you need a refresher on what terms like message digest and
public key encryption mean, then a good place to start would be here:
http://blog.devicewire.com/blogs/devicewire/archive/2008/06/22/how-do-digital-certificates-work.aspx
IPSec
Internet Protocol Security (IPSec), is an end-to-end protocol,
meaning that only the sending and receiving systems need to be able to support
it – the encrypted data can pass through routers and other machines on the
interlying networks without them needing to also support it.
Using IPSec, data is encrypted at the Transport Layer, which means
that data is encrypted before it gets to the Network Layer. Any machines
through which the encrypted packets will travel will examine the address
information on the packet, see that it is not intended for that network and
pass it on, the packet only being decrypted again when it reaches the Transport
Layer on the target machine. This is what is meant by end-to-end.
As with TCP, IPSec itself is actually a number of protocols. The
protocol that handles the encryption of the TCP data packets is called the Encapsulating
Security Payload (ESP) Protocol.
Individual packets are encrypted using a different encryption key,
and each encrypted packet is appended with a message digest, or checksum, so
that should any of the data be altered en route, the digest will no longer
match the contents of the payload (a message digest works by essentially taking
the value of all of the 1s in the payload and applying a mathematical function
to it, then saving that resulting value. Should the data change, the value of
the 1s will change and the resulting value of the mathematical function will
also change).
Individual encryption keys are used so that should an attacker
manage to intercept a large amount of traffic all encrypted using the same key,
they will not be able to calculate the key from that traffic, and potentially
encrypt their own data using that key. This is known as anti-replay.
The checksum value is stored in the Authentication Header.
This is an additional header which is added to the normal TCP packet before IP
adds its own address headers. The Authentication header does not need to be
used with ESP, it can be used by itself. The Authentication Header does not
encrypt the data, but it does secure it against modification.
Other values are also stored in the Authentication Header:
·
Next Header –
this field indicates the transport protocol used (TCP, UDP, etc) so that the
encrypted packet is submitted to the correct transport protocol on the
receiving machine.
·
Length –
indicates the length in bytes of the Authentication Header.
·
Security Parameters Index (SPI) – indicates whether ESP is being used or not.
·
Sequence Number –
indicates the packets position within the data stream and also contains another
message digest to guarantee the uniqueness of that packet.
·
Authentication Data – this is where the message digest for data payload is stored.
Security Association
When two computers using IPSec “handshake” (agree the parameters to
be used for the connection), before any data is sent or received they must
first establish a Security Association (SA). This “agreement” defines the
encryption key to be used as well as the security protocol (ESP, AH, or both,
for example) and a security identifier (in case each or even both of the
machines are already involved in other IPSec-based communications with other
machines).
Once agreed, the SA will have a specific lifetime, after which time
the process will be repeated to agree a new association using a new encryption
key (an anti-replay technique).
Once connected, the VPN client is effectively connected to the
remote network. As such it is assigned an IP address on that remote network, a
non-routable IP address which the VPN software sends over the Internet
connection for reception by the VPN server.
This being the case, the VPN server will need to be able to assign
remote devices local IP addresses – ideally automatically via DHCP from a pool
of reserved addresses.
Tunnelling
ESP can be used in two modes: transport mode and tunnelling
mode.
In transport mode, only the data payload is encrypted. In tunnelling
mode, the data and also the IP Header is encrypted. When used in a VPN
solution, ESP operates in tunnelling mode.
In tunnelling mode, the entire TCPIP packet is encrypted (not just
the TCP packet), digitally signed, and then a new IP header created, which is
unencrypted, so that the VPN packet can still be routed across the Internet.
When the packet arrives at the destination network, the receiving server
removes the IP header and the ESP header (decrypting it in the process), and
uses the original IP header information to route the packet across the local
network. It is this process that can sometimes cause problems when connecting
from certain devices, especially mobile devices, which I will now endeavour to
explain.
Network Address Translation (NAT)
Network Address Translation is a technology employed to address the
issue of a shortage of available “routable” IP addresses. Because there are not
sufficient routable IP addresses available for each machine connected to the
Internet to have one, local networks employ a non-routable addressing scheme
and have one machine, a gateway, with a network interface connected to the
Internet with a single routable IP addresses allocated to it. Using this single
address, many many machines can sit “behind” this gateway and enjoy Internet
access, without being directly connected to it. This process is known as
Network Address Translation. A typical example of this process may work as
follows:
1.
A machine on the internal network requests a web
page from a web server on the Internet. The machine creates an HTTP request and
submits it to the network, which sends it to the NAT gateway router.
2.
The router receives the request and sees that it
is destined for a machine not on the local network. The router saves the
machine’s non-routable IP address to an address translation table. It then
re-writes the IP header, replacing the source IP address with its own public IP
address and sends the request out across the Internet.
3.
When the response comes back from the web
server, the router checks the address translation table, rewrites the IP header
of the incoming data, changing the destination address from its own to the
address of the machine on the internal network, and forwards it on.
IPSec and NAT compatibility
If a TCPIP packet crosses a NAT gateway, it will have its source IP
address information changed. Because IPSec performs a data authentication check
on all incoming packets to ensure that they have not been altered in any way
while in transit, the changing of the source IP address by the NAT gateway will
cause the message digest to no longer match the data, and IPSec will “fail” the
packet and the connection will not be established.
When connecting to the Internet from a mobile device, the mobile
network operator will employ a NAT gateway between the mobile network and the
Internet. For this reason, VPN connections from mobile devices will quite often
fail.
Help is at hand
One solution to this problem is known as NAT Traversal (NAT-T).
This technique addresses this problem by using UDP as the
transport protocol, rather than TCP.
UDP is the User Datagram Protocol. It is a transport protocol
similar to TCP, but it does not employ error correction, it is used for
“unimportant” communications where data loss is not necessarily an issue.
Because UDP does not send acknowledgement messages back to the sending machine,
it does not include a sending IP address in the header, only a target IP
address. For this reason it is sometimes referred to as a “fire and forget”
protocol.
Using UDP to transport the encrypted the IPSec packet therefore does
not involve rewriting any of the packet’s data as it passes through the NAT
gateway. Instead, at the NAT gateway, a normal TCPIP header will be added for
routing across the Internet. At the receiving machine, the TCPIP header will be
removed at the network layer, and the unaltered UDP packet delivered to the
transport layer and the waiting IPSec protocol.
This technique does require that both the VPN client software and
the VPN server both support NAT-T (also referred to as UDP Encapsulation), and
do agree on this protocol during the negotiation of the security association.
Fortunately, most mobile network operators are aware of this problem
and have implemented their own solutions. The public “Internet” access point
(APN) which most users will connect to for Internet access, will use NAT to
allow the large number of mobile users to connect to the Internet whilst only
requiring the operator to provide a small number of public IP addresses.
For users who wish to establish a VPN connection, there are
alternative APNs available. Most operators will be able to offer two additional
APNs intended for VPN use: which one is relevant for you will depend on the
requirements of your VPN infrastructure.
Taking Vodafone as an example, the public APN is simply “internet”.
This will employ NAT to provide users with access to the Internet. “MyLAN” is a
separate access point intended for corporate VPN users. This APN will use NAT-T
to get around the issue of NAT and IPSec compatibility.
On the Orange network, “orangeinternet” is the public Internet APN,
whereas “internetvpn” is intended for corporate VPN users.
There is typically no cost to use these alternate APNs, but your SIM
card must be enabled for these services first by calling customer services and
requesting it.
However, there is another potential issue which can cause a VPN
connection to fail. Typically, the “non-routable” IP addressing scheme used by
mobile network operators will allocate addresses to users in the range 10.x.x.x
This is fine if the local network in the office uses an addressing
scheme of, say, 172.16.x.x
This means that when connected to Vodafone 3G service, the mobile
device has an IP address of, say 10.0.0.1, and when connected to the VPN, the
“virtual network adapter” has an IP address of 172.16.199.1
The computer “knows” that any traffic destined for the 172.16.x.x
network needs to be sent to the VPN software which will encrypt it and route it
over the Internet connection (with a UDP header of 10.x.x.x being added to the
VPN packet).
However, if the network in the office also uses the 10.x.x.x address
range, the VPN software will be assigned a virtual address in this same range,
and the PC will then no longer be able to tell what traffic is intended for the
VPN and what is normal Internet traffic. In this situation it will most likely
try to route encrypted packets to the wrong destination and the connection will
fail.
This being the case, most network operators therefore provide 2 VPN
APNs. These work in the same way, but simply use different addressing schemes
to address this issue. Which one you need depends on your addressing scheme at
work.
So, if the Vodafone MyLAN APN uses addresses in the range 10.x.x.x,
MyLAN2 will use 172.16.x.x
Similarly on the Orange network, internetvpn will use 10.x.x.x and
internetvpn2 will use 172.16.x.x
The third way
Should your VPN infrastructure not support NAT-T, then the only
solution is to consistently connect from the same, routable IP address,
ie have a public IP address associated with your mobile device (or more
correctly, the SIM card in the mobile device).
There are providers that can offer this service, although the
service is chargeable. One such company is Wireless Logic (www.wirelesslogic.co.uk).
Configuring the VPN Client
All versions of Windows since Windows 98 have had a VPN client
included as part of the operating system. These VPN clients are only designed
to connect to the Routing and Remote Access service on a Windows Server 2000 or
2003-based endpoint. Windows Mobile devices also have VPN capability, but these
are also only intended for use with a Windows Server at the other end. If a VPN
solution by any other company other than Microsoft has been deployed, such as
Cisco or Checkpoint, then the corresponding client software developed by that
company should be used on the remote device.
Most VPN client software will require 3 pieces of information when
configuring the connection:
·
VPN Server Address
·
Username
·
Password
MacOS X Leopard:
Windows XP:
Windows Mobile:
All VPNs clients will install a virtual network adapter as part of
the installation process.
Troubleshooting
When troubleshooting VPN connections it is important not to forget
the basics. At a simple level, should the VPN client report that it is not able
to contact the remote server, or something along those lines, verify that the
device does have a connection to the Internet and can browse web pages.
If you do have a connection to the Internet, but the VPN client is
not able to contact the VPN server, it may be a DNS issue – try entering the IP
address of the VPN server rather than the friendly name.
If you are able to connect to the VPN server, but once connected you
are not able to access any network resources, this may be an IP issue – the VPN
server must be able to allocate remote clients valid IP addresses via DHCP.
This may also be a DNS issue – once connected try connecting to the IP address
of a file server rather than its friendly name, for example. Your network
administrator will be able to provide the details to use.
To conclude
VPNs are massively complicated, but not impossible to set up
successfully provided that you understand the requirements, potential pitfalls
and their workarounds. The biggest hurdle is often just finding out what it is
that you have. Once you know what your equipment supports then the available
options are clear.
As a bootnote, and for completeness, I should probably mention that
not all VPNs are necessarily secured. A Virtual Private Network could be a
Virtual LAN (VLAN) – which is a technique whereby the same physical network
infrastructure (cabling and switches) is used to host separate networks using
different addressing schemes and which are not “aware” of each other, but over
which communications are not secured.