Redundant SSL anyconnect VPN setup with 2 ASA in different locations

[eevlogiev]

Hello guys,

We have a single ASA5510 located in San Jose serving as a VPN Anyconnect concentrator for our remote clients assigning them IPs via DHCP. However we want to add another ASA5510 in our datacenter in New Jersey as a backup one. Both ASAs will have a connection between each other going over company's MPLS. So some questions raised:

1. We want both ASAs to serve same DHCP pool - for example 10.10.101.x.24 in both geographical locations. Is it doable?

2. We also want San Jose ASA to work as a primary one and only if it fails anyconnect clients to connect to the New Jersey one. I know there is a BackupServerList option in the profile config. Is it applicable in that case?

3. One last thing: We have several VPN clients that need to have a certain static IP address, like 10.10.101.20 (as they are servers and they use that IP into their configs for the services they host) so in case of failover the backup ASA must provide same IP address in its DHCP offer. Is that possible to implement?

Thank you very much!

Evelin

[Richard Burts]

Evelin

Having the San Jose ASA as primary for AnyConnect and having New Jersey as backup is easy using the XML profile. Put San Jose as the primary and put New Jersey in the backup server list.

We do not know about your network environment and that makes it difficult to provide good answers to your other questions. In general I would think it is problematic to try to have both ASAs using the same DHCP pool. One challenge would be how to prevent two users being given the same IP address (10.10.101.26 in San Jose for user A and 10.10.101.26 in New Jersey for user B). Another challenge would be how to determine how to forward a packet that is generated somewhere in your network for 10.10.101.26, do you forward it to San Jose or forward it to New Jersey?

HTH

Rick

[eevlogiev]

Thanks for sharing your thoughts on this, Richard.

The idea is to have New Jersey ASA working only if San Jose ASA is down for some reason. So the DHCP pool in San Jose won't be in use during that downtime and it can be reused in New Jersey.

My major concern is about some servers connected to VPN using a certain DHCP provided IP addresses that need to be offered by the New Jersey ASA.

regards,

Evelin

[Richard Burts]

Evelin

The only way that I know of to be sure that only one or the other ASA is running but not both is to configure your ASAs in an active/standby High Availability pair, and San Jose to New Jersey is a very long way for that to work. Otherwise it is highly likely that sometimes you will have active sessions on both ASAs. Think about what happens if there are a bunch of sessions active on the San Jose ASA and there is some event that impacts its outside connection and new sessions begin to be established on the New Jersey ASA. You now have active sessions on both ASAs until the sessions on San Jose time out or are terminated. And think about what happens when the event that impacted San Jose outside is resolved and new sessions are again being established on San Jose. How many sessions have been established in New Jersey and how long will it take for all of them to time out or to be terminated? How do you manage the DHCP pool during these periods of overlap?

HTH

Rick 

[MARK BAKER]

Evelin,

I remember trying to use DHCP for static assignment to VPN clients before and not being able to identify the host to the DHCP server. This was awhile back and may be fixed now. If you are currently doing this at San Jose, then I would think that if that same host connected to New Jersey, that it would be identifiable to the DHCP server still.

If the above is true and the DHCP server can detect already assigned IPs, I would think having the same DHCP scope at both locations would be ok.

Could you redistribute into your internal network the static host routes created during an AnyConnect session via Reverse Route Injection? This would route packets to San Jose for any VPN sessions there and to New Jersey for any VPN sessions there. This would only apply if you are using a dynamic routing protocol internally.

Thanks,
Mark