What next for VPNs?

What are VPNs?

An Introduction to VPNs

For many years Virtual Private Networks (VPNs) have been used in ICT in order to connect one private network to another private network across an insecure public network. There have been primarily two classes of VPN:

  • A site to site VPN doing pretty much what it says on the tin – connecting one physical location in an organisation to another, and

  • A remote access VPN connecting a user device back to the central resources they need to access.

Diagram showing different types of VPN

Security of the VPN was based on a public key infrastructure (PKI) or some form of pre-shared key (PSK) and in controlling who had access to the secrets in order to ensure that only those authorized to connect were able to connect.

Reverse Proxy & Load Balancers

A reverse proxy is typically used to terminate SSL or TLS sessions at a common network location in order that a common certificate can be used across a number of services. For example service1 and service2 may have different backend servers but are both presented from https://www.acme-rmt.co.uk/ using a certificate for that base URI. A reverse proxy also typically offers some security features – like obfuscating the real IP addresses of the servers, providing user authentication, encryption, caching content, etc.

Illustration of usage of a reverse proxy

A load balancer is typically used for one of two reasons:

  1. Where the number of sessions anticipated exceeds the number a single server can handle

  2. Where there is a requirement for some form of redundancy or availability that drives a decision to use more than one backend server.

Its quite normal for a single appliance to have the capability to deliver both load balancing and reverse proxy functions.

SSL VPNs – a side case?

A remote access VPN is used to provide a user access to resources at a central location as though the user were at that location. It does this by setting up a secure tunnel between the user and the resources so that the user is effectively local to the centralized resources.

A reverse proxy appliance presenting applications securely to the internet can be used to authenticate who has access to those applications. It’s a pretty short leap from granting access to application web pages to granting access to any application of service hosted centrally. This is what an SSL VPN does (or a TLS VPN). Provides a tunnel from the user device to the central location that instead of using an IPSec VPN uses a TLS based VPN. This has the advantage that most firewalls will allow TLS traffic as its required for most web pages.

I’m not going to dwell on the differences between IPSec and TLS as a tunnel protocol just now as that isn’t my point in this post.

What has been the market leading solution?

The are a number of market leaders who all have products with similar features –

–         Easy to install

–         Supports Active Directory integration

–         Certificate based not pre-shared key based

–         Automatic

–         Minimal user interaction

–         Support pre-login tunnel initiation

Cisco AnyConnect, Citrix Gateway, Juniper VPN, F5 Big-IP are just a few of the market leaders in a traditional appliance based VPN solution.

My point in this blog post however is to ask whether there is a future in on-premise appliance based VPNs? Do they offer what is needed and if not what are the alternatives?

Why would an on-premise device not be suitable?

I think that there are two changes that are shifting the requirements around VPNs in favour of a internet based scalable remote access solution that is orientated around the user –

  • Shift from on-premise delivery to cloud delivery: Organisations are being encouraged to move away from delivering services on-premise to deliver services from cloud. This can be infrastructure no longer sitting on premise but in AWS or Azure but also organisations consuming software as a service solutions. This means that the services being accessed could be geographically anywhere and going across the internet to a data centre only to go back out to internet to access a service may not make sense – it may lead to higher latency.

  • Shift from office-based workplaces to flexible working: the majority of users may not be in an office any longer but could be at home, at someone else’s office, in a café etc.

Its also important to note that the user really doesn’t care how they gain access – merely that they can access the services they want to, when they want to, from wherever they are and ideally always in the same manner. You don’t want situations where the user has to remember a set of actions they need to take based on where they are in order for them to access an application.

Normally a VPN appliance is scaled for a particularly number of users – take for example the Cisco ASA series – if you anticipated that 10% of your staff would work from home and generate 120Mbps peak traffic and you had 10000 staff then you might choose the Cisco ASA Firepower 5508 model because its good for up to 175Mbps of IPSec VPN Throughput. Conversely if you though you would sometimes need more IPSec throughput you would choose a larger box. But most organisations would purchase a box sized for their normal operational requirement not the requirement during a disaster.

COVID-19 A case in point

At present its clearly the case that users are in all likelihood not working in an organisations offices but rather working from home. I imagine for a number of organisations this has caused some problems – possibly a need to buy additional licenses for an existing remote access solution or in some instances to buy a whole new solution if the existing solution was purchased without scope of a license only growth in users.

In my above example if suddenly all my 10000 users needed to work from home except say 100 people who needed to “keep the lights on” in the office then I’d probably need to go back to my network provider and ask for a new device.

Ideally you would want a solution where as the user numbers and throughput increased so would the capability of your solution. Without any administrative changes or redesign required. You certainly wouldn’t want to have to launch a full infrastructure replacement project.

Is a VPN always best?

There are applications where a VPN is not recommended – for example Microsoft recommend for both Skype and Teams that the session traffic is not sent through a VPN. This is because tromboning the connection over the internet to a private data centre, then back out to the internet in order to access a latency and jitter sensitive service doesn’t make sense. Both of these services are secured using HTTPS and strong authentication so accessing them from a central location isn’t required.

This does however highlight two other problems

  1. How do you do VPN split tunnelling for an application that doesn’t have a fixed IP address? This is a challenge not just in relation to Skype but any services that are internet based where you want to allow that service to be accessed directly from wherever a user is located without requiring a VPN.

  2. How do you differentiate a legitimate user login to a service from a malicious actor using hacked / stolen user credentials? Traditionally you’d do this based on the source IP address – but this only works when all legitimate user traffic comes from a small range of addresses. If users are accessing an internet based service from a range of UK IP addresses then this type of restriction cannot be effectively applied.

