cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2461
Views
0
Helpful
1
Replies

VPN - DHCP and local pools

GW M
Level 1
Level 1

We recently had an issue with our ASA 5555 device supporting Cisco AnyConnect VPN client access. Our ASA is configured to use a primary and secondary DCHP server. They are also configured to use local pools as a third alternative in the event of DCHP primary and secondary failure. Both DCHP and local pools are configured to use the same IP address range/subnet. So, here is the situation. DHCP failed, both primary and secondary. The ASA then started to using it's local pool. Prior to the DHCP failure, DHCP already handle out IP addressing to hundreds of Cisco AnyConnect VPN clients. When the ASA took over the IP addressing responsibility it started to assign IP's to new Cisco AnyConnect VPN clients using the same IP's that were already handed out to already connected Cisco AnyConnect VPN clients by the DHCP server. When new Cisco AnyConnect VPN clients tried to connect, they were disconnect immediately. Each time this happened the ASA would quarantine the IP address because it was in use by an existing connected VPN client. Clients would try to connect again and again and would be disconnected until the ASA finally found an available IP that wasn't already in use by an existing connected VPN client.

 

Has anyone every seen this? When DHCP failed, the ASA should have know what Cisco AnyConnect VPN clients were connected already and removed those IP's from the local pool to be allocated to new Cisco AnyConnect VPN client connections. We are running software version asa942-6-smp-k8.bin

 

Thanks

 

GW

1 Accepted Solution

Accepted Solutions

Rahul Govindan
VIP Alumni
VIP Alumni

Unfortunately, this is the current behavior. This is because the ip address conflict check only happens when a connection attempt is made and an ip address is assigned as a part of that connection. What you are asking for (and the right behavior IMO) is for the ASA to have a proactive check when DHCP fails. This is also going to be complex, because the ASA would have to have some sort of logic to understand that the DHCP server has failed. I don't think this is there yet. 

 

Another option for you is to create a separate IP address pool (and associated NAT and filter rules) for the VPN. This way, you can also know that DHCP addr assignment failed when you see VPN users with the local IP pool.  

View solution in original post

1 Reply 1

Rahul Govindan
VIP Alumni
VIP Alumni

Unfortunately, this is the current behavior. This is because the ip address conflict check only happens when a connection attempt is made and an ip address is assigned as a part of that connection. What you are asking for (and the right behavior IMO) is for the ASA to have a proactive check when DHCP fails. This is also going to be complex, because the ASA would have to have some sort of logic to understand that the DHCP server has failed. I don't think this is there yet. 

 

Another option for you is to create a separate IP address pool (and associated NAT and filter rules) for the VPN. This way, you can also know that DHCP addr assignment failed when you see VPN users with the local IP pool.