Redundancy options for IOS Headend for AnyConnect Clients

[mmelbourne]

What are the options for IOS Headend redundancy to support IKEv2 AnyConnect clients (terminating on ASR1k)? Currently, we use classic IKEv1 Remote Access VPN with the IPSec Client, and use stateless IPsec failover (using HSRP) between two ASR1k peers, and the failover, though not quick, is acceptable (clients need to detect the peer has gone away and reconnect.

Is something similar possible with IKEv2 RA VPN on a pair of ASR1k routers - I am not clear on what the headend certificate requirements are for IKEv2, as the FQDN in the client (and the certificate) points to a VIP which could be 'owned' by either router? Is the only solution a pre-defined list of backup peers (each with their own, separate, identity certificate).

I suspect the IKEv2 Load Balancer may offer an alternative solution, but again, the certificate requirements for the member servers isn't clear.

Cheers,

Matt

[Marcin Latosiewicz]

Matt, For redirection, this is to some extend outlines here: http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/sec_conn_ike2vpn/configuration/xe-3s/asr1000/sec-flex-vpn-xe-3s-asr1000-book/sec-cfg-clb-supp.html#GUID-97B9319C-5035-4228-8F68-1E6A0602CE8A When you perform redirect in IKE_INIT the identity payloads and certificates were not yet exchanged. The certs are exchanged in IKE_AUTH. M.

[mmelbourne]

So, does that mean each member of the IKEv2 CLB cluster can have its own identity certificate (e.g. for the FQDNs vpn01.foo, vpn02.foo, vpn03.foo), and clients can connect to vpn.foo (which resolves to the VIP of the CLB cluster)? I thought there had to be a matching CN in the identity certificate of the VPN peer for the FQDN supplied by the AnyConnect client?

Or, should the trustpoint associated with identity certificate vpn.foo, once created, be imported into each VPN peer in the IKEv2 CLB cluster?

Cheers,
Matt
 

[Marcin Latosiewicz]

Matt, I asked the folks who tested this feature to take a peak at this thread. What IMHO should work is CN for cluster (vpn.foo) + SAN (vpn1.foo or vpn2.foo etc) specific to the box for each member of the cluster. Now looking at the docs it's not clear to me how the load balancing choses whether to advertise FQDN or IP ;] M.

[Marcin Latosiewicz]

Spoke to the guys here, they mentioned DNS load balancing could be also a possibility, or usage of wildcard certificates. Quite a few different ways. I don't see any whitepapers published around it. I'd be curious to try this myself, unfortunately it's not within my realm anymore.