Establishing a virtual private network (VPN) connection from a cellular device can be quite a complicated affair and when troubleshooting issues it is necessary to understand what is happening in the background to be able to identify what might be going wrong.

A crash course on VPN technologies

VPN technology is used to extend private networks beyond the boundaries of their physical cabling – to grant remote users access to local network resources by 'fooling' the network into believing that the remote client is connected locally. This is accomplished by 'encapsulating' the data packets generated by the client – that is to say, the client generates a request for a local resource, and that request ‘packet’ is then ‘wrapped up’ in a larger packet with the necessary information to enable the request to be routed over the Internet. At the VPN server, the Internet addressing information is removed and the ‘local’ packet delivered to the local network resource. The process is then repeated in reverse to deliver the response from the local network back to the remote client. This process of encapsulating packets with 'local' addresses into larger packets with 'routable' addresses so that they can cross the Internet is known as tunneling.
Because the packets are traversing the Internet to get to their destination, and could potentially be intercepted on their route to the destination, the contents of the packet are encrypted for security.

There are three principle protocols employed by VPN products:

• PPTP – Point to Point Tunneling Protocol
• L2TP – Layer 2 Tunneling Protocol
• IPSec – Internet Protocol Security

Each of these protocols essentially works in the same way: a packet is created with a source and destination address on the local network. That packet is then encrypted so that it cannot be read by any party that does not have the required decryption key. The encrypted packet then has the host’s Internet source address added and the external IP address of the VPN server is set as the destination.

PPTP is the oldest of the three protocols and provides security by encrypting data, but does not provide any means of verifying the identity of the sender or verifying whether the data may have been modified en route.
L2TP addresses this limitation by signing each packet with a digital certificate and adding a “hash” value or “message digest” to each packet. Essentially this involves performing a mathematical function on the data stored in the packet using the key contained in the certificate, and saving the result of that function. If the data is altered en route, when the receiving machine performs the same calculation, the resulting value will not match the original and the packet will be discarded and a request issued for a new copy.
IPSec, the commonest form of VPN protocol in use today, goes further and adds a message digest to the addressing “header” as well as just the data. This means that should your packet be intercepted en route and a hacker attempt to substitute your source address with their own (so that the VPN server then replies to them rather than you), the hash value on the address header will not match and the authentication process will fail.

This last detail is important and has implications on the ability of cellular devices to establish IPSec-based VPN connections.

Network Address Translation (NAT)

When a mobile device registers with the mobile operator using the normal ‘public’ APN (Access Point Name), it will be assigned a private IP address, normally in the range 10.x.x.x
Due to limitations of the IPv4 addressing scheme, there are not sufficient addresses available for all connected devices to have a ‘public’ IP address. Instead, connected networks typically have a single Internet-facing device with a public address and any devices that sit ‘behind’ that ‘gateway’ have private addresses. When a particular private device needs to connect to the Internet, it issues a request to the gateway using its local IP address. At the gateway, this request is edited, with the local address being substituted for the public address, and the request is then sent on its way across the Internet. The machine on the Internet, be it a web server or whatever, sends the desired response to the Internet address of the gateway, which receives it and then forwards it onto the private address of the local machine.
The process of editing the source address of a IP header is known as Network Address Translation.

A mobile network operator works in exactly the same way, and will assign connected client devices local addresses, performing NAT on all requests that are passed onto the Internet.

A moment ago we saw that the IPSec VPN protocol will perform a check on the IP header of a packet so that the VPN server can verify that the packet has not been altered en route. When the VPN packet passes through the NAT gateway, it will have its source address rewritten, substituting the local address with the external address of the gateway. Although this is not a malicious act, it will effectively cause the IP header check value to no longer match, and the VPN server will refuse to accept the packets, believing them to have been modified – which of course they have been.

This is a common cause for VPN connection issues when using the IPSec protocol from cellular devices.
There are a number of resolutions to this problem.

• Use a public IP address: most network operators provide the ability to use a public IP address rather than a private one, that will not undergo any NAT and therefore not be subject to this issue. In most cases this is simply a question of connecting to an alternate APN rather than the default, such as ‘vpn.o2.co.uk’ in the case of O2, rather than the standard ‘mobile.o2.co.uk’. Contact your network operator for more information.
• If your network operator does not provide a public IP address, then it is possible to get around this issue. Most modern implementations of IPSec provide for what is called ‘NAT Traversal’. Essentially this involves creating the VPN packet using the UDP transport protocol rather than TCP. UDP does not use source IP addresses when creating the data packet, only a destination address. Therefore a UDP packet can pass through a NAT gateway as there is nothing to re-write. Check within the configuration of your VPN software whether there is an option to use UDP mode, or NAT-T mode.
• Alternatively, if neither of these are an option, verify whether your IPSec VPN can be run in tunnel-only mode rather than authentication mode. This will mean that the VPN software does not verify the integrity of the header information, which is defeating the object of having an IPSec VPN in the first place, but is an option nonetheless.
• Finally, if none of the above are possible, then it may be necessary to use a different VPN mechanism rather than IPSec – an SSH or SSL-based VPN may be option, such as OpenVPN.

Addressing Schemes

When configuring a VPN server, it is important to remember that once authenticated, your client device will then need to be assigned an IP address on the local network in order to be able to communicate with other network resources, ideally via DHCP – it is surprising how many times this is overlooked. It is also important to use a suitable address range.
For your VPN solution to work, the client will need to recognise the remote resource being requested as residing on a network ‘behind’ the VPN server.
The majority of mobile network operators will assign connected clients an IP address in the range 10.x.x.x or 172.16.x.x (or potentially 192.168.x.x).
Therefore, if you have connected to your provider’s 3G service and have been assigned an address of, say, 10.10.0.24, you may be able to connect to your VPN server, but if you then request a connection to a server on the remote network with an address of 10.10.0.89, the client device will not know to route the request over the VPN link but will look for it on the local network.
Your internal network should therefore ideally use an addressing scheme that is suitably unlikely to be in use elsewhere.
Once connected, the VPN client will be assigned an IP address on the remote network. Similarly, in order for the remote resource to be able to reply to requests from the VPN client, the address used by the client also needs to be ‘behind’ the VPN server so that local network resources know to route responses accordingly.
The necessary routes will need to be added to the local network resources: either each machine will need a route added to it to direct requests to the VPN network to the IP address of the VPN server, or (preferably) add a route on the default gateway of the internal network.

Troubleshooting

Should your VPN connection not be established successfully from your client device, there are a number of things to check.

Firstly check the basics – are you definitely connected to the Internet and able to browse web pages? If not, address that issue first as until you can connect to the Internet you won’t be able to contact the VPN server.

If you can connect to the Internet, but cannot contact the VPN server, it may be a DNS issue. If your VPN client is configured with a name (eg vpn.domain.com), try connecting to the external IP address of the server instead.

Always check the log files, both on the client and on the server. If you receive errors relating to Security Association, or SA, failures, then it may be related to the IP address issue I looked at earlier.

Firewalls. If the VPN server sits behind a firewall, ensure that the correct ports are open – consult the documentation of your VPN server appliance. If using IPSec in UDP mode, the following ports will need to be open:

UDP 500 (IKE)
UDP 4500 (ISAKMP)

If you are able to connect to the VPN successfully, but once connected you are not able to connect to any resources, it may be an addressing or routing issue – verify that the IP address assigned to the VPN adapter does not conflict with the address assigned to the device by the mobile operator, and with your administrator that the necessary routing is configured on the local network.

If all fails, ring tech support!