The 10% missing are that I can still ping IPs assigned to interfaces on that router, for example 192.168.1.2. Experimented a lot with the rules, read the packet flow diagram, and it seems like the major catch is that such traffic is not destined to bridge port or physical out interface, so I don’t understand where it fits in the flow. I can capture such traffic in the input chain, but the forward chain ignores it regardless if I specify it with ips or interfaces. This rule does not capture ping to the neighbour bridge address, but captures traffic that exits the neighbour bridge:
so they traverse I → J instead of the usual I → L ?
given the 90% rule will block all traffic going through another bridge or WAN interface, what else am I risking except for allowing access to the MT services exposed on “internal” IPs if I don’t block this internal traffic?
Since RouterOS doesn’t have different services listening on different addresses, it doesn’t matter to which client connects to. But if you want to limit it for cosmetic purposes, you can:
In other words no actual data will flow but if you want to feel better enact extra rules…
I prefer to use One bridge and do all my talking and blocking with vlans and interface lists…
How does bridge, vlans and interface lists help with this? Unless you have them just for L2, i.e. router functioning only as switch, you have the same “problem”.
If you have vlan1 with 192.168.1.1/24 and vlan2 with 192.168.2.1/24, and want them completely isolated, then blocking in forward chain blocks e.g. 192.168.1.100<->192.168.2.100. But 192.168.1.100 is able to access 192.168.2.1 (address on router), so it seems that it can access the other subnet. It’s misleading, because it really can’t. If it’s allowed to access something on router on 192.168.1.1, then accessing it on 192.168.2.1 makes no difference, because it’s exactly the same service. If would be different if RouterOS allowed e.g. several independent dns resolvers, where one listening on 192.168.1.1 would have some filtering, and another on 192.168.2.1 wouldn’t. Then client connecting to the other one could be problem. Currently it’s not possible, so it’s ok, but you may still want to “fix” it, to make it look better.
given the 90% rule will block all traffic going through another bridge or WAN interface, what else am I risking except for allowing access to the MT services exposed on “internal” IPs if I don’t block this internal traffic?
Nothing really, other than the internal addresses being visible as explained by @Sob
Thanks for the help, it’s clear now. The only risk I see (in my set-up) is leaving DNS accessible, but that’s OK for me and I know how to plug it if I wanted to.
I wish the CPU+internal IPs was treated as separate port, that would make it easier to manage and reason about.