FIrewall is always used for traffic being routed ... meaning between different IP subnets.
Generally yes, but I would say that a firewall can also be used inside a closed environment within just the same one subnet, without any uplink.
Do you think this doesn't make any sense? IMO it very well does.
You're mixing things. First things first: a typical MT does two distinct things: a) routing b) firewalling
Routing process is involved always where source and destination of a packet are not within same IP subnet. And it doesn't matter if one of those subnets is on the other side of Earth (i.e. internet) and the other subnet is your own LAN ... or if you have multiple LAN subnets (all within your premises) and you want to move packets between those IP subnets ... it is still routing.
And then you can have a firewall between two parts of network (either same IP subnet or different IP subnets) ... firewall inspects packets passing and according to rules it either passes packet or drops it (optionally informing sender about that). By default in MT, firewall is placed between different IP subnets connecting to the MT device, by enabling "use-ip-firewall" on bridge means placing firewall to a certain point within IP subnet (and that point is bridge in MT device).
A typical MT device does 'all-in-one' and it seems as if both functionalities are somehow blended. But they are not, if one is careful, it can identify which entity (router or firewall) handles a packet at certain point ... it is true that there's some meta information from router available for firewall (e.g. in-interface), but at no point can firewall directly affect the routing (other than e.g. via packet marks).
So when I wrote "FIrewall is always used for traffic being routed ... meaning between different IP subnets." I chose my words carefully and considering the LAN-to-LAN case as well.
The use-ip-firewall=yes option only affects traffic passing bridge which would otherwise skip CPU (because it is within same IP subnet).
Sorry, I have some difficulties understanding that statement (the "skipping CPU" part) . Can you or someone else pls clarify/elaborate?
At this point it is necessary to understand the
OSI 7layer model.
Let's consider ethernet only ... layer 1 is physical layer (i.e. modulated electrical signals over UTP cable or modulated light over optical fibre), layer 2 is ethernet encapsulation (MAC layer), layer 3 is IP packets (or IPv6 or ...), and then further on.
Bridge is a layer2 entity spanning member interfaces in the same way as usual ethernet switch does. As L2 entity it only processes MAC addresses ... which in devices with switch chips actually happen in switch chip hardware. In devices without switch chip (or in special cases in devices with switch chip) traffic between ports actually does travel to main CPU and back, but the software, impelmenting the bridge, does only the beforementioned simple processing.
And device-to-device communication is done as follows: device's L3 stack (e.g. IP stack) determines it needs to send a packet to another device which is within same L3 subnet. Which means the destination is reachable within same L2 segment and thet id can use destination's MAC address as destination of that packet. When a switch or MT bridge sees L2 frame with destination MAC address other than its own, it forwards the frame to the output port where destination device is connected.
When sending device determines that L3 destination is outside its own L3 subnet, it uses an L3 gateway (IP router). So now it uses gatway's MAC address as L2 destination address and sends off the frame. When router receives L2 frame with its own MAC address, it takes it, decapsulates L3 payload and considers L3 destination address.
If you set 'use-ip-firewall' on bridge entity, then usual L2 processing of frames by ROS doesn't happen, rather all frames passing bridge get forwarded to CPU to process.
This is where routing (L3) process starts to unroll ... and with Mikrotiks, this process is entirely done by software run by CPU. Routing can involve complex operations (and firewalling on top of it). And this is the part which I was referring to by "skipping the CPU part"...
There's always possibility of a mismatch between administrators desires and reality ...
Sure. But you must admit that there is also always possibility of mismatch between the intention of the documentation/spec and the reality; usually called bug(s)...
Sure, that's possible as well. To determine which it is, it is necessary to thoroughly understand theory of networking (I don't claim I do
), good knowledge of how device works is necessary as well. One has to be able to do some engineering-grade testing (most of home users are not, surprisingly high share of proffesionals are not either). And only then one can judge if description from manual really diverges from devices' behaviour.