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 a given.
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 fairly straightforward idea: securely connect someone you trust to a resource they need via a network you don’t trust.
Windows, Mac, and mobile operating systems often have standards-based VPN client options built-in. For example, Mac OS X 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.
The trick comes in knowing what VPN type to use when. Let’s consider several VPN types and think about where they fit. We’ll look at two main VPN types, what I’ll term client-based VPN and network-based VPN.
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 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.
What’s the benefit?
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 offer enhanced security features. One is the ability to carefully inspect a user’s device before allowing them onto the network. 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 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, Dynamic multi point VPNs, and MPLS-based L3VPNs.
1. IPsec Tunnels
In principle, a network-based VPN tunnel 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.
What’s the benefit?
The simplest kind of network VPN is the standards-based IPsec tunnel. Most network routers and firewalls are capable of building one.
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?). 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 the tunnels be authenticated? (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? (What will we talk about?). 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, generically termed policy-based VPNs.
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 networking vendors, including Cisco and Juniper. However, the availability varies by platform.
Although IPsec VPNs are standards-based, it’s 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.
2. Dynamic Multi point 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.
What’s the benefit?
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.
You can 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.
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.
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.
3. MPLS-based L3VPN
As a bonus, I thought I’d briefly mention L3VPNs, the most commonly deployed application over multi protocol label switched (MPLS) networks.
MPLS is most often found in service provider networks. 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.
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.
What’s the benefit?
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. Buy L3VPN service from a provider when you need national or international connectivity between your remote offices, and must have a guarantee of service.
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. Likewise, 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.
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.