A virtual private network, or VPN, is a connection established between two peers such that each can behave as if they are on the same subnet. VPN is very commonly used to connect remote workers to a corporate network so they can access email, files, and network resources when away from headquarters where these resources typically reside.

Figure 1: Teleworker VPN extends the corporate network to the branch or home office

Road warriors rely heavily on VPN and depend on its security and reliability. Luckily for them, they don’t have to deal with the complexity of configuring and managing VPN. Unfortunately, VPN deployment is no easy task for any IT administrator. Until now, that is. Meraki’s new Teleworker VPN makes configuration and deployment painless, and it even eliminates some previously required hardware components entirely.

1-2-3

This is how easy it is to get VPN up and running:
1) Download the VPN virtual concentrator from the dashboard and install it in a VMware virtual machine

Figure 2: download VM image for VPN concentrator

2) Click “Enable VPN” on the Network-wide settings page

Figure 3: tunnel AP traffic back to VPN concentrator with one click

3) That’s it! Any access point on this network will now have a VPN connection back to the corporate network, and it will be completely transparent to the user.

There is no client-side software to install, no VPN concentrator box to manage at headquarters, no messy provisioning on each client machine. The remote worker connects to the Meraki access point and sees all the network resources that are available when physically located at headquarters.

Meraki’s cloud-based architecture makes this all possible. Access points automatically traverse NAT and firewall settings using a technique called hole punching. This allows the APs to find and connect to the cloud controller for configuration and establish the secure link to the corporate network for VPN traffic. There is no AP provisioning needed from the IT administrator, and the APs receive and install the correct configuration for their network automatically.

Some background: IPsec

Let’s take a look at just a bit of what happens behind the scenes when using a VPN link via IPsec.

IPsec is a group of protocols that provides mutual authentication and encryption between trusted peers so that an end-to-end connection can be secured. It operates at the IP layer, meaning any application that uses IP can be protected by IPsec, and applications do not have to be redesigned or adapted to be secured.

VPN has many, many options and controls. Some of them handle authentication and identity functions, while others handle encryption and securing of data. Instead of exhaustively going over each, it’s best to first gain an understanding of a commonly implemented form of VPN. A simple way to understand what happens in VPN via IPsec is to look at the packets in encapsulating security payload (ESP), a common type of encryption and authentication. Tunnel mode of ESP is used when connecting a remote user to a network or when connecting two routers that link sites.

Peeling the onion: packets within packets

Consider first a normal, unsecured IP packet. The major structural parts of the packet are the header and the payload. The header has many components, but for this discussion, the most interesting one is the protocol field. This field describes the protocol of the information contained in the payload. Very often the payload contains a TCP datagram, so the IP header will indicate protocol 6, for TCP.

The IP payload then contains the TCP datagram: a TCP header and TCP payload. This is the same TCP/IP packet type that is so widely used over the Internet today.

Figure 4: original, unprotected packet

This method provides no security for the communicating parties. An eavesdropper could view packets on the wire and listen to the conversation between a source and destination. Clearly, this is not suitable for private communications where sensitive data needs to be exchanged. That’s where VPN comes in.

In a configuration providing a VPN over IPsec using ESP, IPsec takes an IP packet, secures it completely (including IP header and payload), and wraps it in a new payload format, called encapsulated security payload. It attaches a new IP header and modifies it to point to a payload (ESP), instead of the original unprotected IP protocol payload. The original IP packet, including header and payload, become the new payload data contents of the encapsulated security payload. ESP also includes a trailer, after the payload, that includes some padding and points to the payload type (in this case, TCP). Authentication is optional with ESP, but highly recommended. When using authentication, a few more bits of information are added to the ESP trailer.

Figure 5: IPsec encrypts and protects the original packet

That summarizes the packet structure when using IPsec with ESP. But one might wonder how, exactly, is the information actually protected? The data of interest, now part of the encapsulated security payload, is still inside the packet. How is it protected from prying eyes? To find out, we need to peel another layer of the VPN onion.

Security associations

Using encryption and authentication requires that each peer verify the identity of the other and have some way to de-encrypt the desired data. This means they must have knowledge of secret keys, algorithms used, and protocols used (for example, AH or ESP). Security associations are simply parameters that describe the algorithms, secrets, and keys used in a one-way connection. Naturally, most connections are two-way, so a pair of security associations is required in the case of IPsec with ESP. These parameters are stored in the security associations database (SADB). The SADB keeps track of a large number of parameters, including the ESP encryption secret key, the ESP encryption algorithm, and the ESP authentication enabled flag.

If data is protected using encryption and authentication, and if encryption/decryption is performed using secrets, it follows that knowledge of the secrets is a very critical requirement for ESP to function properly. The transfer of knowledge of the secrets must be done in a secure way so that unwanted parties do not learn it. There are several ways to do this, ranging from manual installation to key management protocols. Key management protocols allow for the secure exchange of keys (and other security association parameters) without the need for manual installation, making them suitable for large-scale deployment and configuration.

Choose your encryption algorithm

ESP itself does not specify the algorithm to use for encryption, but instead lists several from which to choose. A very commonly used algorithm is AES-CBC: advanced encryption standard with cipher block chaining (mode). AES was selected by the USA’s National Institute of Standards and Technology (NIST) as the government’s dedicated encryption cipher, with the expectation that it protects unclassified, sensitive information at least until the next century. AES is commonly used with 128-bit or 256-bit key sizes, making attacks extremely processing intensive and thus completely impractical. Another common algorithm is TripleDES, or 3DES, which is based on the data encryption standard (DES). DES was found to have weak keys, but TripleDES gets around this by processing each data bit block three times in a chained fashion.

Identity

Even if information is encrypted, it’s still necessary for each peer to establish and verify the identity of the other party. When using ESP with authentication, as is recommended, a commonly used authentication algorithm is HMAC-SHA1-96: hashed message authentication code with secure hash algorithm 1, using a 96 bit-long authenticator, and operating on 64-byte sized blocks of data. It ensures the packet authenticity and that it cannot be altered while in transit.

Peeling even more layers

There are many more details that are involved in making a VPN connection work properly and securely, but they are out of scope for this article. The key exchange methods and protocols, for example, can provide protection from attacks and can even protect future keys from being stolen by unauthorized parties holding a current key. Another topic ripe for illustration is how peers initiate communication in the first place – the discovery process.

This article discusses one type of VPN, remote access. Site-to-site VPN is another type of connection and is used to connect two fixed locations between gateway points, replacing leased-line WAN connections. Meraki’s MX router has integrated site-to-site VPN capability and is as easy to turn on as the Teleworker VPN shown here. More information is on our website at http://meraki.com/products_services/vpn/.