Change IP after ISE CoA

[Josh Morris]

I have heard of this issue before, but am not quite sure how to stop it...

Client connects to switch, switch contacts ISE on the backend. Client gets IP address on VLAN 30 in the meantime. ISE determines client belongs in VLAN 60 and performs CoA. Switch changes VLAN, but client still has an IP address in VLAN 30.

Anyone have a good way to stop this? The only thing I've heard is to put a pre-auth ACL on the port denying DHCP. But I am having issues even getting that to work.

Thanks.

[nspasov]

What type of devices are you having issues with?

[Josh Morris]

I am not having issues with any "Smart" devices like laptops.

The issues are more with devices like security cameras and building automation controllers. Devices I would consider dumb. Thats why I would like to block them from getting an address at all until ISE authorizes them.

[nspasov · Accepted solution]

I have had this issue before and have posted on similar threads. I have never tried blocking DHCP with an ACL but it would be interesting to know if it will work. I can see two issues with it though:

1. The ability to use critical auth VLAN in the event of ISE going down is not really an option unless you use Cat 3850s or 3750s with IP Services where you can use an EEM script to remove the pre-auth ACL. Otherwise, even though the ports become authorized, there is not Radius server to push a dACL to replace the pre-auth ACL

2. I like using the guest/CWA flow when 802.1x and MAB fail. This of course requires an IP

3. A lot of good profiling information is obtained via DHCP.

In the past I have used static IPs on those devices and that seem to work ok. Overall, I really don't like the dynamic VLAN override for this exact reason. That is why I recommend just leaving everyone on the default VLAN and just limit access via dACLs or ACLs on the L3 interfaces. If additional segmentation is needed then you can always go to SGT/SGA :)

Thank you for rating helpful posts!

[bikespace]

Is there an option with 3850's to apply a critical auth access list?

[Alfredo Plana Ramirez]

Hi to all,

I am having this issue too on my Wireless enviroment, and telling people "not to use it" does not fit me as a good answer.

Seems like the problem comes when CoA is happilly finished, NIC needs to be switched off and back on to automagically renew an IP address. The process that launches the DHCPRequest process only is triggered upon a physical connection (Wireless included)

In Wintel platforms I workaround it with a logon script that tells the computer SO to release and renew the ip information and gather it back again. So relaying in DHCP helper finally in workgroup vlan I receive a good IP address.

Here is a batch line script useful as well in Win+r execution box:

cmd /c "ipconfig /release && ipconfig /renew"

Hope this helps

[mohanak]

If you are using ISE 1.2.0.867 version and clients are Mac OSX and Windows 7, then this may be the bug:

IP address did not change for Mac OSX and Win 7 in CWA flow

CSCuh50368

Description

Symptom:
Vlan change IP address renewal does not succeed on Windows 7 and MAC OSX

Conditions:
N/A

Workaround:
None

Further Problem Description:

Known Affected Releases:

(1)

1.2(0.867)

[Saurav Lodh]

Even Java/ ActiveX on Client could be generate this issue as IP renewal after coa, Vlan Change, depends on it.

[Josh Morris]

Great response Neno. Thank you.

I am leaning towards using closed mode at the moment as opposed to the pre-auth ACL. Just seems easier to configure. My initial testing is not going well though, and I'm afraid it's because of your third point...I lose the DHCP profiling information. I am using MAB for much of this though, I think that should still work even if the client does not have an IP. 

This would actually fit my ultimate intended model, where an auth failure authorizes the client on the Guest VLAN. Is the critical auth VLAN able to be used in closed mode?

Leaving them all on the same with with SGTs isn't really an option here. The reason why is that many of these machines are machines that do not get updated regularly, so they are vulnerable. We have them in a VRF. Therefore, they need to be in a different VLAN.

[nspasov]

This would actually fit my ultimate intended model, where an auth failure authorizes the client on the Guest VLAN. Is the critical auth VLAN able to be used in closed mode?

Response: Yes, you can. I was really talking about the usage of the following commands:

authentication event server dead action reinitialize vlan fail_safe_vlan

authentication even server dead action authorize vlan fail_safe_vlan

Those commands are very useful when you need to protect yourself against ISE/Radius outage. However, when you ave a pre-auth ACL and the Radius server is down, there is nothing (no Radius server) left to push a dACL and replace the pre-auth ACL. Thus, even though endpoints are allowed on the critical VLAN, the pre-auth ACL is still there, thus preventing clients from gaining access to the network. With the Cat3850 you can have a critical ACL. With the 3750s running IP Services you can configure an EEM script that can remove the ACL in the event of an ISE outage

Leaving them all on the same with with SGTs isn't really an option here. The reason why is that many of these machines are machines that do not get updated regularly, so they are vulnerable. We have them in a VRF. Therefore, they need to be in a different VLAN.

Response: SGT can actually provide layer 2 segmentation too :) SGT/SGA is really the future of TrustSec

Thank you for rating helpful posts!

[Josh Morris]

Thanks. You have helped me decide not to use a pre-auth ACL. I think closed mode is the way for me to go now with a default ALLOW rule in ISE for the time being. This should keep the client from getting an IP address until after ISE has authorized the CoA VLAN change.

I will also research the SGT more to see if I can change the way we do it.

[nspasov]

Awesome. Glad I was able to help!