What is the proper way to execute firewall rules before nat? I am just a beginner but from what i found, natted packets do not enter firewall at all. But what if I want to run a set of rules on ALL traffic entering IN the device through a particular eth port regardless of what happens to it. A good example would be black list. I have seen the scripts e.g. https://github.com/pwlgrzs/Mikrotik-Blacklist or https://www.marthur.com/networking/mikrotik-setup-squidblacklist-firewall/388/ but if it is really true that packets to be natted do not go through any of the chains, those examples are not very good one.
One option would be to do it via firewall>raw but i have never really encountered this so i don’t know its downsides.
Can anyone help out (especially to solve the problem of say blacklist properly)?
B. NAT is done before routing and firewal so you have inspect proper addresses in firewall rules e.g if you DST-NATted packet to internal device then it in it’s header has pair of ORIGNALSRCIP:DSTNATTEDIP instead of ORIGINALSRCIP:ORIGINALDSTIP. If you do alse SRC-NAT then you should match SRCNATTEDIP:DSTNATTEDIP addresses
ad A/ I probably misunderstand everything but wiki says: “Firewall RAW … is very useful for DOS attack mitigation” and "There are two predefined chains in RAW tables: prerouting - used to process any packet entering the router " but you say RAW is any packet originated by the router (and just to make sure by router i understand routerOS device itself not some virtual distinction router or firewall, that is those are packets that come through some physical port)
ad B/ you say “NAT is done before routing and firewal” so how can i inspect “proper addresses” in firewall if it is bypassed?
I consult those packet flow diagrams often but rarely understand them fully these days, they became too convoluted. The problem is that they completely miss nat flow.
Perhaps the issue is the word filter? If if the word was Firewall, would that make the diagram clearer?
Raw is technically considered more efficient to discard packets but Raw has no discrimination and one can block way more than intended by mucking about in this area.
In any case as Bartoz has stated, in the general sense, NAT, ROUTE, FIREWALL. So in the case of port forwarding where one needs to translate packets…
One creates a dst-nat rule that translates the packets and then the translated packets pass by the firewall rule.
Its done a bit differently on Mikrotik compared to other products.
Mikrotik does the bulk of the work on the NAT rule, a. the translation, b. the specifics of where the traffic is heading (which server) etc. and the FIREWALL RULE is a generic, let all dst-nat packets identified in the NAT RULE go by the firewall.
On my older zyxel devices it was the opposite. The NAT rule was generic, in that it forwarded traffic coming in on the desired port and translated it and then the firewall rule ensured the traffic was allowed further and sent it to the right server.
In common, both handled NAT first and then applied the firewall rules.
There are a lot of very interesting presentations that are shared during the MUM meetings. Some of then are really localized and I cannot understand, but many others are in English.
This screenshot was taken from one of them, can’t recall exactly which one at the moment.
Might be interesting to browse through the hundreds of interesting PDF’s etc that might shine some interesting light on a certain subject, or how other deal with it.
BartoszP
If understand correct I have a port forward and want to check it against the firewall filter I would use forward as chain with dst-address as the internal address?
could anyone add where Torch does listen?
It clearly says that
Traffic that appears in torch is before it has been filtered by a Firewall. This means you will be able to see packets that might get dropped by your Firewall rules.
Does it mean just after “Input Interface” or before Input-Filter, Output-Filter or Forward-Filter?
Moreover, does Torch show the translated IPs in the case of NAT?
I’m wondering what I see in the destination column for incoming traffic and not driving nuts thinking about if
@error2 Dont waste your time with youtube bloatware firewall rules.
Simply drop all traffic at end of input chain and forward chain and only add traffic that is allowed.
A clean clear firewall is optimal. If your config is complex, having a KISS firewall setup will permit adjustments and aid troubleshooting.
A messy disorganized bloated firewall will cause you grief, lost hair, unhappy customers or unhappy family members.
It simply looks up the NAT table if the source IP of an incoming packet is listed in the NAT table to translate the destination IP (which is supposed to be the incoming interface IP) to an internal IP
That’s it?
According to packet flow firewall entity does connection tracking magic on ingress packets early (hence forth connection-state is known). Soon after that firewall entity does DST NAT (hence forth connection-nat-state is known). And after that routing decission is made (hence forth chain is known). So when firewall entity starts to evaluate filter rules, it can use those states to match packets.
The rule you quoted matches packets which are not DST NATed (did not trigger any of DST NAT rules) and are establishing new connection (they don’t belong to any of existing connections) and are ingressing via combo1 interface. Action on matched packets is to drop them (and get logged with specified custom prefix).
