0
Votes

Feature Request: 802.1x supplicant capability for Omada EAPs & Switches

 
0
Votes

Feature Request: 802.1x supplicant capability for Omada EAPs & Switches

Feature Request: 802.1x supplicant capability for Omada EAPs & Switches
Feature Request: 802.1x supplicant capability for Omada EAPs & Switches
Saturday

This is a copy of an extremely long running feature request I had from UniFi, before I switched most clients and sites to Omada. There are many situations (particularly in schools, kids get up to all kinds of stuff, but also camp grounds, B&Bs etc) where physical security of remote ethernet ports/APs cannot be assured and simultaneously it's desirable to make sure that unauthorized devices can't just be plugged in and go cruising through the network by tagging their own traffic. MACs are utterly trivial to spoof. The right way to do that is typically multi-host 802.1x for a wired port. As far as I can tell, Omada of course supports acting as an Authenticator for its own clients, but the actual switches and EAPs do not have any ability to act as a supplicant themselves (same as UniFi). So their ports have to be set force authorized, and in turn if someone unplugs one they can then just plug in something else.

 

And while technically this is true of lots of devices that don't support 802.1x, I think it's worse in the case of network infrastructure. If some networked screen or printer or whatever client appliance didn't support it, the port still needs to only offer just a single VLAN of traffic along with features like port isolation, so it can be trivially restricted and monitored. But switches and access points that are themselves serving further downstream clients must be able to pass traffic for everything those clients might use, including further network devices and the management VLAN itself.

 

Having the switches & APs themselves support RADIUS under network options and cooperate such that the port won't pass any traffic at all without an authorized device attached could be used to fix this. It's also possible to envision various proprietary approaches, allowing admins to explicitly designate a given port as a "downstream network intermediary" or whatever label, and make it so that Omada hardware has a way to handshake and perhaps setup a transparent to operator tunnel. I think something standard is likely best, but whatever the approach it'd be a real boon to have some extra layers available.

 

Ideally Omada would leverage this into the adoption process, so new kit can have credentials added so everything automagically can provision on adoption or deployment. Apologies if this has already been addressed somewhere, but I did a search and couldn't find it. Thanks for your consideration.

#1
Options
2 Reply
Re:Feature Request: 802.1x supplicant capability for Omada EAPs & Switches
20 hours ago

  @sonaric 

 

Is there something like this you want?

 

https://community.tp-link.com/en/business/forum/topic/714314

#2
Options
Re:Feature Request: 802.1x supplicant capability for Omada EAPs & Switches
19 hours ago

  @MR.S 

I saw that, but MAB is just MAC authentication with an extra step on the setup side unless they're doing something extra, but I don't think there is any hint there that Omada was doing anything in the background for some sort of real key? And again MAC is utterly trivial to spoof. Not that you can't get it by connecting to a machine anyway, but in this case the MAC is literally right on the back of the AP, just set the desired NIC (# ifconfig <interface> ether AA:BB:CC:DD:EE:FF) to that MAC and that's that. It's not the same thing as having an AP or switch actively authenticate with a secret stored onboard.

#3
Options