Virtual private networks (VPNs) have become a critical part of nearly every broadcast operation. Using VPNs and establishing policies for them can be an important part of your overall networking strategy.
As the name implies, a VPN allows a computer to appear to be connected to a local network, even though the computer may be hundreds or thousands of miles away. In this article, we will consider the case of a reporter hundreds of miles from the station who needs to log into the local newsroom computer to file a story. Before looking at VPNs, let's analyze an example that does not make use of a VPN.
Web browser access
One way to give the reporter access to the newsroom system would be to allow the reporter to log in to the system using a Web browser. The reporter connects the laptop to the Internet, enters the URL of the newsroom system into a Web browser and is presented with a login dialog box. Once the reporter logs into the system, she is able to file her story as if she were sitting at a desk in the local station. While this would work just fine, there are a few critical issues with this implementation, all of which revolve around security.
Using a Web interface to connect to a newsroom system is not a problem in and of itself. The question is whether the designer of that system has taken adequate safeguards to ensure that the system is not vulnerable to an attack. By having the Web interface exposed on the Internet, hackers will try to break into the system.
Figure 1. The station firewall can be configured to allow Web access for the newsroom network, but this is a security hazard. Click here to see an enlarged diagram.
Network engineers design strong security systems specifically to deter attackers from reaching critical internal systems. As Figure 1 shows, most stations employ firewalls and other devices at the Internet ingress point. These devices are specifically designed and updated to foil attackers. But all network engineers face tough challenges when implementing such systems.
On one hand, network engineers would like to protect the inside systems from attack. But they struggle with the security implications of allowing outside connections through the firewall technology they have worked so hard to create. If they have to provide remote access for other systems as well, then the network designers ultimately end up having to trust that a number of different vendors have taken adequate safeguards to be sure that their systems will not be compromised by an attacker.
The privacy of a VPN
In the past, there were few practical solutions. You built the best firewall you could, and then you exposed the absolute minimum inside equipment to the outside world. But with VPNs, network engineers have a better solution that provides a high degree of security while actually improving the end-user experience.
As mentioned earlier, the VPN creates a private network of computers, even though some or all of those computers are thousands of miles away running on different physical networks. The net effect of this is that once connected to the VPN, the reporter's laptop sitting in a hotel room acts just as if it were plugged into the newsroom network back at the station.
The communications between the laptop and the station can use encryption, making it difficult for an attacker to listen in. And because the VPN connection forces all Internet traffic destined for the laptop to pass through the corporate firewall, the laptop is protected by the same technology on the road as at home.
VPN in action
Figure 2. Once connected to the VPN, the laptop is assigned an IP address from the UPN address pool. All traffic across the Internet is encrypted. Click here to see an enlarged diagram.
Let's take a look at how this might work. In Figure 2, a station has configured its newsroom system to run on a separate network from the rest of the building, and the network design does not allow any traffic to pass from the firewall to the newsroom system. In this scenario, the newsroom system login screen is not accessible to the outside world — the firewall blocks all access.
At the start of the VPN session, the reporter's laptop is connected to the Internet. The laptop has been assigned a public IP address of 68.243.49.223 by the hotel's ISP. At this point, the reporter can access the Internet, run a Web browser and perform other functions, but the reporter cannot access the newsroom system. The firewall at the station prevents him or her from seeing the inside network on which the newsroom system is located.
When the reporter starts the VPN client and begins the VPN login process, several important steps occur. (Note: This is a simplified description.)
First, the VPN client verifies that the VPN-capable router is available at the station. Second, the VPN client asks the reporter to log in, preventing unauthorized access of the VPN if the laptop is stolen.
Third, the VPN client and router communicate, verifying the login data is correct and then applying any policies for the VPN link that have been established by the network engineer. Finally, the VPN client reports that it is connected to the VPN.
When the process is complete, several changes have taken place on the reporter's laptop. First, all communications over the VPN are now encrypted, and the only communications between the laptop and the outside world occur over the VPN back to the station. The laptop can no longer communicate directly with other computers on the Internet without those communications first going over the VPN back to the station and then through the station's firewall out to the Internet. This helps to protect the laptop from attack by applying the same security policies to the laptop as have been established for other computers within the station.
Second, the laptop has been assigned a new IP address within the station's VPN pool. In other words, the laptop now thinks it is attached to a network behind the station's firewall. In this example, the network address assigned to the laptop is 10.35.2.11.
As Figure 2 shows, the station has two separate networks. The newsroom network is 10.35.1, and the VPN network is 10.35.2. Computers connected to the networks are given addresses between 0 and 255. So the main newsroom computer's IP address might be 10.35.1.0. At this point, the laptop is connected to the VPN, and it thinks it is inside the firewall on the 10.35.2 network.
Because of the way IP works, the laptop still cannot see the newsroom system, which is on a separate network (10.35.1). Earlier, I mentioned that during the VPN login process, security policies were applied to the connection. Parts of these policies establish which IP addresses get assigned to VPN clients and which routes are established between various networks.
In this case, when the laptop connects to the VPN, a predefined route is established between the 10.35.2 network and the 10.35.1 network. This means the router automatically knows about both networks and effectively connects the two networks so traffic can flow back and forth between the VPN network and the newsroom network.
Now the reporter enters the internal (non-public) URL of the newsroom system in her Web browser. She is presented with the login screen, and she is ready to go.
Caveats
A few notes are in order. First, for those of you who are more advanced at networking, it is more efficient to use sub-netting rather than to use three completely separate networks. Also, DHCP would need to be configured to assign the correct group of IP addresses to the VPN clients so they can access the newsroom system.
Second, this is but one of many ways to configure access to newsroom systems. If your newsroom vendor uses some other secure access technology, this is perfectly fine. I selected the newsroom system as an example that would be familiar with many readers.
Finally, I will write about IP addressing schemes in next month's introduction to networking article, so you might want to reread this column once you have read January's column in order to understand how sub-netting might be a better way to go.
Brad Gilmer is executive director of the AAF Association, executive director of the Video Services Forum and president of Gilmer & Associates.
