ASA IKEv2 Multi-Peer VPN

Overview

High Availability VPN can be achieved on a Cisco ASA firewall using multi-peer crypto map, previously this feature was only supported on the ASA using IKEv1/ISAKMP not IKEv2. As of ASA version 9.14 this feature is now supported on IKEv2.

Multi-peer crypto map allows the configuration of up to a maximum of 10 peer addresses to establish a VPN, when a peer fails and the tunnel goes down, IKEv2 will attempt to establish a VPN tunnel to the next peer. The VPN’s are Active/Standby, only 1 tunnel per crypto map sequence will be active. To detect tunnel failure, when a peer VPN tunnel goes down, the ASA will transmit 5 x SA_INIT packets to the peer, if after the final retransmit the peer is still unreachable it will attempt to establish a connection to the next peer by sending an SA_INIT. In total this takes approximately 2 minutes to failover.

Figure 1 – IKEv2 Multi-peer failover process

Refer to the Cisco ASA 9.14 documentation for more information
https://www.cisco.com/c/en/us/td/docs/security/asa/asa914/configuration/vpn/asa-914-vpn-config/vpn-ike.html

Topology

The diagram below represents the topology used in this guide. There are 2 sites (DC and Branch1), the DC has 2 ASA firewalls with 2 different ISP connections, Branch1 has 1 ASA and 1 ISP connection. Branch1 ASA will be configured with 2 peer IP address in the crypto map configuration, DC-1 ASA (1.1.1.90) will be the primary peer and DC-2 ASA (1.1.2.90) will be the backup/secondary peer. Under normal operations Branch1 ASA will establish a VPN tunnel to the primary peer (DC-1 ASA), once bi-directional IPSec SAs have been established, DC-1 ASA will install the Branch1 networks into it’s routing table, by the use of reverse route injection (RRI). These routes will be redistributed into the DC LAN, for the DC core switch to route the Branch1 VPN traffic to the correct ASA.

In the event the primary peer (DC-1 ASA) fails, a VPN will be established to DC-2 ASA (1.1.2.90). DC-2 ASA will then advertise the Branch1 networks in it’s routing table and redistribute to the core switch, in order for the DC LAN to route traffic destined to Branch1 via DC-2 ASA, instead of via DC-1 ASA.

The ASAs in this scenario will be using IKEv2, therefore ASA version 9.14 software image must be utilised.

Figure 2 – Toplogy diagram

Configuration

Common Configuration

The following configuration is common amongst all ASA used in this scenario.

Configure IPSec Proposal

crypto ipsec ikev2 ipsec-proposal AES-GCM
 protocol esp encryption aes-gcm-256 aes-gcm-192 aes-gcm
 protocol esp integrity null

Configure IKEv2 Policy and enable on OUTSIDE interface

crypto ikev2 policy 10
 encryption aes-gcm
 integrity null
 group 19
 prf sha256
 lifetime seconds 3600
crypto ikev2 enable OUTSIDE

Ensure IKEv2 protocol is enabled in the Default Group Policy

group-policy DfltGrpPolicy attributes
 vpn-tunnel-protocol ikev2

Create objects to reflect the DC and Branch1 sites.

object network BRANCH1
 subnet 10.10.3.0 255.255.255.0
object network DC
 subnet 192.168.0.0 255.255.0.0

DC-1/DC-2 ASA Configuration

Create a tunnel-group for Branch1, matching on the public IP address and defining the IKEv2 pre-shared key

tunnel-group 2.2.2.1 type ipsec-l2l
tunnel-group 2.2.2.1 ipsec-attributes
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

Create an ACL to identify the interesting traffic and establish the VPN tunnel

access-list BRANCH1 extended permit ip object DC object BRANCH1

Create a crypto map, reference the following: –

Match the crypto ACL to identify interesting traffic
Ensure PFS (optional)
Set the peer IP address of Branch1
Set the IKEv2 proposal
Set reverse-route injection (RRI), for the VPN networks to be redistributed
Enable the crypto map on the OUTSIDE interface

crypto map CMAP 1 match address BRANCH1
crypto map CMAP 1 set pfs group19
crypto map CMAP 1 set peer 2.2.2.1
crypto map CMAP 1 set ikev2 ipsec-proposal AES-GCM
crypto map CMAP 1 set reverse-route dynamic
crypto map CMAP interface OUTSIDE

