Missing MAC Restriction with port profile recommendation on ports that have one.

[ekobres]

This comes up on a pair of ports with a profile I have set up for Proxmox nodes. The profile includes a default "Service" VLAN and a tagged "IoT Isolated" VLAN (for my Home Assistant VM, which has an interface in the IoT VLAN). I have the same profile applied to 2 other ports on a different switch, but those ports aren't mentioned.

The way UniFi deals with multi-node ports is kind of weird since it has to deal with the fact some switches support certain profile features (e.g. 802.1X, PoE, etc) and some don't - in this case neither of the switches that use this profile support 802.1X. The port configuration warns that 802.1X configurations cannot be applied to the port - but there's no way to eliminate them from a port profile. Not sure if that's even relevant - but thought it was worth mentioning.

This goes away if I set the port profile 802.1X configuration to Auto instead of Multi-MAC.

[tvancott42]

So the suggestion to clear this up with an Ethernet Port Profile is merely a security posture thing that I came up with. My logic was that if somebody has an explicit port profile set for a port, then they intend the port to be an unrestricted access port.

Not the case in your scenario, but just wanted to clear that up.

I do wonder why 802.1X as Auto clears this up and not Multi-Host. I've not tried 802.1X Multi-Host before on UniFi TBH - how does that work from the RADIUS side?

[ekobres]

Port profiles are used for lots of things besides unrestricted access ports. Basically I think of them as enabling DRY principles for port configuration. You can immediately change something across multiple ports in one place. I have profiles for every device type: Server, Proxmox Node, Protect Camera, UniFi Talk Device, UniFi AP, UniFi Switch, User Device, etc. So if I want to switch a category of device to a different VLAN, or deploy a different set of tagged VLANs for a new SSID, or some other port-related thing - it's explicit and all in once place.

The way Multiple Host works is that the port only needs to be authenticated once after which it will allow any MAC. Normally authentication would fail the first time an unauthenticated MAC is seen, which is what you would want on a port with a single device attached. So in the ProxMox example I can authenticate the ProxMox node itself, then any additional MACs seen on that port are allowed.

If I had my wish, I would only want to flag ports that are set to "allow all" VLANs and/or set with a native default VLAN and no port profile.

Flag "Info" on ports with a profile that allows all VLANs and recommend to explicitly list the needed VLANS. "Allow All" is a convenient default during setup or for "it just works" configurations with no port security applied. You'd probably never use "allow all" in a real production environment.

Also, while we're talking about profiles, I've given up on the idea of a profile for "Disabled" because UniFi Network seems to get confused about it and flap the state between disabled and disconnected if you apply such a port profile. (Try creating a disabled profile and apply it to a port, then use the mobile app to view the switch - every few seconds the port flaps between white and grey.) Also, a "Disabled" profile doesn't really get you anything from a DRY perspective because there's really no other setting you would ever want to change on a disabled port - so it's more like an OCD thing to say there should never be a port without an explicit profile. Disabling a port is already an explicit configuration that does only one thing and without additional risk of someone magically enabling all disable ports at once. That's not presumably a use case anyone would ever use - so why encourage it?

[tvancott42]

I know, there's a whole Port Profile recommendation engine in Config Optimizer.

I hate it's more clicks per port currently to use a disabled profile but I like that you can enforce no PoE as well... Not that it matters, it's an OCD thing.

[ekobres]

Disabling the port also disables PoE, so that's not necessary. If it helps you get over the OCD thing, remember that what a port profile gives you is a tool to mass-change port behavior. Changing a "Disabled" port profile to do anything other than disable the port can only result in heartache and potential security issues, as you will bulk-enable all disabled ports that use the profile. So after thinking through it, I consider a generic "Unused" port profile as a foot-gun, waiting to mistakenly enable a bunch of disabled ports. That's an increased risk - so why encourage it? In fact, one could argue that flagging a port profile called "Unused" or "Disabled" that disables a port as an informational configuration risk for exactly that reason. Why encourage someone to set a configuration that can only ever possibly cause an issue? It's an unnecessary expansion of blast radius for a configuration mistake.

Rather, it's very useful to have a profile for something you plan to enable/disable in the future as an explicit profile definition. Maybe you want to temporarily disable all the Guest ports in public areas of a building? Maybe you are starting a camera deployment and you want the ports disabled until the installers have finished? There are potentially a lot of good reasons to use profiles to disable a port - but I'm not convinced having a generic "Unused" profile is a good practice.

Edit: To add - I 100% agree that all active ports should have a profile. So a reasonable audit policy would be that all active ports should have a profile, and all ports without a profile should be disabled.

[tvancott42]

You're overthinking my stance. Disabling the port alone doesn't disable the stupid PoE port icon in UniFi Network. Disabling both the port and PoE does lead to icon being correct. This is just a recommendation born out of network configs that are a product of what's basically a bug in the UniFi Network UI.

My impression from port profiles is they'll eventually morph into something more useful with a visual bulk apply tool. As they are right now, they're kind of sitting on a ton of untapped potential. The recommendations are just in anticipation of the obvious next feature set that I predict will come with future UniFi Network versions.

They'll get dialed in over time. I'll probably cut the disabled port profile suggestion soon, as you can tell I'm not particularly in love with it. It was just born out of a goal of uniformity in config, and right in the recommendation you can see the caveat that it's awkward to set up. Hence it being only an info item.

[ekobres]

Fair enough - and actually you're right about PoE being a separate config for un-profiled ports.

There is a lot of missing useful stuff that would be easy for them to add with port configuration and RADIUS. They use FreeRADIUS under the hood, so a lot is possible. Even quality of life stuff is possible with little effort, such as being able to quickly add known devices and clients as MAC authenticated users - there's already an endpoint for it: /proxy/network/v2/api/site/default/radius/users/batch_add (and batch_delete). It could also be a one click operation to set a port to only allow the currently connected device/client.

There's a lot they could do with almost no effort.

[tvancott42]

@ekobres the original issue should be fixed with https://github.com/Ozark-Connect/NetworkOptimizer/releases/tag/v1.11.3

I'm still mulling over what do do about disabled port profiles.