Security

Hello all,

We've got an issue that has caused us to bang our heads for entirely too long.  I've used the wonderful Wired Policy Enforcement solution guide that Mr Cappalli put together to help me accomplish the bare minimum of MAC-based authentication for switch ports.  In theory it works great, but the reality isn't so rosy...

When a device (PC or printer) goes to power-save/sleep, it flaps the network port.  It does not transmit any frames after it flaps the port, so the port remains in an unauthenticated state.  This is apparently normal behavior, but it causes a major issue in two specific scenarios:

• Our desktop support staff frequently need to remotely access PCs to perform updates, install software, etc.  If the PC has gone to sleep we would not have the mac address in our mac-address table, but at least with port auth off, the ARP frame is flooded until it reaches the right port and the PC then wakes up and responds.  With port auth on, the PC is probably not even in the right VLAN for flooding the frame.  The only workaround we've found to this has been to schedule the PCs to wake up at regular intervals so that the techs can do their work.  It's horribly hokey, but at least we were able to achieve some level of functionality.
• Printers that are offline can't be printed to.  We see the same scenario as above where the ARP frame is flooded before we turned on port auth, but now that it's on the print job can't ever reach the printer unless the printer decides of its own accord to start transmitting frames again and get re-authenticated. 
  We are seeing this all over the place with HP and Lexmark printers alike and we can't figure out a solution....help!!

We are at a point where this massively useful configuration that allows us to sleep soundly knowing that we know what's on our network might as well go in the dumpster if it can't support some of the devices that most frequently move around.

I understand this may not be a common issue in businesses that see every PC and printer used every minute of the workday, but surely other schools have at least seen this?  Are y'all in the same boat?

Thanks! - Daniel Hamilton

ACMP, ACCP, ACSA

Are you using Aruba switches? MAC-pinning can help you:

https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=2ahUKEwi55t6rlLXhAhVIWH0KHRWCAnEQFjAAegQIARAC&url=https%3A%2F%2Fcommunity.arubanetworks.com%2Faruba%2Fattachments%2Faruba%2FCampusSwitching%2F3052%2F4%2FMAC_Pinning.docx&usg=AOvVaw3zVTC6Xg7uhE1unaCKnepU

I'm trying that out now.  I don't know how I didn't find this before.  It does seem vaguely familiar so I wonder if we did find it and found it not to work.  We'll see!  Thanks for the tip, and I'll report back what we find.

For Aruba Switches Set the Controlled-Directions of the port

aaa port-access A18 controlled-direction in

Or set higher logoff periods

aaa port-access mac-based A18 logoff-period 86400

controlled-direction did not seem to help me.  The issue is that the mac address ages out anyway.  We had tried extending the logoff period with some success, but some printers were not helped by this at all.  PCs also saw no improvement.  It seems that the root of the issue is that if the endpoint flaps the port when going to sleep, as our PCs and Lexmark printers both do, then none of the above solutions are sufficient.  If the port does not flap, like our HP printers, then the mac pinning or logoff period extension seems to help.

We are still testing and validating some things, but mac pinning has the most promise as a "solution" in combination with other things.  It really does nothing for PCs that go to sleep, which is a huge problem for us and surely some others?

Personally I don't like the MAC pinning feature because this is a security hole and needs to be manually configured per port.

A better solution, in mine opinion, is the ip client-tracker feature. This feature will probe the devices using ARP and make sure a device sends traffic every (by default) 20 minutes. Please note, because of a bug in older release you should use firmware version 16.07.0004 or 16.08.0002. Also make sure you configure a probe delay, otherwise windows will detect a IP conflict.

Than the WoL. To make WoL work you should indeed use the controller direction feature. Next to this, you should think about the default VLAN add the port. Because no device is authenticated the port is placed in the default VLAN which is configured. The WoL packet should be send out in this VLAN. For example, if the default VLAN add the port is VLAN 10 and the client is placed in VLAN 20 and the WoL is send in VLAN20 the WoL packet is not reaching the client because the port is placed in VLAN10 as there is no authenticated device. So the workaround is to send the WoL packet in VLAN10 or you should set the default VLAN to 20.