Define an NAT Exemption rule, to ensure traffic between the DC networks and Branch1 networks are NOT NATTED.

nat (INSIDE,OUTSIDE) source static DC DC destination static BRANCH1 BRANCH1

Define a Prefix-list to identify the Branch1 networks

prefix-list REMOTE_VPN_NETWORKS seq 10 permit 10.10.3.0/24

Define a route-map to match the prefix-list used to match the Branch1 networks

route-map REMOTE_VPN_NETWORKS permit 10
 match ip address prefix-list REMOTE_VPN_NETWORKS
 set metric 1500
route-map REMOTE_VPN_NETWORKS deny 20

Configure the dynamic routing protocol (could be BGP, EIGRP or OSPF) and redistribute the static routes with the route-map.

router bgp 7500
 bgp log-neighbor-changes
  neighbor 192.168.101.2 remote-as 7500
  neighbor 192.168.101.2 activate
 address-family ipv4 unicast
  redistribute static route-map REMOTE_VPN_NETWORKS

NOTE – Once a VPN is established and if RRI (reverse-route injection) is enabled under the crypto map, the remote networks of Branch1 will be injected into the routing table. These VPN routes can be redistributed as static routes in the network. This is an important step to ensure traffic is routed to the active/up tunnel.

The above configuration can be mirrored on DC-2 ASA, the only difference will obviously be IP addressing on the interfaces and routing.

Branch1 ASA Configuration

Define 2 x tunnel-groups, for each DC ASA IP address – ensure the pre-shared key is the same, as configured on the DC-1/DC-2 ASA.

tunnel-group 1.1.1.90 type ipsec-l2l
tunnel-group 1.1.1.90 ipsec-attributes
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****
!
tunnel-group 1.1.2.90 type ipsec-l2l
tunnel-group 1.1.2.90 ipsec-attributes
 ikev2 remote-authentication pre-shared-key *****
 ikev2 local-authentication pre-shared-key *****

Create an ACL to identify the interesting traffic and establish the VPN tunnel

access-list VPN extended permit ip object BRANCH1 object DC

Create a crypto map, reference the following: –

Match the crypto ACL called VPN to identify interesting traffic
Ensure PFS (optional)
Set the peer IP address of both DC peer IP addresses in the required order
Set the IKEv2 proposal
Enable the crypto map on the OUTSIDE interface

crypto map CMAP 1 match address VPN
crypto map CMAP 1 set pfs group19
crypto map CMAP 1 set peer 1.1.1.90 1.1.2.90
crypto map CMAP 1 set ikev2 ipsec-proposal AES-GCM
crypto map CMAP interface OUTSIDE

Define a NAT Exemption rule, to ensure traffic between the DC networks and Branch1 networks are NOT NATTED.

nat (INSIDE,OUTSIDE) source static BRANCH1 BRANCH1 destination static DC DC

Verification

With the configuration above, we will run a simple test to confirm failover works as expected.

Run the command capture IKE type isakmp interface OUTSIDE on the BRANCH ASA to capture the IKE/ISAKMP packets
Establish a VPN connection to the primary peer and confirm connectivity over the VPN tunnel is successful
After a confirming connectivity, shutdown the OUTSIDE interface of the DC-1 ASA primary peer and wait until failover occurs, approximately 2 minutes
On the Branch1 ASA copy the IKE packet capture to a computer for analysis, use the command copy /pcap capture:IKE tftp://<TFTP SERVER IP>
Open the packet capture file in wireshark for review.

Figure 3 – Wireshark capture of IKEv2/ISAKMP packets

From the output above we can confirm: –

Packets 1-2 are the initial SA_INIT packets to the primary peer
Packets 3-6 are the IKE_AUTH establishing the IPSec SA
Packets 7-14 are the ISAKMP Keepalives (DPD)
Packet 15 is the first of the SA_INIT packets being sent after the OUTSIDE interface of the primary peer ASA was shutdown
Packets 16-21 are re-transmissions of the SA_INIT packet, in total more than the documented 5 x SA_INIT.
Packet 22 is the first packet sent to the secondary peer ASA, which responds in packet 23
The remaining packets confirm the successful establishment of the VPN to the secondary peer ASA and subsequently the regular ISAKMP Keepalives
In total the failover occurs in approximately 2 minutes