RADIUS CoA

[config t]

When I impose a RADIUS CoA on a Windows box to maneuver it to an isolation VLAN should it detect the network change and DORA automatically? It seems as if it is failing to initiate DHCP unless the port is bounced.

[config t]

To answer my own question:

It depends on the equipment string. In this case a voip handset in-line with the PC was causing a failure to detect the network change so it wouldn't initiate DHCP. The answer for this scenario was installing the NAC agent.

[deanwebb]

Yes, and most Windows won't notice the change without an agent. This is why agentless solutions have to hard-bounce the port to get the device to request a new IP address. Any dot1x solution works so much better with agents that replace the Windows supplicant.

I have evil things to say about Windows supplicants, if you would like to hear them...

[Otanx]

This is why I propose port based ACLs instead of vlan changes when doing 802.1x. Too many variables to handle to make the vlan change work.

-Otanx

[deanwebb]

^indeed. But once the ACL has to be open for all the AD servers or something like that, it takes off and becomes something like 1800 lines for all the ports and IP addresses. This can lead to partial ACL application if things time out. Whereas "VLAN 911" - it's done in just the one line, less chance of a timeout issue.

[Otanx]

If you go to that level of detail that is true. The way I handle it is to put a real firewall between clients and servers. Do most of the filtering there. Then the port based ACLs can be permits to IPs, and a deny for all others to block east/west. Usually only 5 or 6 lines at that point. So a remediation ACL would look something like:

10 permit ip any AD_Server
20 permit ip any Patching_Server
30 permit ip any AV_Server
40 permit ip any Web_Proxy
50 deny ip any any

The normal ACL we used was just a deny to the /16 for client networks, and a permit any. That way a workstation couldn't go to another workstation, and then everything else was handled by the firewall. We also had different ACLs for printers that locked them down to just the print server. We didn't do any guest wired normally, but we did have an ACL with just the Web_Proxy for the few times we needed it.

There are a couple downsides. One is no logging on port based ACLs so that blinds you to some things. Also there is no good way for help desk to identify if a system is in quarantine or not without looking at the switch, or RADIUS logs. The IP is the same so that isn't a clue anymore. Same with log correlation in the SIEM. You need to bring in the RADIUS logs to identify host profiles because the source IP is the same for all clients.   

-Otanx

[config t]

From a practical standpoint "simple and easy-to-maintain" is the way forward with this particular customer. Boundary FW is managed by someone else, other than VTY all of the ACLs live on the core, no east-west FW, and add to that a regular personnel rotation which makes consistent reliable skill sets a dubious proposition.

Personally, I'm a fan of object-groups and do have another customer where the PACL use case is feasible. I just wish they could make decisions faster.