the problem I’m facing is, how to achieve a desired effect without redesigning the network.
The situation is, I have a large single subnet, 10.0.0.0/8 which happens to overlap another subnet, 10.0.0.0/8. Devices belonging to the latter are aggregated in Switch 1, but require access to 10.63.203.3/8, which is available via Switch 2.
The desired outcome is to have particular devices from the “10.0.0.0” range being able to communicate with 10.63.203.3, and 10.63.203.11 being able to communicate with 10.63.203.3 and .4 - with the rest of IPs (10.64, 10,72s etc.) completely blocked. All IPs are static, MAC addresses are known. L2 switches are not manageable, so no VLANs.
As this is L2 and all aforementioned devices are in a big subnet, I guess the firewall feature is irrelevant here, however, I read that Mikrotik features Bridge Filter, that allows to filter particular traffic even within a subnet (unless I got something wrong). I am aware that it is not the optimal solution, the catch here is that it is not possible to redesign that network - so only an “L2” firewall of sorts would help.
My question is, is my thinking correct, i.e. is it possible to use the bridge filter feature to inspect packets and filter them based on IP criteria?
RB devices, when in bridge mode, can filter L2 traffic … you have to construct appropriate firewall rules and configure /interface bridge settings set use-ip-firewall=yes. And disable HW offload for at least one of ports that carries traffic which has to be checked (e.g. if switch 2 is connected to RB interface ether3, then execute /interface bridge port set [ find interface=ether3 ] hw=no ).
The thing which is not entirely clear to me is the following: do networks on left and right of RB only use same network address and netmask or do used IP addresses collide as well?
In the later case (e.g. if there’s a device with 10.63.203.11 on the right side as well) RB will have to be in routing mode and this complicates things a bit (it has to perform src-nat for connections crossing from left to right), etc.
No IP conflict whatsoever, both networks, regarding IP adresses, are properly designed. It’s the overlapping of ranges (i.e. broadcasts, multicasts) that causes the headache - and it needs to be addressed without messing with the network structure itself.
One question though, I read about hardware offloading issue yesterday, but it seems that the option to uncheck it is not available (i.e. in every single port I’ve checked the HW offload is permanently checked and greyed out). Could it be due to hardware limitations in the Lite series?
Should it be understood, that for filtering purposes, options available under Bridge/Filters are treated separately from IP/Firewall (i.e. being parallel), or is it required, in order to achieve L2 filtering, to check the “use IP firewall” option?
Bridge filtering works without IP firewall check. But the note about disabling HW offload is still true. And I don’t know why it’s grayed. Which UI do you use, winbox or webfig? In winbox, you should go to Bridge → Ports → double-click interface and there’s Hardware Offload … in my case it’s not grayed.
Or, if you’re not afraid, open terminal window and use CLI to disable HW offload on ports.
Thanks, your suggestion regarding HW offload via CLI worked - I am not sure about rule precedence in Bridge/Filter - is it identical to IP/Firewall/Filter (i.e. top ones are processed first)? I was thinking about a standard set like “allow 10.63.203.0/24” then “allow 10.0.0.0/24” then “drop everything else”.
Anyway, I do not understand rules perfectly, but it seems to me, that IP lists (ranges) cannot be used in L2 Filter, so in my case it would probably be best to either define allowed/disallowed subnets, or do it on a host-by-host basis, right? Not sure about the last one, but since I have two separate network architectures (both using 10.0.0.0/8) then using 24 bit mask might not be the best idea.
I don’t have much experience with bridge filters, so take my words with caution.
I expect bridge filters to behave same way as firewall filters, i.e. from top to bottom. And regarding the overlaping subnets: I’d extensively use in-interface property of filter rules which should nicely separate both networks.
Be careful about too strict blocking: devices expect that they are actually part of same network. Which means ARP has to pass in both directions, perhaps some others as well.
