The outbreak of the coronavirus, and the global pandemic that has ensued, has pushed millions of workers across the globe to work from home. This sudden sea-change in connectivity models and workforce management has left some businesses facing technical difficulties, as IT teams struggle to support hundreds or even thousands of workers on existing network capacity.
VPN (virtual private network) load, in particular, can be a challenge. Here are three ways you can keep your VPN from getting overloaded, and ensure business continuity in a mass work from home event.
- Use Split-Channel VPN
Most office VPNs are set up to route all traffic through the user’s VPN channel, in order to inspect and monitor traffic. That includes not only office traffic, like file share request, but nonessential traffic, and even internet-bound traffic. In that case, every HTTPS request and response must hit both the upload and download side of the office's WAN twice—which can be punishing for bandwidth.
What’s worse, is that it’s hardly necessary when traffic to online apps like Office 365, Skype, and Slack is already encrypted. In such cases, you can save a lot of bandwidth by skipping the office WAN and letting traffic go directly from the user to the cloud.
By routing just office-bound traffic over an office VPN and allowing all other Internet traffic to proceed directly to its destination you can massively reduce VPN traffic, and it’s easy to do—the admin simply disables global routing and instead only routes the office subnet or subnets through the VPN. Of course, depending on your compliance and regulatory environment, this may not be allowed, so it’s important to check first.
An alternate method, if you’re unwilling to give up all control over Internet-bound traffic, is to enable only services known to be safe to circumvent the VPN. Microsoft has encouraged its customers to take this approach to optimize Office 365 traffic, and provides an API for identifying MS service endpoints, which you can query with a PowerShell script.
- Educate Your Users and Prioritize VPN Use:
Whether you’re using a split-channel VPN by default or not, chances have it your users are putting a much larger load on your VPN than they need to. In the past decades, many of the applications and file-shares that required VPN access have been replaced by SaaS applications, which have their own security measures and don’t require VPN access. Despite this, many users continue to use VPN for cloud-based apps, such as Office 365, which have their own set of protective firewalls and filters and don’t require a VPN. That’s why it’s important to make sure you know who’s using your VPN and why, and to communicate to your users specifically which services still require VPN, and which ones don’t. By doing this, you can significantly reduce the load on your VPN, without ever needing to set up a split-channel.
- Monitor for Potential Issues
Finally, if you want to keep tabs on the bandwidth your VPN is using, as well as the health of your WAN and your network writ large, you’ll want to monitor your WAN bandwidth usage, as well as VPN access closely. With any monitoring tool, you should be able to use SNMP polling or traps to monitor VPN tunnel up/down status, but you should also try to collect username, IP address, local address, client version, duration connected, start/end time of connection, and bandwidth usage, where possible. That way you can stay on top of total VPN connections, identify bandwidth hogs, and determine when you'll need added capacity—all before things start to go south for users.
General bandwidth monitoring is also a good idea. Real-time monitoring allows administrators to identify interfaces/links/applications/users/protocols taking up bandwidth, and will let you identify waste and free up resources for business-critical applications. With network monitoring tools, you can track bandwidth usage over all areas of the network—devices, applications, servers, link connections, leased lines, etc., and get insight into network bandwidth utilization and traffics analysis.