The information here is somewhat technical. If in doubt you should follow the instructions for your specific device, or seek advice from your local Computer Officer or the UIS Service Desk; incorrect configuration can result in an insecure connection being established, and your credentials and traffic intercepted by a third party.
See also the Managed VPN Service for Institutions, which may be useful for institutions needing to restrict access to internal resources based on the IP address of the client.
- Connection types
- IP addresses and traffic filtering
- Ports and protocols used
- Problems caused by intermediate firewalls and networks
The VPN uses IPsec with ISAKMP (IP Security with Internet Security Association and Key Management Protocol). These are used together as follows:
- IPsec - is used to tunnel the traffic passing over the VPN connection across the internet. It also secures it by both authenticating (confirming that the traffic came from the correct host and has not been tampered with en route) and encrypting it (scrambling it to prevent third parties reading it by capturing the data in transit).
- ISAKMP - is used to set up and maintain an IPsec connection by allowing each party to authenticate each other and exchange the necessary security keys to protect the traffic. It also allows the server to send the client an IP address to use and information about what traffic can pass over the VPN connection.
The VPN service supports two methods of authentication and key exchange over ISAKMP, both described below.
It should be noted that the VPN does NOT support PPTP (the Point-to-Point Tunnelling Protocol) nor IPsec/L2TP (IPsec with the Layer 2 Tunneling Protocol).
This is the simplest, and preferred, method for connecting to the VPN. The server first authenticates itself to the client by supplying a trusted server certificate before the client supplies its username and password using EAP (the Extensible Authentication Protocol) and either the MD5 or MSCHAPV2 types.
Typically, a client will only need the following information to connect:
- Type: IKEv2 EAP (Username/Password)
- Server name: vpn.uis.cam.ac.uk
- Username: CRSid@cam.ac.uk
- Password: Network Access Token
- EAP type: MD5 or MSCHAPV2
This protocol is supported by Windows 7 and 8, and Android with the StrongSwan client.
Other systems for which StrongSwan is available may be able to utilise the following minimal configuration examples, compatible with StrongSwan 4.5/5. The client will also need a copy of the VPN server certificate from the Managed VPN Service.
# ipsec.conf - strongSwan IPsec configuration file config setup conn %default keyexchange=ikev2 ikelifetime=60m keylife=20m rekeymargin=3m keyingtries=1 conn CAM left=%any leftid="<Username>" leftauth=eap leftsourceip=%config leftfirewall=yes right=<Server name> rightcert=<Server certificate filename> rightid="CN=<Server name>" rightsubnet=0.0.0.0/0 auto=add
# ipsec.secrets - strongSwan IPsec secrets file <Username> : EAP "<Network Access Token>"
This method involves two phases:
- Phase 1 is used to secure communication between the two end parties (the server and client) before sensitive personal credentials are exchanged in the second phase. The server sends its server certificate to the client as with IKEv2, but IKEv1 requires that if one end sends a certificate, the other end must do too, so the client must also send its client certificate to the server.
- Phase 2 is performed once both ends have confirmed the identity of each other and a secure channel is set up between them. This allows the client to send the personal username and password of the connecting user.
Configuring a connection with this protocol is somewhat more complicated than IKEv2 as the client certificate and key must be installed:
- Type: IKEv1 with RSA and Xauth
- Server name: vpn.uis.cam.ac.uk
- Client identity: client identity certificate and key (below)
- Username: email@example.com
- Password: Network Access Token
This protocol is supported by OS X, iOS and Android and is commonly referred to as Cisco IPsec.
The VPN uses certificates to verify the identity of each party, much like a web server running SSL (HTTPS).
The server certificate is used by the server to prove its identity to the connecting client. It is a regular certificate from a known, public, trusted root Certification Authority (CA) and will have the server's hostname (vpn.uis.cam.ac.uk) as its Common Name (CN).
Some platforms (including Windows, OS X, iOS and the Android StrongSwan client) check that the certificate is signed by a trusted CA and that its CN matches the hostname (much like other secure services such as HTTPS, IMAPS, etc.), so need no additional information to validate the identity of the server.
However, some platforms (in particular Android using the built-in client) do not check any of these details and need to be given a copy of the server's certificate to confirm that the server is, indeed, the correct one. As certificates expire every few years, it may be necessary to update the copy held on the client device when the server certificate is changed - the UIS will notify users in advance, with the time and date of the change, and the new certificate.
Note. It is possible to configure some clients (e.g. the Android built-in client) not to check the identity of the server. This must never be done as the client will then send the username and password of the connecting user to the server without knowing if it is the correct one. A man-in-the-middle attack can be used to steal account details and impersonate users. As the same credentials may be used for other services (e.g. eduroam) this will also allow access to, and abuse of, these services.
Download: server certificate (dated 2014-09-24). This certificate is likely to be replaced in mid 2017.
The client certificate is only required when connecting over IKEv1 - it is used to identify the client host (but not the individual connecting user's account) to the server.
The client also requires the private key to accompany the certificate in proving its identity. The certficate and private key are bundled together in a PKCS#12 (Public Key Cryptography Standard number 12) file (also sometimes called a PFX file). The private key in the PKCS#12 file is protected with a passphrase - this is set to "vpn" (without quotes).
Usually a private key should be kept secure and its distribution tightly controlled but, as the individual username and password are also required, it can be widely distributed and made freely available without security issues.
The client certificate has a long lifespan (until 2034) and should not need to be replaced during the lifespan of either the client device or the service itself.
The VPN service issues CUDN-wide private IP addresses to connecting clients. Traffic from clients connecting through the VPN to hosts within the CUDN will not be translated and will use these addresses directly; traffic leaving the CUDN to exit onto Janet and the internet will pass through the regular CUDN NAT service and appear to come from one of the CUDN's global IP addresses.
The IP address range used by clients is currently 172.16.32.0/23 but this may expand or move in future, without warning. We strongly recommend that you do not rely on this range for use with further access controls.
The managed VPN service for institutions uses IP addresses dedicated to clients from that institution and is useful where IP-based access control is required.
The VPN service provides a simple, stateful firewall which blocks inbound connections to clients including any services running that client (e.g. Windows filesharing, SSH or a webserver). However, we recommend that clients run their own host-based firewall for their own security.
The VPN service uses several ports, which differ depending on whether there is Source Network Address Translation (SNAT) operating between the client and the server:
- The initial connection from the client to the server is made using ISAKMP on UDP port 500. This protocol will be used to authenticate both parties and exchange the security keys, as well as determine if SNAT is in use.
- If there is no SNAT, the tunnelled traffic will use ESP (Encapsulating Security Payload), IP Protocol 50 - this is an IP protocol separate to UDP and TCP, without port numbers. In addition, ISAKMP will continue to be used to update the security keys and maintain the connection, typically every hour or so.
- If SNAT is detected, the connection will, instead, switch to use NAT-T (IPsec NAT Traversal) on UDP port 4500 as the server port; the client will use whichever port the SNAT has translated its data to, so will be unpredictable. This port is used as a tunnel for the ESP and further ISAKMP traffic, so all communication from this point onwards should use this connection. This protocol is used in preference to ESP as it is difficult to maintain a connection through SNAT with ESP.
However, despite the behaviour stated above, NAT-T may be forced any/all connections, even when SNAT is not detected, as it has been observed to behave more reliable, especially with firewalls which have trouble maintaining an ESP-based connection (either because of ESP itself, or because the UDP packets over 500 are sent very infrequently and translations can have expired before the next packet is sent). This policy can change without notice.
When connecting from outside the CUDN, it is most likely that SNAT will be in use, as the connecting client will be on a domestic broadband connection, or on an SNATed private address (the equivalent of a CUDN-wide private IP address) at another institution. NAT-T is designed to work through a stateful firewall and should not require any special configuration to work.
Some firewalls or NATs attempt to interfere with or block IPsec traffic (both ESP and NAT-T) and it is necessary to ensure they are not set to do this as it will typically result in difficulty establishing or maintaining a connection with the VPN service. Disabling this feature may require that an option called "IPsec passthrough" is specifically enabled, especially on domestic broadband routers.
In addition, because VPNs require that the packets of user traffic (inside the VPN) are encrypted and wrapped up ('encapsulated') inside other packets, between the client and the VPN service, this can result in the packets being too large to pass across some network links. In this case, the packets may be fragmented (broken up into several pieces and sent separately) to be reassembled at the far end. Some firewalls do not allow fragments to pass through them and can prevent the VPN from working. The VPN service has been configured to try and prevent this from happening, but it is not possible in all cases. Resolving this issue may require the enabling of an option such as "Allow IP fragments" or "IP fragment reassembly" on an intermediate firewall or router.
Advice on changing the settings on a particular router is beyond the scope of advice which can be given by the UIS and users are advised to contact their Internet Service Provider (ISP), if it is suspected this may be occurring.
Last updated: 1 September 2015