I Like IKEv2 (And so should you!)

Just when you thought that you were getting the hang of IKEv1, IKEv2 came along and threw a wrench in your well-oiled VPN configuration machine. IKEv1 works just fine, so what’s the point of a second version? Well, unlike most Hollywood movie remakes, the newest version of IKE contains many improvements:

1. It’s more efficient. IKEv2 reduces the number of messages that must be exchanged to setup a VPN tunnel, which means tunnels can be setup faster and with less bandwidth.
2. It’s more reliable. There’s a built-in liveness check in IKEv2 to detect when the tunnel goes down.
3. It protects against DoS attacks. Unlike in IKEv1, an IKEv2 responder doesn’t have to perform significant processing until the initiator proves it can receive messages at its advertised IP address.
4. NAT-T is built-in. You don’t have to worry about finding that obscure checkbox to enable it like you did with IKEv1. NAT-T, or NAT Traversal, is required when a VPN endpoint resides behind a router that performs NAT. IPsec tunnels send data using the Encapsulating Security Payload (ESP) which is not compatible with NAT. Therefore, NAT-T is used to encapsulate the ESP packets in UDP which can then be routed over NAT.

And these are only a few examples. RFC 4306, the proposed standard that introduced IKEv2 back in 2005, lists 14 changes from IKEv1 in Appendix A.

IKEv2: Better, Yet Familiar

If you take away anything from all this, it’s that IKEv2 should be used over IKEv1 whenever possible. And no, not knowing how to setup an IKEv2 tunnel is no excuse to go back to IKEv1. IKEv2 is, after all, based on IKEv1, so the configuration should be very familiar to you.

To get an idea of how closely related IKEv1 and IKEv2 are, check out a comparison of strongSwan configurations for IKEv1 and IKEv2 tunnels. In case you’re interested, strongSwan is an open-source IPsec solution for multiple operating systems, including Windows and Mac OS.

conn cato-vpn
        auto=add
        compress=no
        type=tunnel
        keyexchange=ikev1
        fragmentation=yes
        forceencaps=yes
        ike=aes256-sha1-modp1024
        esp=aes256-sha1
        dpdaction=clear
        dpddelay=300s
        rekey=no
        left=172.16.1.62
        leftid=54.183.180.107
        leftsubnet=172.16.1.0/24
        right=45.62.177.115
        rightid=45.62.177.115
        rightsubnet=172.17.3.0/24
        authby=secret

conn cato-vpn
        auto=add
        compress=no
        type=tunnel
        keyexchange=ikev2
        fragmentation=yes
        forceencaps=yes
        ike=aes256-sha1-modp1024
        esp=aes256-sha1
        dpdaction=clear
        dpddelay=300s
        rekey=no
        left=172.16.1.62
        leftid=54.183.180.107
        leftsubnet=172.16.1.0/24
        right=45.62.177.115
        rightid=45.62.177.115
        rightsubnet=172.17.3.0/24
        authby=secret
 

Spot the difference? Hint: it’s only a single number. Simply changing the keyexchange value from ikev1 to ikev2 is enough to convert strongSwan from IKEv1 to IKEv2.

​Note: ​​You may set the IPSec shared secret (​PSK​​) up to 64 characters for both IKEv1 and IKEv2 sites.

Switching from IKEv1 to IKEv2 in the Cato Management Application

Creating an IKEv2 site or migrating from IKEv1 to IKEv2 in Cato is just as simple. The steps required to migrate from an IKEv1 to IKEv2 tunnel are listed below.

1. The site’s Connection Type needs to be changed from IPsec IKEv1 to IPsec IKEv2 from Configuration > Sites > [site name] > General in the Cato Management Application.
   
   WARNING! The site’s Native Range and other networks will be lost when switching the Connection Type, so make sure you have them written down somewhere.

2. Enter the Native Range and any other remote networks under the Networks section. These are the remote traffic selectors.
3. Select the Primary Source (Egress) IP and enter the Primary Destination IP of the remote VPN gateway under the IPsec IKEv2 section.

4. Enter the PSK in the Password field under Set/Change Primary PSK.

5. Enter the local traffic selectors under Network Ranges. These should all be networks already configured at other sites connected to Cato or the Cato VPN range.

6. Check the Should Cato initiate connection box to have Cato initiate the VPN connection. This configuration is optional but recommended because the remote VPN gateway may not be configured to initiate the connection.

7. Set the Init Message Parameters and Auth Message Parameters as needed. You can leave every field set to Automatic except for the Diffie-Hellman group if desired.

You might have noticed that the Init and Auth message parameters are almost identical to the Phase 1 and Phase 2 parameters in IKEv1, but there is both a PRF and Integrity algorithm configuration option in IKEv2. Most vendors do not support different PRF and integrity algorithms, so if in doubt, set them to Automatic or make sure that they’re set to the same value.

8. Save the configuration.

IKEv2: The Final Frontier

These days, there is really only one reason to party like it’s 1999, or to be precise, 1998, when IKEv1 was first defined by the IETF: if at least one side of the VPN connection is terminating on a legacy device that only supports IKEv1. The major cloud providers (AWS, GCP, Azure, Alibaba Cloud), currently support IKEv2. So, unless you are connecting to an older VPN endpoint, IKEv2 should be your first choice when setting up VPN tunnels.