By Nicole Olsen and the Peer5 Team
In this guest blog, MediaPlatform partner Peer5 offers tips for configuring your VPN to efficiently deliver video to your remote workforce.
VPNs are nothing new, but they’re making a huge comeback in these wacky days of COVID-19. This gives us an opportunity to talk a little bit about how a company’s virtual private network (VPN) might negatively impact their ability to stream video, and, in the process, recommend a couple of ideas for mitigation.
Many companies secure their internal services behind a strong firewall in order to make them inaccessible to anyone outside their local network. The only way to reach these services is (a) to physically be in the office or (b) to connect to the corporate network through a VPN, which allows someone to remotely access a local network as if they were actually on the premises. There are many different types of VPN that use varying terminology, but they all work similarly by altering networking behavior. For simplicity, I’ll just refer to all of them as “VPN,” because what I really want to focus on are the conceptual implications of using a VPN or VPN-like tools on video streaming, rather than going into the specifics of each software solution.
The limitations of a corporate network
Although it may seem counterintuitive at first blush, many companies have very limited connections to the public internet. An office with 5,000 employees might have amazingly fast internal communication speeds, but as little as 2Gbps of throughput to the outside world. This equates to 400 Kbps of bandwidth for each employee – not much when you’re trying to stream HD video. This limited bandwidth needs to serve not only the employees and services inside the office but also any employees connecting remotely via a VPN. If the VPN is even slightly misconfigured, the overall traffic volume could be unnecessarily increased by up to 2x. Conversely, if configured properly, extensive use of VPNs might not lead to an increase in traffic at all. So let’s break down the different potential configurations for a VPN, focusing on the path that the video stream will take.
The various VPN configurations
All VPNs behave on a spectrum that lies between (a) routing all traffic on your computer through the corporate network to (b) routing only a very specific subset of IP addresses through the corporate network. The first configuration is usually called “full-tunnel” whereas the latter is called “split-tunnel”.
Let’s consider the example of an all-hands meeting in which the CEO addresses all 5,000 employees, half of whom are connecting from home. The stream is broadcast from the CEO’s office to a cloud HLS ingestion service and an event web page is set up to play the stream using a standard HLS player.
But to make things interesting, let’s require that each employee has to authenticate with an internal corporate service before they can access the event page.
An employee inside the office will authenticate, load the event page and then watch the video — so far so good. In this case, the number of video bytes that are transferred is 1x — no overhead.
A different employee, who is working remotely, tries to load the event page, but fails because they are outside the office. So they connect to their full-tunnel VPN, which means that now all of their network traffic is routed through the corporate network. The employee is now able to authenticate successfully and watch the video, but the video quality isn’t great with pixelated frames and lots of rebuffering. Why does this happen?
In this full-tunnel example, the video bytes traverse the corporate internet port twice. Whenever the remote user makes a request for a video segment, this is the path for the response:
- Video cloud server -> VPN server
- VPN server -> client
Not only does the VPN add latency, it also overloads both the uplink and the downlink of the company’s already constrained internet connection.
The obvious question here is: why does the video need to go through the VPN server? Once the employee is authenticated, there is really no need to pass the video segments through the VPN.
Full-tunnel vs Split-tunnel
Configuring a full-tunnel makes sense in certain cases; for example, when one is connecting from an untrusted location. An airport WiFi hotspot is an example of a location that is not ideal for banking or other sensitive communication. These days, most communication is encrypted using TLS, but in the case of a public hotspot, you might not even want to disclose the servers you are connecting to. A full-tunnel VPN creates a secure end-to-end link between the computer and the server which captures 100% of the network packets — safety is assured.
Full-tunnel has been the standard configuration for VPNs for many years but it comes at a price, and that price is latency. All of your network traffic needs to travel much further, which translates to higher latency and lower speed. Specifically in the case of video, a full-tunnel VPN means that your traffic is tightly coupled to the corporate network — if it’s congested, then you are congested too. You may have a 100 Mbps connection at your home, but you’ll never fully utilize that speed with a full-tunnel VPN as the overhead is just too great. For this reason, many companies now favor a more lightweight approach called “split-tunnel”.
Split-tunnel means your computer is connected to the VPN server just like before, but only a specific portion of your traffic goes through the VPN server, while the rest goes directly to the public internet.
Circling back to our CEO event example, a proper split-tunnel configuration might be as follows:
All connectivity to auth.company-internal.com is configured to go through the VPN (with the help of IP subnets) and all other requests go directly to the internet. Now, a remote employee who tries to watch the event will:
- authenticate successfully, since he is able to reach the authentication server
- connect to the cloud video service directly and watch the stream flawlessly via their 100 Mbps home internet connection
Configuring your VPN for video
The key to configuring a VPN for video is to avoid passing the video segments through the VPN server. In a typical split-tunnel configuration, only whitelisted IP ranges are routed through the VPN. However, if full-tunnel is a reality you’re required to deal with, then you can try to blacklist the cloud video server IP address(es) to prevent this specific traffic from flowing through the VPN server. If you are using a CDN or other cloud service, you can ask your vendor for their IP addresses and use this info to configure your VPN.
Here are some references for split tunneling / whitelisting on common enterprise VPN services:
- Perimeter 81 – Split tunnel
- Cisco AnyConnect – IP whitelisting
- Fortinet – Split tunnel
- Pulse Secure – Split Tunnel
- Citrix Gateway – Split Tunnel
- Google Cloud VPN – Split Tunnel
- ZScaler – Split Tunnel
- OpenVPN – Split Tunnel
Peer5’s Auto VPN support
Without proper detection, some P2P networks may connect users that are physically on the corporate network to VPN users. Those connections are the worst because they create more incoming bandwidth and even upstream bandwidth from the corporate network. Peer5 is VPN-aware and will avoid passing P2P traffic over the constrained VPN connection. This is essential because the ultimate goal of Peer5’s Enterprise Content Delivery Network (ECDN) is to reduce bandwidth from the internal network. If you are using a VPN for some or all of your users, let us know and we will make sure everything is configured correctly.