Cato IPsec Guide: IKEv1 vs IKEv2

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.

IKEv1

IKEv2

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.

To migrate a site from an IKEv1 to IKEv2: tunnel:

  1. On the ​Network > Sites​​ screen, select the site you want switch from IKEv1 to IKEv2.
  2. On the Site Configuration > General page, change the Connection Type from IPsec IKEv1 to IPsec IKEv2 from.

    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.
  3. On the ​Network > Sites > [site name] > Site Configuration > Networks​ page, enter the Native Range and any other remote networks. These are the remote traffic selectors.
  4. On the ​Network > Sites > [site name] > Site Configuration > IPsec page, under the ​Primary​ section, select the ​Cato IP (Egress) IP​ and enter the ​Site IP​​ of the remote VPN gateway.
  5. Enter the PSK in the Password field under Set/Change Primary PSK.


  6. Expand the ​Routing​ section, add the routing option for the site under ​Network Ranges​​. These should all be networks already configured at other sites connected to Cato or the Cato VPN range.
  7. Select the ​Initiate connection by Cato​​ checkbox so Cato initiates the VPN connection. This configuration is optional but recommended because the remote VPN gateway may not be configured to initiate the connection.
  8. (Optional) Expand the ​​Init Message Parameters​​ section, and configure the settings. As most IPsec IKEv2-supporting solutions implement automatic negotiation of the following Init and Auth parameters, Cato recommends setting them to Automatic unless specifically instructed to by your firewall vendor.
    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.
  9. Click Save.

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.

Was this article helpful?

3 out of 3 found this helpful

0 comments

Add your comment