I’ve got a hEX PoE. Port 1 → 5 are configured on the switch chip on my switch. Port 1 is in vlan 90, port 4 → 5 is in vlan100.
I wanted to implement a form of portsecurity, where only mac 00:E0:4C:00:03:A7 is allowed on ether5.
I thought, easy peasy, this can be achieved with switch rules:
/interface ethernet switch rule
add comment="Allow 00:E0:4C:00:03:A7 on ether5" ports=ether5 src-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF switch=switch1
add comment="Drop all other macs on ether5" new-dst-ports="" ports=ether5 switch=switch1
The menu contains an ordered list of rules just like in /ip firewall filter, so ACL rules are checked for each packet until a match has been found. If multiple rules can match, then only the first rule will be triggered. A rule without any action parameters is a rule to accept the packet.
The first rule is, as the documentation says an accept rule, as it doesn’t contain an action. Since it matches the MAC I am connecting to this port, I would expect the traffic from this port to be accepted. The second rule has an action new-dst-ports=“”, meaning it is a droprule as the documentation specifies. The rule matches all traffic from port5, but it comes after the accept policy for my mac. However, when I enable this second rule, my client with mac 00:E0:4C:00:03:A7 also stops working. I am running on version ROS 7.16.
Is this a bug, anybody got an idea?
The way I read the ACLs, the second rule matches also “return” traffic … which has dst-mac-address set to MAC address of allowed device. So perhaps you have to introduce another rule and push it between existing two rules:
add comment="Allow 00:E0:4C:00:03:A7 on ether5" ports=ether5 dst-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF switch=switch1
And yes, I’m pretty sure it has to be a separate rule, if you’d set both src-mac-address and dst-mac-address on same rule, it would match nothing (multiple match criteria are AND together).
So, there is the need of two “monodirectional” rules:
comment=“Allow from 00:E0:4C:00:03:A7 to ether5”
and:
comment=“Allow to 00:E0:4C:00:03:A7 from ether5”
?
Make those “from/to ether5” read “via ether5” to make comment more precise. It seems that switch ACLs don’t care about direction of frame passage via some port, it’s just port involved … direction is only implied with src-/dst-mac-address … and not even then (same frame can have src-mac-address on ingress through “connecting” port or on egress on “foreign” port).
Allow me to disagree
Syntax/commands need to be precise, actually exact.
Comments need to be descriptive/understandable.
The ethernet cable physically connects ether5 to a port on another device identified by the MAC address.
Packets/whatever travel back and forth on this ethernet cable.
It is clear that what is connected is the router via ether5, but I stand by my comments as descriptive enough.
Comments are a linguistic category and since we’re coming from different language families (and we’re both non-native English speakers), I think we can agree that we don’t understand your comments in the same meaning
Thank you for the replies. I am 1 step closer I think.
The DHCP is working now with my rules:
/interface ethernet switch rule
add comment="ALLOW 00:E0:4C:00:03:A7 via ether5 (ingress)" ports=ether5 src-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF switch=switch1
add comment="ALLOW 00:E0:4C:00:03:A7 via ether5 (egress)" dst-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF ports=ether5 switch=switch1
add comment="ALLOW BROADCAST ether5" dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF ports=ether5 switch=switch1
add comment="ALLOW MULTICAST ether5" dst-mac-address=01:00:5E:00:00:00/FF:FF:FF:00:00:00 ports=ether5 switch=switch1
add comment="Drop all other macs on ether5" new-dst-ports="" ports=ether5 switch=switch1
However, when I try to ping the gateway 172.16.100.254, which is on the mikrotik. It doesn’t get through for some reason.
My computer has an arp entry for the gateway, so that’s fine. The Mikrotik has an incomplete ARP entry for my computer.
In a wireshark trace on my computer I see the Mikrotik ARPing the whole time ‘who has 172.16.100.29?’ (IP of my computer). My computer replies to this ARP with his IP (src mac: 00:e0:4c:00:03:a7). But somehow that ARP reply packet doesn’t get past the switch rule filter…
The Mikrotik keeps arping for my computer until I disable the rule “Drop all other macs on ether5”. The ARP then stops, the Mikrotik is able to get an arp entry for my computer and the ping starts working.
Somebody got an idea why the arp reply is not reaching the Mikrotik with my switch rules? The ARP reply on ether5 should hit the first rule (ports=ether5 src-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF switch=switch1) , no?
If I want to be able to ping from a device connected to ether5 to a device on the switch with MAC A8:4A:63:68:00:C2 (ether2), I have to add the rule “Why this rule?”. Otherwise it just wouldn’t work. I don’t understand why tho as all these packets should hit the second rule (because they are sourced from MAC 00:E0:4C:00:03:A7).
I’m really puzzled here…
[admin@Mikrotik hEX PoE] /interface/ethernet/switch/rule> print
Flags: X - disabled, I - invalid; D - dynamic
0 ;;; Why this rule?
switch=switch1 ports=ether5 dst-mac-address=A8:4A:63:68:00:C2/FF:FF:FF:FF:FF:FF copy-to-cpu=no redirect-to-cpu=no mirror=no
1 ;;; ALLOW 00:E0:4C:00:03:A7 via ether5 (ingress)
switch=switch1 ports=ether5 src-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF copy-to-cpu=no redirect-to-cpu=no mirror=no
2 ;;; ALLOW 00:E0:4C:00:03:A7 via ether5 (egress)
switch=switch1 ports=ether5 dst-mac-address=00:E0:4C:00:03:A7/FF:FF:FF:FF:FF:FF copy-to-cpu=no redirect-to-cpu=no mirror=no
3 ;;; ALLOW BROADCAST ether5
switch=switch1 ports=ether5 dst-mac-address=FF:FF:FF:FF:FF:FF/FF:FF:FF:FF:FF:FF copy-to-cpu=no redirect-to-cpu=no mirror=no
4 ;;; ALLOW MULTICAST ether5
switch=switch1 ports=ether5 dst-mac-address=01:00:5E:00:00:00/FF:FF:FF:00:00:00 copy-to-cpu=no redirect-to-cpu=no mirror=no
5 ;;; Drop all other macs on ether5
switch=switch1 ports=ether5 copy-to-cpu=no redirect-to-cpu=no mirror=no new-dst-ports=""
Did another test where I connected device with MAC D0:50:99:82:6C:11 to ether3.
If I want to be able to ping a device on ether2 with MAC “D0:50:99:82:6C:11” then I need specific rules allowing this traffic, same for when I want to be able to ping the GW of the subnet. So the first 4 rules I added for this, which does not make sense, as all the pings from/to those devices would match my rules “ALLOW 00:E0:4C:00:03:A7 (ingress)(Ether3 PORTSECURITY)” and “ALLOW 00:E0:4C:00:03:A7 (egress)(Ether3 PORTSECURITY)”.
If I now want to ping a device on ether4 from ether3, I have to add the MAC address of the devices behind ether4 as well in a rule to port ether3… This doesn’t make sense to me… I’m starting to believe this is a bug.
What doe you guys/girls think? Should I open a bug report for this?
