I'm moving a customers ASA from client address pools to DHCP address assigment for VPN clients anyconnect and also IPsec client.
When I make the change, the first client connects fine and receives an IP address OFFER from the DHCP server which is ACK'd and the client is up no problem,
The problem is when the second user accesses via the same method, ASA passes the DISCOVER to the DHCP server and it OFFERs the same IP address to the second client as it did to the first. I have verified this using packet capture wizard and exporting it out to wireshark..
The reason appears to be because the ASA sends the DISCOVER message to the DHCP server with the same client mac address each time so the DHCP server sees the request as coming from the same client each time and therefore offers the same address out, the ASA sees this duplicate address assignment and appears to actually drop the ACK from the DHCP server so the second client attempt does not connect.
The VPNs work fine when using client address pool assignment.
How can this functionality be changed to either send the DHCP messages out from the ASA using the original client MAC, or otherwise?
Taken from wireshark, this is the same in every DHCP packet relayed by the ASA. This appears to be incorrect behaviour?? The documentation I've read says that the client field is used by the server to differentiate between client requests.
Client MAC address: Cisco_d2:d1:0d (00:27:0d:d2:d1:0d)
Just incase any one else has this issue, here is the response from cisco TAC.
When configured for DHCP address assignment with VPN clients, the ASA will always use its own MAC address in every DHCP request it send to the ASA, but, will change option 61 (Client Identifier) in the DHCP Discover message, so every Discover packet is different and hence, the ASA will track IP addresses assigned to the clients and each client will have its own unique IP address.
And looking at the sniffer you sent, you can clearly see option 61 (client identifier) is unique and different for every DHCP Discover.
Now, some DHCP servers like QIP assign IP addresses only based on the MAC address of the client, and since the ASA will always use its own Mac address, the DHCP server will always reply with the same IP address in the DHCP offer.
Please note that the ASA doesn’t support such servers (like QIP) which only assign IP addresses based on the MAC address, as documented in the bug with ID:
CSCsr96775 ASA source MAC address to request DHCP - dont work properly QIP srvr
This is actually not a bug with the ASA code, but rather a way to document that the ASA doesn’t support such DHCO servers for VPN address assignment.
For more details about this bug, please check the link below:
The workaround for this is to have your DHCP server supporting the identification of the client based on the value contained in the client identifier in option 61 of the DHCP Discover message, rather than just identifying the clients based on the MAC address. This way, everything at your side should work fine and the Anyconnect clients should be assigned IP addresses using DHCP server properly.
If the DHCP server has a lease time set for the AnyConnect clients, should'nt they also recieve the same IP address when they connect during the course of that lease? I am able to get a DHCP address successfully, but get a different IP address upon every connection of the same client even with the lease set to 6 days. Is this normal?
BenefitsDocumentationPrerequisiteImage Download LinksLimitationsSupported PlatformsLicense RequirementsTopologyStep-By-Step ConfigurationConfigure Virtual ServiceActivate the virtual service and configure guest IPsConfiguring UTD (Service Plane)Configurin...
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...