we have an 2911 VPN Router which is used for Anyconnect to dial in via IPSec. However, we are using an external Windows DHCP server to manage IP Adresses. We just found out, that the router passes the DHCP Discover each time with a differerent Client identifier number. For that the client computer each time gets a new IP from DHCP instead of keeping it's IP during Lease period.
This is the setup on the Router:
crypto ikev2 authorization policy ikev2-author-policy_AnyConnect dhcp server 10.128.9.98 dhcp giaddr 10.128.30.1 dhcp timeout 10 dns 10.128.9.99 def-domain company.name route set access-list acl_split-tunnel
Is there a way to configure the router so that it doesn't regenerate a unique ID for a remote client computer?
I have seen the option:
Router(config)#ip dhcp relay information option vpn
which changes the giaddr to the outgoing interface.
Not sure what that does for AnyConnect/IPSec clients, but configure that and check if the unique ID is removed.
I am not sure if there is something on the Cisco router that can prevent this. Can you test to disable option 61 on one of your (hopefully Windows) clients, and see what the results are ?
You need to change the HKEY below on the client:
By default, this registry entry is set to 0 (False),and therefore the option is included in outgoing DHCP requests.
Set this value to 1 (True) to prevent the option from being sent in the DHCP requests.
I think is not a client problem as the DHCP is working correctly whenver I vpn into a Cisco Firewall. Then the Unique ID keeps permanent for the client. This Problem is only happening in combination with an IOS Router.
tough one. Can you debug the traffic to your DHCP server ? Maybe that reveals where the UCIs come from...
access-list extended 101 permit ip any 10.128.9.98
debug ip packet 101 detail
When I debug the dhcp request, I can see that a hex dump generated by the router itself will be used as Client identifier. And the frustrating thing is that the router generates a new hex dump every time a vpn client connects.
I did a test and configured a local dhcp pool on the router itself and also with this scenario, the generated hex dump from the router leads in the direction that every time when a client connect via VPN, it gets a new IP address although the old IP lease time hasn't expired. This comes to the end that the DHCP scope is getting out of available IPs.
Is there nobody out there living in the Cisco World who has a running setup with FlexVPN on a Router where DHCP is working as expected?
I remember that (a very long time ago, admittedly) in Active Directory, you could set a static IP address, and then Cisco ISE would query AD for this attribute.
I wonder if something like this could be configured in your router, with local AAA. I researched this, and it should look something like below. The 'problem' is which attribute type to use, the options are massive...
aaa authorization network attr-list-group local
aaa attribute list attr-list
attribute type --?
crypto ikev2 authorization policy ikev2-author-policy_AnyConnect
dhcp server 10.128.9.98
dhcp giaddr 10.128.30.1
dhcp timeout 10
route set access-list acl_split-tunnel
aaa attribute list attr-list
I opened a TAC Support case and the outcome is that there is no way to configure the router so that it sends the client's mac instead of a hex dump. With the local dhcp pool the router will give the user the next available IP. DHCP leases are ignored.
For this the only workaround for now is to setup static IP attributes in AD which then can be used by a radius server. This is a very frustrating workaroung and not really a solution when having hundreds of vpn clients
If you are using ISE the following links may help in assigning static IP's:
--> For this the only workaround for now is to setup static IP attributes in AD which then can be used by a radius server. This is a very frustrating workaroung and not really a solution when having hundreds of vpn clients
So nothing has changed since the AD/ISE 'workaround' I mentioned earlier, which as far as I recall has been around since at least the days of Windows 7. Frustrating indeed, especially if you have hundreds of clients.
I guess the next thing to do would be to look for a non-Cisco solution.
We have the same situation also with our FTD Firepower machine and there is an open Bug for this (and ASA) and NO solution for this!