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 10.0.0.1 client connect Tunnel1 connect auto ! interface Tunnel1 no tunnel destination 10.0.0.1 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 192.168.10.0/24 network.
There are a couple of things we need to do on the FlexVPN client:
- 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.
- Since we are using PSK authentication, we need to configure a pre-shared key for the backup FlexVPN server.
- We also need to add a match identity statement for the backup FlexVPN server under the IKEv2 profile.
- 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 10.0.0.254 ! crypto ikev2 keyring FLEX_SERVER_KEY peer FLEX_SERVER_BKUP address 10.0.0.254 pre-shared-key cisco ! crypto ikev2 profile FLEX_CLIENT_PROF match identity remote address 10.0.0.254 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:
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 icmp-echo 10.0.0.1 ip sla 2 icmp-echo 10.0.0.254 ! 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 10.0.0.1 track 1 peer 2 10.0.0.254 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 10.0.0.1 255.255.255.0 standby 1 ip 10.0.0.100 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 peer FLEX_SERVER_VIP address 10.0.0.100 pre-shared-key cisco ! crypto ikev2 client flexvpn IKEv2_CLIENT_PROFILE no peer 1 no peer 2 peer 1 10.0.0.100
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
- EzVPN-NEM to FlexVPN Migration Guide: http://www.cisco.com/c/en/us/support/docs/security/flexvpn/115950-ezvpn-nem-to-flexvpn.html
- Configuring Internet Key Exchange Version 2 (IKEv2): http://www.cisco.com/en/US/docs/ios-xml/ios/sec_conn_ikevpn/configuration/15-1mt/Configuring_Internet_Key_Exchange_Version_2.html