Further – Gartner identified in its “Market Guide for Zero Trust Network Access” of April 2019 that it believed traditional VPN-based access should be phased out and replaced with ZTNA (more on this below) because it doesn’t meet the requirements of cloud delivered services or flexible working.

What is the alternative then?

Could it be ZTNA?

Zero Trust Network Access or ZTNA fundamentally provides access to applications the user is permitted to access based on authenticating the user and then granting access. It is similar in concept to an authenticated reverse proxy service shielding applications. There are two sub-models of ZTNA:

  1. Client Initiated ZTNA: An agent is installed on the user device and establishes the connection to the ZTNA service and then authenticates the user and provides a list of applications for them to access. Network level security is established between the agent and a gateway appliance. Agent is required. Any application.

  2. Service Initiated ZTNA: The user authenticates to the ZTNA service proxy via a browser and is offered a list of services they are allowed to access. The applications are registered with the ZTNA service and connectivity from the applications to the ZTNA service is provided by a connector application. User access to an application is provided via the ZTNA proxy through the ZTNA connector. No agent is required. Browser only.

Service-Initiated ZTNA Functional Diagram

A key difference here to a VPN solution is that (ideologically) access to the application is only ever granted via ZTNA – so users access the application via ZTNA when working in the office, when working at home, or when working in a café. It is Zero Trust and thus trusts no one location anymore than any other location. You may also come across the term BeyondCorp – this was and is a ZTNA framework created by Google.

I’m not 100% convinced that ZTNA is wholly the answer but it needs to be explored. I think that remote access VPNs will remain in place at least until they are replaced by the normal replacement cycle due to end of life – at that point you probably want a solution that delivers both traditional VPN and ZTNA in order to have a viable migration path.

General Solution Requirements

I believe that there are a number of different technologies that need to work together to meet the below requirements:

  • Manage security based on identity and device not location: Clearly managing security based on location only really works if all staff are in one location. If staff can legitimately work from a range of locations then the legitimacy of any login attempt needs to be based on other factors – for example the characteristics of the device they are using, failed login attempts, Country of origin, reputation of source IP, time/date, actions taken by user etc.

  • Use a single identity provider not per application accounts: All user access attempts should be managed and permitted or denied by a single identity provider. This means that access attempts to different applications using the same hacked credentials would be reported to the same identity provider and be more obvious.

  • Present service access over the internet using strong authentication: I believe that the overall direction of travel is for more organisations to be consuming services as software and paying for access to services per user. Such services are designed to be readily accessible over the internet. Because of this it makes sense to plan for services to be presented publicly but to have adequate security controls. Note that I’m not suggesting you should announce which services are available but to have a portal through which services are offered _after authentication_.

  • Use a remote access solution where you pay per user: Let someone else manage the hardware associated with your remote access solution and have the flexibility to scale up and down on demand. This could be to provide access to applications only or to provide traditional network based access.

  • Connect back to on-premise: If you use an internet based VPN solution you still need to plan how to connect from that solution to services that remain on-premise. If the remote access VPN solution is a fixed public IP address you could simply allow direct access from that IP but to me that doesn’t sound secure – so I think a better option is to retain a VPN appliance on-premise for terminating site to site VPNs such as this one.

  • Integrate your VPN solution into your identity provider solution: You want a VPN solution that works with your identity solution in order to ensure that user posture is held and understood by your VPN solution.

  • Base granting access on a zero trust model: The default position should be “block access” and access should only be granted when the user and the device that user is using have both been adequately authenticated.

I’m sure there are many other requirements beyond those I’ve listed above but I think I’ve covered the main ones.

Are there solutions that do this then?

Yes. I think though that there are several different elements that are required to provide a solution – primarily a identity management platform, and a remote access platform (be it VPN or ZTNA or both).

I think most mid to large enterprises will have Microsoft Active Directory (AD) so whatever solution is chosen its likely that it will have to integrate into AD. There are a range of different providers in this space but I think most organisations will look to Azure AD to be their cloud identity provider because integrates well to the existing on-premise AD and also to Office 365.

So on the remote access solutions – I think that there are a range of providers depending on exactly what you want – there are the cloud VPN providers with enterprise gateways (e.g. NordVPN Teams) if you want something that more closely resembles a traditional VPN solution, then there’s the ZTNA providers (e.g. ZScaler), then there are the traditional VPN appliance manufacturers with cloud offerings too (e.g. Cisco’s Duo acquisition), then there are the cloud providers themselves (e.g. Microsoft O365 / Azure with Conditional Access can be used to build a ZTNA or VPN solution).

Out of these providers I think that ZScaler has the most complete offering – but I haven’t had opportunity to use their solution so my opinion is purely paper based (or whatever the modern equivalent).

What action needs to be taken?

I think that you need to be aware of the likely changes in VPN usage when making procurement decisions around ICT security infrastructure and have a plan in place to trial some of the alternatives. Some of the solutions are quite radical – for example introducing ZTNA means not trusting your office locations just as much as not trusting a internet cafe.

I think remote access also needs to be considered when replacing wide area networks (WANs) – if services are migrating to an internet delivery and the mode of implementing remote access is changing then these two need to work together. So there are some questions to ask when going to tender for a WAN replacement – for example around whether sites should have internet only access or a private network.

Finally I haven’t considered Software Defined Wide Area Networks (SD-WANs) at all in this article and I think there is probably some interaction/synergy between SD-WANs and VPNs.

Want to know more?

Why not subscribe to our FREE Newsletter to receive regular updates from us on ICT, technology and what we’ve been doing?