Maintaining access to internal services during a continuity event
Last updated:
How to make sure your remote users can access services during business continuity events.
Business continuity events place pressure on service providers. Some organisations struggle to keep services accessible to remote users during these times.
Aside from scaling an existing virtual private network (VPN), or buying a new service for rapid deployment, here are some options that could relieve the pressure on these services in other ways:
Change user behaviour
Changing how users access systems is a powerful way to ensure resources are used as efficiently as possible, without the need for configuration changes or additional licenses.
- Small changes to timetables can spread out some of the load
- Encouraging flexible working hours can help to flatten spikes in demand
Make effective use of current VPN resources
The two limits organisations are most likely to hit are concurrent sessions and throughput, so it's important that each user takes up a minimal amount of resource for a minimal amount of time.
Ensure there are no idle users
Although it's nice for a user to return to their workstation after a four-hour break and find they're still connected, with a fixed number of seats they will have unnecessarily been occupying a licence that whole time.
Make sure that your VPN service has appropriate session length and idle timers set to ensure that idle resources are freed up.
Speak with vendors
Some may offer additional seats at reduced cost during times of crisis and can advise on how to drive maximum performance out of their products.
Conserve bandwidth
Switch full tunnel VPN's to split tunnelling if possible (and if there are no constraints around traffic inspection). Only advertise internal subnets so that traffic can be offloaded at the user’s workstation.
If split tunnelling is not possible, look at inserting net_gateway routes, or configuring Local LAN Access for high bandwidth services such as Netflix, iPlayer and YouTube.
Most large service providers publish their IP ranges, including Microsoft and Zoom. By loading these into the VPN server as routes to break out at the client, it’s possible to dramatically reduce the bandwidth each user consumes.
Allow access to internal services without a VPN
By opening up services to direct access where appropriate, the number of users that need to access a VPN at any given moment can be reduced.
This doesn’t have to be an ‘all or nothing’ approach. An effective application layer firewall allows individual urls to be filtered. VPN access would be required for admin console access and privileged tasks, but regular users could be permitted access without. Network address translation (NAT) can make this difficult, or impossible, but there are other ways to securely deliver services behind an IPv4 NAT without the use of a VPN.
What about security?
Although VPNs are an easy way to add encryption and authentication to services, many modern applications operate over some form of built-in strong encryption and now support strong authentication mechanisms out of the box (SAML, OIDC, OAUTH, Kerberos, LDAP) enhanced with multi-factor access.
- Jisc offers a critical services protection service that can help mitigate potential attacks
- Major cloud providers such as Cloudflare, Microsoft, Amazon and Google offer products that can act as drop-in solutions
Explore alternative service designs
If your services are delivered over HTTP, investigate the use of a reverse proxy or load balancer. This can add strong encryption, strong authentication, and isolation from the internet without the use of a VPN.
There are a large selection of:
- Open source reverse proxies (Apache, NGinx, Pound, Varnish, HAProxy, Træfɪk, Caddy, Squid)
- Products from major cloud vendors(Cloudflare, Microsoft, Amazon and Google)
- Physical and virtual appliances (F5, A10, Citrix)
Some options go a step further and enable the build out of a zero trust security model with ease.
Switching over to this kind of design is application-dependent, but can allow access to systems to scale better.
This doesn't have to be an 'all or nothing' approach. It’s possible to start from a single service and have it delivered both via VPN and via reverse proxy simultaneously.
Migrate services to the cloud
A common reason for deploying a VPN is to access services that are based on private addressing. A quicker way to make these accessible is to migrate these to a public cloud.
The difficulty of migration is dependent on the application itself, but once they're in the cloud there are additional options for making them accessible, including:
- Network virtual appliances (to provide dial-in VPN services)
- Built-in load balancing
- Reverse proxying capabilities
Deploy IPv6
As a longer-term activity, IPv6 provides sufficient addressing so that any site can offer end-to-end connectivity for all users and services.
For sites with a limited pool of available IPv4 addresses, this would allow the delivery of on-premise services without the use of a VPN to some users during continuity events.