Having access to all the digital resources you might need, no matter where you are or what sort of network connection you have, has become a way of life for most. Whether you’re a business sharing data with other businesses, or a traveler who needs to stay in touch at all times, access to resources is simply taken for granted.
While applications hosted in the public cloud go a long way towards making location a non-issue, many resources are hosted privately for reasons such as security and privacy. Access to these private resources is often handled through VPNs (virtual private networks).
VPN technology is a straightforward idea: securely connect someone you trust to a resource they need via a network you don’t trust.
The trick comes in knowing what type of VPN to use when. Let’s consider several different VPNs and think about where they fit. We’ll look at two main classes of VPN, what I’ll term client-based VPNs and network-based VPNs.
Client-based VPNs
A client-based VPN is a virtual private network created between a single user and a remote network. There’s often an application involved to make the VPN connection.
In most scenarios, the user manually starts the VPN client, and authenticates with a username and password. The client creates an encrypted tunnel between the user’s computer and the remote network. The user then has access to the remote network via the encrypted tunnel.
Examples of client-based VPN applications include Cisco’s AnyConnect, Pulse (formerly Juniper), and Palo Alto Networks’ GlobalProtect.
Windows, Mac, and mobile operating systems often have standards-based VPN client options built-in. For example, Mac OS X 10.10 includes L2TP (Layer 2 Tunneling Protocol) over IPsec and PPTP (Point-to-Point Tunneling Protocol). Even Cisco IPsec, which is standards-based plus some Cisco enhancements, is an included option for Mac users.
Note that while IPsec was the client VPN protocol of choice for many years, SSL is more often used these days. For example, Cisco no longer updates their legacy IPsec client. Instead, Cisco’s premier client VPN solution, AnyConnect, uses SSL.
Client-based VPN apps make it easy for your users to connect their laptops or mobile devices to your private resources from anywhere. For example, I use a VPN client on my iPhone, iPad, and Mac to connect to headquarters when I’m traveling. This allows me to manage my network remotely across the secure VPN tunnel that’s been stood up between my device and the headquarters firewall.
In addition to basic connectivity, VPN clients often offer enhanced security features. One is the ability to carefully inspect a user’s device before allowing them onto the network. For example, during the authentication process, the Cisco AnyConnect client can verify (among other things) that the device has a particular version of anti-virus software installed and is part of a specific Windows domain. This provides IT teams the ability to reject client VPN devices for reasons other than simple authentication failure.
Premium VPN clients come at a licensing cost. While the client software might be free, the firewall is typically licensed by the number of simultaneous VPN connections that are allowed. For example, you might have 1,000 VPN clients deployed to your users’ devices, but only need to license the firewall to support 500 of those at any given time.
Network-based VPNs
Network-based VPNs are virtual private networks that securely connect two networks together across an untrusted network. One common example is an IPsec-based WAN, where all the offices of a business connect to each other across the Internet using IPsec tunnels.
There are several kinds of network VPNs. We’ll look at three of the most common:
- IPsec tunnels, both route-based and policy-based
- Dynamic multipoint VPNs
- MPLS-based L3VPNs
IPsec Tunnels
The simplest kind of network VPN is the standards-based IPsec tunnel, and most network routers and firewalls are capable of building one.
In principle, the tunnel on a network-based VPN is no different from a client-based IPsec tunnel. Both network and client implementations create a secure tunnel through which encrypted traffic flows between networks. While the client-based IPsec tunnel is designed to encapsulate traffic for a single device, the network-based IPsec tunnel carries traffic for entire networks of devices, allowing them to communicate.
When building an IPsec tunnel between two networks, the following things need to be agreed upon:
- Which two devices will be the endpoints of the tunnel? (Who will do the talking?)
- How will the tunnels be authenticated? (How will we trust each other?)
- What traffic will be allowed to flow through the tunnel? (What will we talk about?)
Who will do the talking? The answer is usually a pair of single IP addresses. One firewall administrator configures the other’s IP address as a peer IP.
How will we trust each other? Most often, the answer is a pre-shared key — a password — or a certificate exchange. The two endpoints must also agree on how traffic will be encrypted by using a common set of ciphers.
What traffic will be allowed to flow through the tunnel? In Cisco parlance, the most common way to specify allowed traffic is to use a crypto access list (ACL). The crypto ACL defines source IP networks that can talk to destination IP networks. Both sides of the tunnel must have matching elements (IP network pairs) for a security association to form and the tunnel to carry the traffic as expected.
IPsec tunnels that use some flavor of crypto access lists to define the traffic that can flow through them are generically termed policy-based VPNs.
The catch with policy-based VPNs is that the crypto access lists require maintenance to keep up with the demands of the business. If a new IP network comes online that needs to access a network on the other side of the tunnel, the crypto access list must be updated on the devices on either side of the tunnel.
Use policy-based IPsec tunnels when you need to build a single tunnel between two sites to provide carefully controlled access to resources. I’ve used policy-based IPsec tunnels in the following situations:
- To connect to another company doing work for my company
- As a backup to a private link between remote offices
- As a temporary connection to a new facility brought online during a corporate merger
- As a connection for employees in a home office
In contrast to policy-based IPsec tunnels, route-based IPsec tunnels are more like a virtual link, allowing any traffic to flow through them. Route-based VPNs are available from many different networking vendors, including Cisco and Juniper. However, the availability varies by platform. For instance, the Cisco ASA doesn’t support route-based VPNs.
Although IPsec VPNs are standards-based, it’s unfortunately common for vendors to implement the standards differently. Therefore, bringing up an IPsec VPN tunnel between devices from two different vendors is a sort of rite of passage for network engineers.
I’ve spent many an hour trying to bring up IPsec tunnels between Cisco gear and Checkpoint or Juniper gear. It can be done, but it’s often tricky combing through configuration details and log messages to find the problem that’s preventing the tunnel from forming.
Dynamic Multipoint VPN (DMVPN)
The current version of DMVPN expands the idea of IPsec point-to-point tunnels into a cloud of connected networks. With DMVPN, any network can talk to any other network directly across the DMVPN cloud.
Implementing DMVPN requires devices that can terminate a DMVPN tunnel. DMVPN is a Cisco technology, and for the most part, that means DMVPN is limited to Cisco routers. Despite their popularity, Cisco ASA firewalls are not DMVPN-capable.
DMVPN is a complex technology, requiring the use of GRE tunnels, IPsec, NHRP (Next Hop Resolution Protocol), and a routing protocol, all interdependent components that allow full mesh communication. To ease the complexity, Cisco offers an excellent DMVPN design guide that can help network architects determine the most appropriate design for their environment, along with baseline configurations.
Use DMVPN to connect remote sites to a larger corporate network across the public Internet using a standard router configuration that’s hands-off once completed. For example, I’ve used DMVPN routers for home office users to provide redundant connectivity to head-end sites and minimize latency for voice calls between sites. Accomplishing either the head-end redundancy or latency reduction is not possible (in a practical sense) with traditional IPsec point-to-point VPN tunnels.
DMVPNs eliminate the need to know remote IP addresses, allowing for dynamically assigned IPs to connect to the infrastructure securely, registering their IP address with the DMVPN NHRP hub router. This allows the solution to scale as high as thousands of participating sites. The end result feels like a traditional WAN connection.
MPLS-based L3VPN
As a bonus, I thought I’d briefly mention L3VPNs, the most commonly deployed application over multiprotocol label switched (MPLS) networks.
MPLS is most often found in service provider networks such as those operated by AT&T, Verizon Business, Level 3, and CenturyLink. MPLS allows service providers to virtualize their networks so customers can share the physical network but still be kept logically separate. MPLS is not limited to service providers; some large enterprises use MPLS internally for their own global infrastructures.
If your company obtains WAN service from a service provider, the service provider is most likely offering L3VPN services over their MPLS network to your company. In this scenario, each office in your company connects to the service provider through what the service provider sees as a customer router — the one that connects the WAN circuit from the service provider to the rest of your network.
On the other end of the WAN circuit is the provider edge (PE) router. The PE router drops traffic from your company’s circuit into a virtual route forwarding (VRF) instance that’s unique to your company, and then forwards it into a provider core router, using MPLS to tag the traffic and identify the VRF the traffic belongs to.
The provider core delivers the traffic across their core to another PE router, then to another one of your WAN routers, where your router then delivers the traffic to the remote office network.
To your company, this L3VPN is invisible. You don’t have to run MPLS. You don’t see how the traffic is being forwarded securely across the provider’s backbone. You might peer with the provider using OSPF or BGP routing to announce your routes to them, which they’ll carry in the VRF uniquely assigned to you. But aside from that, you only know that your traffic goes in one router and comes out another.
Buy L3VPN service from a provider when you need national or international connectivity between your remote offices, and must have a guarantee of service.
While building DMVPN across the Internet is a viable connectivity solution, Internet service might not be as robust as your company needs, depending on your requirements. A service provider can prioritize voice and video traffic (assuming it’s been marked appropriately), while the Internet can’t make such a differentiation.
On the other hand, Internet bandwidth is remarkably cheap when compared to private WAN bandwidth running over a carrier’s L3VPN service. For this reason, many enterprises are accepting the risk of poor network quality from time to time, and retiring their private WANs in favor of some flavor of VPN over the Internet.