skip to content

IT Help and Support

University Information Services
 

Find generic technical information about the supported protocols and methods of authentication for the UIS VPN service. Use this when setting up connections on devices not explicitly covered in the instructions. Also given are the network addresses and connectivity which will be provided upon connection.

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.

Contents

Connection types

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

IKEv2 with RSA and EAP

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 the MSCHAPV2 method.

Typically, a client will only need the following information to connect:

  • Type: IKEv2 EAP (Username/Password)
  • Server name: vpn.uis.cam.ac.uk
  • Username: The username for the UIS Network Access Token you created for this device.
  • Password: The password for the UIS Network Access Token you created for this device.
  • EAP type: MSCHAPV2
  • Request an inner address (aka a virtual IP): yes

This protocol is supported by Windows 7 to 11, modern Linux distributions and Android with the StrongSwan client. 

Note that, for Managed VPNs, the server name will be different.

IKEv1 with RSA and Xauth

This method involves two phases:

  1. 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.
  2. 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:

This protocol is supported by macOS, iOS and Android and is commonly referred to as Cisco IPsec. As with IKEv2, for Managed VPNs the server name will be different.

Certificates

The VPN uses certificates to verify the identity of each party, much like a web server running SSL (HTTPS).

Server certificate

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, current versions of StrongSwan on Linux 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, and some Linux distributions) 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 server certificates will soon be expiring every 90 days, this would be extremely annoying, so we recommend using the official StrongSwan client on Android, ensuring your Linux installation is up to date or finding a way to verify with the longer-lived CA certificate which verifies our certificates.

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.

Client certificate

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.

Download: client identity (PKCS#12 - certificate and private key).

IP addresses and traffic filtering

The VPN service issues UDN-wide private IP addresses to connecting clients. Traffic from clients connecting through the VPN to hosts within the UDN will not be translated and will use these addresses directly; traffic leaving the UDN to exit onto Janet and the internet will pass through the regular UDN NAT service and appear to come from one of the UDN's global IP addresses.

The IP address range used by clients on the general/main VPN service is currently 172.16.32.0/21, being NATed behind the global address 131.111.184.3, when leaving the UDN, but these may change 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 using that Managed VPN and is useful where IP-based access control is required.  The global address it is translated behind may be different from that above and, importantly, may be shared with other Managed VPNs or, indeed, other networks on the UDN.

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 does not block outbound traffic beyond the general UDN port blocks at the Janet border.  Any blocks are likely to be controlled at the border of the target institutional network.

IP routing

The UIS service currently only supports being used as a default route, where all traffic goes via the VPN and through the UDN, regardless of whether the destination is on the UDN or not.

It does not provide any more specific routes to support split horizon routing, whereby traffic would only use the VPN if the destination where on the UDN and all other internet traffic would go directly out from the client host, via it's normal internet connection.

As such, it is necessary to ensure that the client is configured to use the default route supplied by the VPN service for it to carry any traffic.

Ports and protocols used

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 UDN, 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 UDN-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.

Problems caused by intermediate firewalls and networks

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 modified: 14 October 2022