Hi all,
I was wondering whether there is something in RouterOS dot1x authentication for the feature that is “authentication control-direction in” in IOS or “aaa port-access controlled-direction in” in HP/Aruba.
Basically, a feature that enables traffic to go out on unauthenticated ports (like ARP, WoL, etc.) but does not let anything in until the port has received an Access-Accept from RADIUS.
Do you have any suggestions?
BR
Robert
You can specify, per port, a guest-vlan-id (as well as a reject-vlan-id), and maybe decrease retrans-timeout. When the port is online, if after 3x retrans-timeout the connected device has not made any authentication attempt, the port will be put in the VLAN specified by guest-vlan-id (here you can place whatever restrictions you want, or configure WoL, etc.…). If the device tries to authenticate but fails, it’s placed in the reject-vlan-id VLAN.
While the port is in the guest-vlan-id VLAN, the connected device can still attempt authentication at any time. If it succeeds, it will be put back into either the original VLAN, or any VLAN specified by the Tunnel-Type, Tunnel-Medium-Type and Tunnel-Private-Group-ID attributes sent by the RADIUS server.
There is no need for manual configuration in /interface bridge vlan to associate the port with the desired VLANs, the router will dynamically create entries there with the port being put in the untagged list of the current active VLAN.
Thank you for the reply. A typical device affected by this problem is an embedded device, often managed by OT or another organizational unit (not IT). It usually has a static IP configured and typically only supports MAC authentication. It is quite common for the device itself not to initiate any communication at all. Instead, it offers its counter data through some protocol and responds only when queried; otherwise, it remains silent.
Usually, its MAC address (without dot1x) gets into the bridge host table when something queries it. Before the actual query, the querying device performs an ARP broadcast. The device responds to the ARP broadcast, and at that moment, the switch learns which port it is on. With dot1x, this mechanism breaks because dot1x MAC authentication requires the device to initiate communication first.
I’m not sure that a Reject/Guest/ServFail VLAN would be beneficial in this situation. Of course turning off dot1x is always an option, but it’s not my preferred solution.
With MAC-auth the workaround with the guest VLAN doesn’t work.
If you want to lock out devices with unsupported MAC addresses from communicating with the router, maybe you can try the alternative which is to set ARP Mode of the VLAN or bridge interface to reply-only, Then, either add static ARP entries to IP → ARP, or configure DHCP Server with static-only as address pool with Add ARP For Leases turned on.
hello robert,
maybe this can help you with
https://mikrotik.co.id/artikel/447/
just use translator should be okay
In the end I’ve filed a feature request to Mikrotik this morning, we shall see what happens. My heart bleeds but can’t start deploying Mikrotik CRS3xx switches in our environment until this gets resolved.