802.1X on MikroTik – multiple devices behind one port & dynamic VLAN assignment

RouterOS General
1

Hi everyone,

I’m trying to implement 802.1X authentication on MikroTik devices for wired connections, but I’ve run into a problem.

When using 802.1X authentication with a Microsoft NPS RADIUS server, I noticed that once a single device successfully authenticates on a port, all other devices connected to that port also gain access to the network — even if they haven’t authenticated. In our environment, we often have multiple end-user devices connected to a single MikroTik port through unmanaged switches (e.g., TP-Link), which poses a security risk. An unauthorized person could simply connect to one of these unmanaged switches and gain network access.

I’ve tried using dynamic switching filter rules, specifically:

Mikrotik-Switching-Filter = “action allow, src-mac-address none action drop”

However, this approach allows only the first device to connect, while all other devices behind the same port are blocked — which doesn’t work for us either, since we have multiple users per port.

Is there any way to enforce per-device 802.1X authentication on MikroTik even when multiple devices are connected through an unmanaged switch? Is such a feature already possible, or maybe planned for future development?

Additionally, I’d like to implement dynamic VLAN assignment based on the authenticated user. While dynamic rules from the RADIUS server are working to some extent, I’m still unable to authenticate multiple users on a single port — which is key for our setup.

Do you have any suggestions or recommended solutions for this use case?

Network topology:

We currently use the following switch setup:

10x MikroTik CRS326-24G-2S+RM — access switches

1x MikroTik CRS317-1G-16S+RM — core switch, uplinked to all CRS326 units

Thanks in advance for your help!

2

This is a limitation of .1x - both the having one device authenticate and then others have access part and the single vlan per port part.

Both are usually solved by using managed switches, which carry out the authentication by themselves on their ports (consulting a central RADIUS in the process.) This basically cannot be alleviated.

There’s still the problem that an arbitrary device can take over a connection on a port in several ways, usually involving a dumb switch and cloning the legitimate mac address. This is again a fundamental limitation of the technology and is possible because an actual encrypted channel is not established.

3

Not if the devices (PCs/Laptops mostly) use EAP for authentication instead of just relying on the MAC address.

4

I’m not talking about authenticating by mac. On most .1x setups that use eap it’s fully possible to plug in a legitimate device via a dumb (transparent) switch, then remove that device (because of the switch, the connection doesn’t go down) and then have another device (possibly with a cloned mac) be connected and inject its own traffic. In these scenarios it’s simply not possible to differentiate the two devices.

There are other variants, such that both devices remain connected continuously and connections and authentication requests are selectively forwarded to the two devices on the same port.

5

That weakness has been known for decades.

RouterOS gained a basic MACsec implementation last year which might be used to solve this.

Alternately, you could use any of the other encrypted VPN tech in RouterOS to manufacture your very own custom overlay network, then deny any traffic not using that overlay.

6

Of course reauth-timeout should be set to somewhat mitigate against such issue, at least the genuine device needs to be periodically plugged in.