Skip to main content

Migrating an existing Transition Network VPN to HSCN

Guidance and considerations for migrating any existing virtual private networks set up on the Transition Network to HSCN.


A virtual private network (VPN) allows the secure connection of private networks over a shared network (the internet), enabling organisations to send data between each other emulating the properties of a private network link.

VPN services for NHS network traffic were introduced on the N3 from 2005 onwards. N3 became the Transition Network in April 2017. VPNs were primarily used to securely connect GP branch sites to their main site. They allow remote users access to clinical systems and other sensitive information hosted at the main site (figure 1). VPNs were an optional component and made available to support compliance with British Medical Association (BMA) guidance.

HSCN features comprehensive security monitoring and analysis functionality, providing a central capability to detect irregular traffic volumes or flows, in near real time. HSCN consumers will benefit from this capability as potential problems can be detected and resolved promptly.

Whilst these capabilities undoubtedly enhance network security, like N3 previously, HSCN should not be considered a 'secure' network. Further information can be found on the Improving cyber security web page.

The incumbent supplier (Transition Network service provider or TN-SP) will not support VPNs with endpoints on different suppliers’ networks; however, the incumbent supplier will provide a redacted configuration taken from the existing router, which allows the consumer network service provider (CNSP) to configure connectivity in the same way as the existing VPN.

Example of Transition Network one-to-many VPN

Diagram of the current Transition Network VPN solution

Figure 1: existing Transition Network VPN solution.

When a VPN is created the traffic running through the tunnel will be encrypted as an additional measure of security.

HSCN supports the use of VPN services as an optional service. Where a supplier is providing VPN services they should consult the government Communications-Electronics Security Group (CESG) guidelines at:

VPN considerations

Please consider the following when using a VPN on HSCN:

  1. Only information that is being shared between collaborating sites should traverse the VPN.
  2. Using a VPN is not mandatory. If an organisation has an existing VPN on the Transition Network and are considering a VPN over HSCN they should revisit the original requirement to see if their applications and services have since evolved or requirements have changed. For example, the current services may now be encrypted, including in transit (HTTPS, TLS for example).
  3. If the site’s network connection is resilient or has redundancy, then the VPN will be active on the primary circuit and the backup circuit (upon failure of the primary circuit).
  4. Using a VPN carries a network overhead (on average 10%) therefore existing network utilisation should be considered before implementing a VPN.
  5. HSCN VPNs are likely to be configured using authentic digital certificates in order to simplify service management. For example, using pre-shared secrets requires regularly changing encryption keys to preserve integrity, which can cause disruption.
  6. The VPN solution will work whether Network Address Translation (NAT) has been implemented at the end points or not.
  7. A suitable VPN terminating device will be required at each endpoint (such as a Cisco Integrated Services Router) because VPN endpoints managed by different HSCN CNSPs will not be supported by the incumbent Transition Network provider (figure 2).
  8. The IP addresses used to configure the VPN are usually independent of the IP addresses that are used for the data transfer; therefore, a new VPN can be configured in parallel to the existing VPN. For example; it is most likely that the consumer organisation’s private IP addresses will be obscured when using assigned external IP addresses.
  9. If an existing Transition Network VPN is being re-established over HSCN then it is important that the consumer ensures suitable dialogue takes place between the HSCN CNSP and the incumbent VPN provider. This is to maintain continuity of the existing communication during deployment.
  10. It will not be possible to configure the new VPN endpoints using the existing digital certificates or new certificates on the existing Transition Network hardware. This is because the Transition Network/N3 VPNs were deployed as a managed service package, including hardware, and the certificates obtained from TrustWise sourced by the Transition Network service provider will be revoked upon service termination.

The following diagram demonstrates a typical HSCN VPN migration process. If there are additional branch sites, then iterations of the same process would be applied.

However, it is advised to configure the new VPN in parallel, demonstrated in figure 2.

Example of a typical HSCN VPN migration process

Diagram of VPN migration process

Figure 2: VPN migration process

The following demonstrates a typical VPN migration process.

Phase 1

Configure the VPN on the new routers, starting with the main location. Note: the crypto map remains disabled until the peer is configured and a valid access list has been applied at all endpoints, allowing internal traffic to traverse the tunnel.

  1. Confirm that VPN capable devices are active and visible on HSCN.
  2. Create Internet Key Exchange (IKE) policy.
  3. Configure the crypto map.
  4. Configure the transform set.
  5. Configure the endpoint mapping.
  6. Write (compile) the configuration on the router.
  7. Create the access list containing a subset of the intended internal network addresses at both ends, sufficient for testing connectivity.
  8. Test connectivity between internal networks via the VPN.

Phase 2

  1. Complete the access list for full live cutover.
  2. Reroute the traffic via the new VPN.
  3. Terminate the old route via the TN routers.
Last edited: 27 September 2018 11:31 am