IKEv2 has been published in RFC 5996 in September 2010 and is fully supported on Cisco ASA firewalls. In this lesson you will learn how to configure site-to-site IKEv2 IPsec VPN. If you haven’t seen it before, in a previous lesson I showed you how to configure IKEv1 IPsec VPN.
We will use the following topology for this example:
ASA1 and ASA2 are able to reach each other through their “OUTSIDE” Ethernet 0/1 interfaces. Their Ethernet 0/0 interfaces are the “INSIDE” where we have R1 and R2. The goal is to configure IKEv2 IPSEC site-to-site VPN between ASA1 and ASA2 so that R1 and R2 are able to reach each other.
First we will configure the IKEv2 policy which is similar to phase 1 of IKEv1.
IKEv2 Policy Configuration
Here’s what it looks like for both ASA firewalls:
ASA1 & ASA2# (config)# crypto ikev2 policy 10 ASA1(config-ikev2-policy)# encryption aes ASA1(config-ikev2-policy)# group 2 ASA1(config-ikev2-policy)# prf sha ASA1(config-ikev2-policy)# lifetime seconds 86400
The configuration is similar to the IKEv1 policy, the only new command is prf sha. PRF is the Pseudo Random Function algorithm which is the same as the integrity algorithm.
IKEv2 IPSEC Proposal
This section is similar to phase 2 of IKEv1 where we have to configure a transform set. For IKEv2 we call this the IPSEC proposal which is configured like this:
ASA1 & ASA2# (config)# crypto ipsec ikev2 ipsec-proposal MY_PROPOSAL (config-ipsec-proposal)# protocol esp encryption aes (config-ipsec-proposal)# protocol esp integrity sha-1
We will use ESP, AES as the encryption algorithm and SHA for integrity. Next step is to configure an access-list that defines what traffic we will encrypt:
ASA1(config)# access-list LAN1_LAN2 extended permit ip host 192.168.1.1 host 192.168.2.2
ASA2(config)# access-list LAN2_LAN1 extended permit ip host 192.168.2.2 host 192.168.1.1
Now we have to configure a crypto map that combines the access-list, remote peer and IKEv2 proposal together:
ASA1(config)# crypto map MY_CRYPTO_MAP 1 match address LAN1_LAN2 ASA1(config)# crypto map MY_CRYPTO_MAP 1 set peer 10.10.10.2 ASA1(config)# crypto map MY_CRYPTO_MAP 1 set ikev2 ipsec-proposal MY_PROPOSAL ASA1(config)# crypto map MY_CRYPTO_MAP interface OUTSIDE
ASA2(config)# crypto map MY_CRYPTO_MAP 1 match address LAN2_LAN1 ASA2(config)# crypto map MY_CRYPTO_MAP 1 set peer 10.10.10.1 ASA2(config)# crypto map MY_CRYPTO_MAP 1 set ikev2 ipsec-proposal MY_PROPOSAL ASA2(config)# crypto map MY_CRYPTO_MAP interface OUTSIDE
The crypto map is called “MY_CRYPTO_MAP” and it specifies the access-list, remote peer and the IKEv2 proposal. It has been attached to the OUTSIDE interface.
The next step is to configure a tunnel group. This is where we define authentication and the pre-shared-key:
When would one use IKEv2 over IKEv1? What are the main differences in using one over the other?
Nowadays you should always use IKEv2 (if possible). It supports a couple of things that IKEv1 doesn’t.
- IKEv2 uses fewer messages than IKEv1 to establish the tunnel and uses less bandwidth.
- IKEv2 has built-in support for NAT traversal.
- IKEv2 has a built-in keepalive mechanism (Dead Peer Detection).
- IKEv2 supports EAP authentication.
- IKEv2 has some built-in mechanisms against DoS attacks.
In short, there’s no reason to use IKEv1 anymore unless you have older equipment that doesn’t support IKEv2 for some reason.
Is there any possibiltity you create any post about ssl/tls tecnology??
Here’s a good example for SSL:
The only other thing I had to do to get this working at work is configure NAT exemptions