Tuesday, March 2, 2021

Ever done the "ping trick" for NAC?

Scenario: You have wired 802.1X configuration set up to authenticate devices, and dynamically assign the correct VLAN based on device profile. Non-authenticated ports are placed in a black hole VLAN.

Scenario: Some "dumb device" that doesn't generate a lot of traffic eventually has the auth session time out. The port switches over to the black hole VLAN, and deauths. The device just sits there never sending traffic, and thus never reauthenticates. It will basically stay down forever, unless woken up somehow.

The Ping Trick: Quickly create a local layer 3 interface on the switch in that Blackhole VLAN, with the subnet that the non-authed device is supposed to be in. Ping the device's IP from that vlan interface. The device will receive the ping (assuming you have control-direction in) and will respond to the ping, triggering the authentication process to finally begin.

Once device is up and authenticated you can remove the layer 3 interface again from that blackhole vlan.

This is... cumbersome. And won't scale well. Yet, as far as I know, it's really the only go-to solution for the situations I've described. Or is it?

How are people handling "dumb devices" that must do MAB now? As long as the device is chatty and sending frames now and then it'll stay authenticated. If it goes silent it'll just de-authenticate, and then because it's placed on a black hole VLAN, it'll never receive any packets that would have otherwise woke it back up.

Ideas? I posted about this about a year ago. Still haven't ever seen a solution. I haven't ever really even seen anyone else other than those who post here acknowledge that this is a problem. Usually when I bring it up with vendor reps I get funny looks and the implication that we've set something up wrong, and they've never heard of people having this issue.

EDIT: I've lied. I've seen some other solutions proposed by some users. They are all varying degrees of bandaids.

  • Force the device to set up as DHCP mode, with a short lease time, so it will force the device to periodically generate traffic.

  • Force the device to set up NTP so it will periodically generate traffic.

Depending on the vendor and device, some of these are not workable. There should be a way to fix this on the network side, but I'm sure that gets into a philosophical discussion on whether or not this should be fixed on the network side, because it's not a network problem. And yet.. it is. Because it's our switch changing the vlan and de-authenticating the device, and our end user suffers the consequences, because now their device is "down."



No comments:

Post a Comment