Previously (up to RouterOS v7.16), the following ACL rules were used successfully on a CRS-series MikroTik switch to restrict traffic on a specific port (e.g., ether41-node102) to allow only one IP address (e.g., 192.168.1.30) and block all other traffic:
/interface ethernet switch rule
add switch=switch1 ports=ether41-node102 src-address=192.168.1.30/32 comment=“Allow only IP 192.168.1.30”
add switch=switch1 ports=ether41-node102 new-dst-ports=“” comment=“Block all other IPs”
Issue Observed:
After upgrading to RouterOS v7.17, the above configuration started blocking ARP packets as well, resulting in connectivity issues because the allowed host could no longer resolve MAC addresses.
Temporary Workaround (confirmed working):
To restore previous behavior, it became necessary to explicitly permit ARP traffic separately:
/interface ethernet switch rule
add switch=switch1 ports=ether41-node102 mac-protocol=arp src-address=192.168.1.30/32 comment=“Allow ARP explicitly”
add switch=switch1 ports=ether41-node102 src-address=192.168.1.30/32 comment=“Allow IP explicitly”
add switch=switch1 ports=ether41-node102 new-dst-ports=“” comment=“Block all other traffic”
Note: This explicit ARP allowance was not previously required (before v7.17).
Request to MikroTik Team:
Please confirm if this behavior change is intentional or a regression introduced in RouterOS v7.17. Clarification or potential restoration of the previous implicit ARP-passing behavior would be appreciated.
It obviously works fine if it also blocks ARP.
You wrote it yourself in the rules: match 192.168.1.30/32 and block everything else.
ARP doesn’t use IP… so it’s rightly blocked.
it is understood that if I do not select any mac protocol it should be all of them
Yes, it does. But still for ex. an ARP packet does not have a src-address, as it is not using IP. So it does not match the 1st pass rule, but does match the 2nd “block all” rule and hence gets dropped.
I would suggest to restrict your ACL rules to IP mac-protocol (0x0800) and let everything else (ARP, IGMP, …) pass:
/interface ethernet switch rule
add switch=switch1 ports=ether41-node102 mac-protocol=ip src-address=192.168.1.30/32 comment="Allow only IP 192.168.1.30"
add switch=switch1 ports=ether41-node102 mac-protocol=ip src-address=0.0.0.0/32 comment="Allow DHCP requests"
add switch=switch1 ports=ether41-node102 mac-protocol=ip new-dst-ports="comment="Block all other IPs"
The 2nd rule is to allow incoming DHCP UDP requests from 0.0.0.0 (in case you use static DHCP lease for the client, as the client has no IP yet)
Our instead (if possible) filter for the src MAC address of your client, what is much easier:
If I consider creating a general rule to allow all other traffic (ARP, IGMP, etc.), but a client sets an IP address that doesn’t belong to them and is already in use by another client, this will cause connectivity issues, since ARP will be permitted and the router will see two different MAC addresses.
Regarding the statement that an ARP packet doesn’t have a source address, it does actually make sense, but then why is the issue solved by explicitly creating this rule?
That’s a good question and hard to answer without knowing how ROS handles rule properties not making sense for the mac-protocol. Like IP src for ARP.
My guess is the rule with only the IP src does not match any non-IP packet. While the rule with mac-protocol=arp ignores the IP src part and matches any arp packet. This is just a guess and can be tested by changing the IP src part of your ARP rule and see if it still matches.
Technically ROS should reject (or warn about) a rule specifying IP addresses together with a non-IP mac-protocol. It is also possible that such undocumented behavior changed btw. older and current ROS versions.
Good point, missed that: Indeed since ROS 7.17 switch rules matching IP properties silently (and invisibly) set mac-protocol=ip resp. mac-protocol=ipv6.
This makes sense and explains the changed behavior seen by the OP. But it would be better if this would be indicated by the mac-protocol property of affected rules.
And the other way round: If IP properties are set in combination with an explicitly set non-IP mac-protocol, the IP properties seem to be ignored. This too makes sense, but should also be documented and ideally issue a warning.
