In the last article, we configured something similar to EzVPN, but we used IKEv2 instead of IKEv1. In that article, I mentioned that we can configure a FlexVPN client profile and one of the things possible with these client profiles is the option to configure multiple peers, e.g., multiple FlexVPN servers. In this article, we will look at how this can be achieved.

The lab setup we used in the last article is as shown below:

IKEv2 Client Profile

Let’s change the configuration on the FlexVPN client to use a FlexVPN client profile. This will also affect the VTI configuration on that client: instead of statically defining the tunnel destination, we will configure it as “dynamic” and let the peer be retrieved from the FlexVPN client profile.

The configuration change of the FlexVPN client is as follows:

crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE
  peer 1
  client connect Tunnel1
  connect auto
interface Tunnel1
 no tunnel destination
 tunnel destination dynamic

You can shut down the tunnel interface and bring it back up for the changes to reflect. Apart from other show commands that we have used to confirm that our configuration works, we now have the show crypto ikev2 client command, which gives us information about the FlexVPN client status:

We can confirm that traffic from/to the protected subnets are going through the tunnel:

Backup FlexVPN server

We can build on this by looking at a scenario where there is a backup FlexVPN server that clients should connect to if the primary FlexVPN server fails.

The configuration on the backup FlexVPN server is exactly like the one on the FlexVPN server in the previous article except that I have changed all the IP addresses to “.254”. Also, I have connected the FlexVPN servers via their Ethernet0/1 interfaces to make up the network.

There are a couple of things we need to do on the FlexVPN client:

  1. We need to add the backup FlexVPN server as a peer under the FlexVPN client profile. We add this server with a sequence number greater than the primary server because the client will connect to the peers in the order in which they are listed, with sequence number 1 being the highest priority and sequence number 255 being the lowest.
  2. Since we are using PSK authentication, we need to configure a pre-shared key for the backup FlexVPN server.
  3. We also need to add a match identity statement for the backup FlexVPN server under the IKEv2 profile.
  4. Finally, we need to enable dead peer detection (DPD) on the IKEv2 profile so that the client can detect when a peer has failed.
crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE
  peer 2
crypto ikev2 keyring FLEX_SERVER_KEY
  pre-shared-key cisco
crypto ikev2 profile FLEX_CLIENT_PROF
 match identity remote address
 dpd 30 2 periodic

As you can see in the configuration above, we can have multiple match identity statements for remote peers in our IKEv2 profile even though only one identity local statement is allowed. The DPD configuration tells the client to send periodic DPD messages every 30 seconds and try to reach a peer twice before declaring it dead.

For the configuration to take effect, we can shut down the tunnel interface on the client and bring it back up.

We can now test the backup feature. I will shut down the Ethernet0/0 interface on the primary FlexVPN server so that the Virtual-access interface goes down. After a while, the FlexVPN client will detect that the peer is dead and will attempt to connect to the next possible peer.

We can check the IKEv2 SA to confirm that the client has an SA with the backup FlexVPN server:

We can also confirm that traffic between the protected subnets is still going through the tunnel:

Server Reactivation

The question then becomes, “What happens when the primary peer comes back up?” By default, nothing happens and, unless the new tunnel formed with the backup FlexVPN server goes down, the client will not attempt to reconnect to the primary server.

However, we can configure IP SLA tracking and use it to track the reachability of peers: as long as the reachability state of a peer is up, it will be considered as a “possible peer”. We can then use the “Reactivate Primary Peer” feature to ensure that the highest priority peer is always connected (as long as it is up).

ip sla 1
ip sla 2
ip sla schedule 1 life forever start-time now
ip sla schedule 2 life forever start-time now
track 1 ip sla 1 reachability
track 2 ip sla 2 reachability
crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE
  peer 1 track 1
  peer 2 track 2
  peer reactivate
  client connect Tunnel1

With this configuration, if we bring the Ethernet0/0 interface of the primary FlexVPN server backup, the client immediately initiates a connection to this server and the VPN tunnel is brought up.

IKEv2 Load Balancer

The last thing we will look at in this article is the IKEv2 load balancing feature, which is something we implement on the FlexVPN servers using HSRP and IKEv2 clusters. You can read about this feature here but I will just show you the configuration.

The configuration on the primary FlexVPN server is as follows:

crypto ikev2 redirect gateway init
interface Ethernet0/0
 ip address
 standby 1 ip
 standby 1 priority 110
 standby 1 preempt
 standby 1 name ikev2LB
crypto ikev2 cluster
 standby-group ikev2LB
 slave max-session 10
 no shutdown

The configuration on the backup FlexVPN server is very similar except that you can leave the HSRP priority as the default of 100.

On the FlexVPN client, we need to add the HSRP virtual IP address (VIP) as a peer under the FlexVPN client profile and also add a PSK for that IP address.

crypto ikev2 redirect client max-redirects 10
crypto ikev2 keyring FLEX_SERVER_KEY
  pre-shared-key cisco
crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE
  no peer 1
  no peer 2
  peer 1

Even though the client will initially send IKEv2 requests to the VIP, the HSRP active router will redirect the request to the least loaded gateway (LLG). This means that the final IKEv2 SAs will actually be built to the real IP addresses of the servers and not the VIP.


This brings us to the end of this article, in which we have looked at different options for configuring multiple FlexVPN servers. You will notice that all the features we looked at rely on the FlexVPN client profile in some way. We have also seen how IP SLA tracking and HSRP play different roles in IKEv2.

I hope you have found this article interesting because I really enjoyed writing it. I look forward to writing the next article in the series.

References and Further Reading