802.1x New IP address after CoA

[imanv]

Hello.

I have a problem with supplicant new IP address after CoA.

In my scenario, all machines authenticated with valid certificate, will receive a temporary IP address. After the successful login (by configuring EAP chaining using machine cert and user authentication with EAP-MSCHAP v.2 over EAP-TEAP or similure configuration with Anyconnect) temporary IP address should be release and new VLAN and IP address based on the Authz profile most be set on machines.

My problem is getting new IP address. I check the authentication session under the switch port. I can confirm the dACL and VLAN changing, and also I can see the CoA working properly. Because my initial IP address will remove for a while and then the temp IP back again. Then in windows I can see the temp IP is still there.

I can get the new IP address just with disconnecting and reconnecting the supplicant connection.

I have the same status with Cisco Anyconnect. I should click on the Anyconnect connection icon over NAM profile name to get new IP address.

How can I solve the completely releasing the initial IP address and getting the new IP without disconnecting and reconnecting the network connection ?

Cisco ISE Version : 2.7 Patch 3

Windows 10 version 2004

any connect : 4.10

[EdouardZorrilla0939]

Hello Iman, could you please advise how did you fix this problem ?. I have the same issue.

Regards,

Edouard.

[Greg Gibbs · Accepted solution]

This is a common issue with dynamic VLAN assignment as the endpoint needs to be able to detect that the network change has occurred and understand that it needs to request a new IP address via DHCP. Some native supplicants have mechanisms that attempt to resolve these issues, but they are not 100% effective.

The AnyConnect Posture Module supports a VLAN change detection mechamism, but that does not help if you're not using the Posture feature.

Two methods I have seen customers use to mitigate these common issues:

1. Use a starting VLAN that has a DHCP scope with a super aggressive lease timer (<30 seconds). This is not supported by Windows DHCP servers, so I've only seen this deployed with Linux/Unix based DHCP servers.
2. Configure a 'pre-auth' ACL on the switchport that blocks DHCP in the starting VLAN. Once the authorisation process completes and the VLAN assignment is changed, you would then push a permissive downloadable ACL to override the restrictive pre-auth ACL.
   The only caveat is that some 'headless' or IoT devices might be sensitive to DHCP timeouts and stop sending requests after a number of timeouts. You would want to test this approach with your endpoints to see if it causes issues.

[vivarock12]

does this applies on DACL too or is not posible to have the same problem?