How to Select the Appropriate VPN Configuration for a Junos Device

The first decision you should make when determining how to deploy your VPNs is whether IKE will be used to negotiate the VPN keys, or whether to use manual keys. For just about every scenario, AutoKey IKE should be used over manual key encryption because AutoKey IKE is dynamic and renegotiates the keys used rather than using the same key indefinitely. The only exception to this rule is if security isn’t much of a concern, due to the impact that AutoKey negotiation would put on your system. Although individual IKE negotiation may not put much load on the system, negotiating lots of VPN tunnels simultaneously can be very computationally intensive, thus making manual keys preferable.

ESP is the most widely deployed VPN protocol because it not only performs authentication, but also provides security by encrypting the data. Although encrypting the data is a computationally intensive process, it typically can be offloaded by using some hardware acceleration. Therefore, unless there is a specific reason to only provide authentication, ESP should be used to provide both encryption and authentication.

Tunnel mode is the most common mode for VPN site-to-site encryption, particularly when going over the Internet. Since Tunnel mode encapsulates the original packet within the encrypted tunnel packet, it allows communication between two privately addressed hosts over a public network (the Internet). Both Tunnel mode and Transport mode allow for encryption, but Tunnel mode does have more overhead in terms of packet size because it must add an additional IP header to the packet on top of the ESP or AH header. Transport mode may be desirable when there is host-to-host IPsec traffic rather than gateway-to-gateway traffic, or when IPsec traffic is communicating over a private network. Transport mode has become popular as a solution for IPsec encryption of multicast traffic, as the contents of the data remain confidential, but the packets can be routed and replicated in the network. If there is any doubt as to which mode should be used, Tunnel mode should be selected.

The rule of thumb when it comes to Main mode versus Aggressive mode is that if both nodes have a static IP address (or an address which can be resolved via Domain Name System [DNS]), Main mode should be used. However, if a gateway or host has a dynamic IP address, typically Aggressive mode should be used for the best interoperability (although depending on the implementation of the VPN gateways Main mode may be able to be used).

Diffie-Hellman key exchange is used to negotiate Phase 1 and PFS aspects of IPsec. The larger the key, the more difficult it will be to compromise the security of the negotiation, but the more computationally intensive the negotiation will be. Typically, Diffie-Hellman Group 2 is considered secure at the time of this writing, although larger key lengths (e.g., Group 5, 14, etc.) are more secure, but may be unnecessary. Remember that Diffie-Hellman is used to negotiate the secure channel to negotiate the Phase 2 keys, but does not actually encrypt the data itself.

As previously discussed, you can authenticate IPsec peers in two ways: via preshared keys and via certificates. Preshared keys are easier to deploy, and are the most common form of authentication. Certificates are a very powerful form of authentication, as you can scale them to large implementations and you can revoke certificates and authenticate certificates dynamically. Certificates do have a certain amount of overhead when it comes to generation, signing, checking status, and renewing, however, and therefore they are most commonly used for large implementations. When just using simple site-to-site VPNs, or VPNs between other organizations, preshared keys are easier to use. If you are deploying site-to-site or client VPNs within an organization on the scale of several hundred or several thousand, certificates should be examined, as they provide some scaling advantages.

IKE identity is commonly overlooked as a major component of a VPN; however, it is important to select the appropriate IKE identity. The IKE identity essentially acts as the username for the IKE authentication in a roundabout way. Typically, when both sides of a site-to-site VPN have static IP addresses, the IKE identity is the IP address for both nodes. When a single node is using a dynamic IP address, that node typically uses the Hostname attribute, which can be a simple name to identify the peer. But when a user is connecting to a gateway, that user should use the UFQDN. It is important to make sure both sides can properly authenticate the other peer with the method that the other side is expecting, as a mismatch or improper IKE identity causes failure.

When selecting the VPN encryption algorithm, the important things to remember are the sensitivity of the data within the VPN, the amount of data that is sent over the VPN in terms of throughput, and whether the algorithm that is used will be accelerated by hardware. DES is largely considered to be an obsolete encryption algorithm by today’s standards because the key space is only 56 bits and it can be broken with modern computers in a few months’ time. 3DES and AES are widely considered to be much better algorithms and are secure against attacks with modern computer hardware. If the data is extremely sensitive and needs to be protected against attacks under extremely powerful computing power, both now and in the future, you should use an algorithm such as AES-256; otherwise, 3DES or AES-128 should be sufficient for most scenarios.

The VPN authentication algorithm is used to create a hash of the traffic to ensure that it has not been modified or forged. Two hash algorithms are implemented in the SRX at the time of this writing: MD5 and SHA-1. SHA-1 is considered to be a stronger hash algorithm than MD5, and since both are implemented in hardware, it is recommended that you use SHA-1 rather than MD5, although MD5 isn’t necessarily an obsolete algorithm.

PFS is a mechanism used to renegotiate the Phase 1 keys over an established Phase 1 channel. It is primarily meant to help provide additional security to Aggressive mode authentication where the IKE identities are negotiated in clear text, but it can also be used to renegotiate Phase 1 for additional security. It is recommended that you use PFS when using Aggressive mode, or in the most sensitive of security environments, and it is very important to choose the correct preshared key (if you’re using preshared keys), along with the proper encryption and authentication algorithms.

Policy-based VPNs are common when configuring simple site-to-site VPNs or remote access VPNs, especially when interoperating with VPN products from other vendors. When only a few VPNs are needed, or if the VPNs are simple, it might make sense to use policy-based VPNs because they are easier to set up and have fewer components (from a configuration perspective) than route-based VPNs. When you’re setting up a VPN infrastructure with a large number of remote access tunnels, or when multicast or dynamic routing protocols are used, you should use route-based VPNs. In general, route-based VPNs are more powerful than policy-based VPNs, so they are generally preferred over policy-based VPNs, but simple implementations can still utilize policy-based VPNs.

To help ease configuration, the SRX has predefined proposal sets for both Phase 1 and Phase 2 IKE negotiations. You can choose to use these predefined sets or create your own. It is really just a matter of preference. There are three predefined proposals: basic, standard, and compatible. Typically, it is best to just define your own, since it takes the guesswork out of configuring the VPNs, especially if you are establishing a VPN to another vendor (which may not use the same terminology). Additionally, if you use predefined sets, you might have to go through several proposals with the peer before finding a match (which would leave a log trail as well), so it is best to just configure identical proposals as the peer.