The following command prints the settings for a/the bridge:
/interface/bridge/settings/print
use-ip-firewall: no
use-ip-firewall-for-vlan: no
use-ip-firewall-for-pppoe: no
allow-fast-path: yes
…
Is there another such/similar command for the non-bridge part or setup? (I think I saw such a command somewhere, but can’t find it anymore )
Ie. for disabling/enabling the firewall, or the fast-path.
And: is such a central setting available also for disabling/enabling fasttrack (besides doing it in the firewall rules itself)?
my understanding for use-ip-firewall, is bridged traffic, by default, does not go through the firewall. by ticking this box, you asking such traffic to go through the firewall, therefore involve more CPU and lower performance. but there are cases where you make the decision that you have to inspect bridged traffic using firewall, knowing the cost is CPU time
however, many tasks can be done by Bridge - Filter
non-bridge traffic, likely to be traffic between different subnet or vlan, are IP traffic or encapsulated traffic, therefore go through firewall anyway
This is really confusing b/c my device is in Bridge Mode (all interfaces in same one bridge), and I have the said use-ip-firewall setting not enabled, and I have placed my firewall stuff under “/ip firewall filter”, but the firewall is still functioning (!), (although not that perfect, or even correct yet for my taste; surely a firewall setup issue. But firewall documentation (or the snippets spread all over the wiki, help, forum, the web…) and the reality somehow don’t match, IMHO… )
I would suggest that MT should better publish a comprehensive & professional RouterOS Technical Reference Manual, where everything is documented centrally in a PDF-book.
I for me have unfortunately a hard time to find the necessary information spread all over many web sites (wiki, help, forum, web, blogs, …), of which none is complete by itself, just snippets/crumbs everywhere
FIrewall is always used for traffic being routed … meaning between different IP subnets. The use-ip-firewall=yes option only affects traffic passing bridge which would otherwise skip CPU (because it is within same IP subnet).
Regarding mismatch between reality and documentation: if you think that is so, post firewall filter rule list and describe how it should work in your opinion. There’s always possibility of a mismatch between administrators desires and reality …
I will post my settings, but it is so much to post: address-list(s), firewall rules, the other settings relating the modus of the device it is operating in, and of course screenshots (more than 1) that show the mentioned discrepancies between documentation, logical expectation, and the actual behavior (effect, result) of the device in reality.
I’ll now prepare that all and post it hopefully later today for everybody to study/verify/check. Thx.
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.
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?
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)…
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.
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”…
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.
@mkx, thanks for the explanation, but unfortunately there are still many points unclear, but as already said, I’ll detail and summarize them in a later posting here.
But to clarify: I’m not a home user as you might wrongly have assumed. I’m mainly a professional senior SW developer (C/C++ plus some more unimportant languages), but at the same time also a system and network admin in Linux environments (with a few Windows machines; years ago even with old Novell NetWare systems). I’ve ordinary educations with graduations for the two/three jobs (system and network administration and SW-development) I do in parallel. I’ve even some (now outdated) certifications like CCNA, MCSE+Internet and some more, albeit they are at least 15 years old… So, neither the OSI-stack nor the TCP/IP stack is alien to me . Sure you couldn’t know.
But I do admit that up until now I’ve very little experience with Enterprise network devices (the biggest switches I had had about 24 ports, actually 26); I rather have more experience with SOHO and consumer-grade network devices in small environments/divisions with less than 100 users in their corporate LAN or subnet.
I’m also remote-administering some Internet servers that are hosted at a server hosting company, ie. mail, web, file, domain etc. servers.
Thanks mkx and I also gained some new insights. Looking in the wiki I found this in the bridge page:
/interface bridge port
set [f] horizon=1
And first thought the “f” stood for false but doing a bit of scripting in RouterOS saw that that it standing for find. It would be so nice that the manual would be not that unclear because it is there to help and putting an ‘enigma’ in you explanation is not helpful from the side of Mikrotik.
@msatter, I fully agree. I also find articles and posts, where authors use shorthened commands, most annoying. It hurts readability a lot and I guess it only serves authors to position themselves as some hotshots.
@mutluit: if I knew your background, I would word my posts only slightly differently. After all, besides aiding OP posts serve as source of information for other users with wide range of background. In addition, personally I often find some more descriptive posts very enlightening as they help me to tidy up a part of my knowledge and understanding even if they were present before I read those posts. My personal hero on this forum for this very reason is @sindy.
There are three predefined chains, which cannot be deleted: input > - used to process packets entering the router through one of the interfaces with the destination IP address which is one of the router’s addresses. Packets passing through the router are not processed against the rules of the input chain forward > - used to process packets passing through the router output > - used to process packets originated from the router and leaving it through one of the interfaces. Packets passing through the router are not processed against the rules of the output chain
Ok, then here my firewall rules (in this version the fasttrack stuff is defined only in the forward chain, and also some more of the other restrictions I have omitted to keep it still relatively simple to study):
Now, I can tell you that most of the traffic is accepted in the output chain and to a fraction in the input chain, but there is nothing in the forward chain.
Hello! What about the forward chain? Cf. the documentation above: that’s exactly the discrepancy between documentation and reality I mean!..
Another mystery is: there is more data and packets accepted in the output chain than in input, and as already said: nothing in the forward.
But this can’t be true as there is no service here that sends that much data out: the input chain has to be bigger than the output, but which is actually only a fraction of the output chain.
Here are screenshots to show the counters that verify/confirm what I just said:
No, problem, ok, I’ll throw out that rule and see…
Ok, I now did throw the fasttrack rule out and did a fresh import of all the firewall rules. I already can tell you: the result is the same as before. There is nothing in the forward chain. I’ll shortly post also a new screenshot to demonstrate it.
To me it very much looks like that the output chain should be the input chain, and vice-versa… ie. something in the code could be mixed-up…
And the description/explanation of these default 3 chains in the wiki above seems to be totally wrong.
Reminds me of accounting, I’m in the black, no you are in the red, I have assets, no you have liabilities, that is income, no it is profit. Accounting is a construct engineered to be counter intuitive, until you join the accounting borg. Same with ROS, its seemingly counter intuitive until you join the Latvian Borg.
In other words, until you understand the concepts, your brain will feel like a pretzel. You will be assimilated, its only a matter of time!
)
yet for my taste; surely a firewall setup issue. But firewall documentation (or the snippets spread all over the wiki, help, forum, the web…) and the reality somehow don’t match, IMHO… 
), 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.
