I tried both options, but I haven't idea why this rule isn't working. Maybe some bridge settings or fast forward can affect to this.
Weird. The bridge where I've tried it looks as follows:
name="bridge" mtu=auto actual-mtu=1500 l2mtu=1598 arp=enabled arp-timeout=auto mac-address=B8:69:F4:xx:xx:xx
protocol-mode=rstp fast-forward=yes igmp-snooping=no auto-mac=no admin-mac=xx:xx:xx ageing-time=5m priority=0x8000
max-message-age=20s forward-delay=15s transmit-hold-count=6 vlan-filtering=yes ether-type=0x8100 pvid=1
frame-types=admit-all ingress-filtering=no dhcp-snooping=no
[me@MyTik] > interface bridge settings print
So nothing unusual there.
However, if you have hardware acceleration enabled on ether7 (hw=yes
), the frames forwarded between ether7 and any other port on the same switch chip where hw=yes
too bypass the CPU so the bridge filter cannot affect them. Regarding frames towards the Mikrotik itself, hw=yes
should not cause any trouble.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.