To set a firewall rule in the Forward chain for a packet that is dst-NAT’d, you can specify a destination IP address. Is this address supposed to be the original packet dstIP as it arrives (the public IP address, which is not very helpful) or the dstIP on the LAN that the dst-NAT process puts in the packet?
Thanks,
Look at packet flow reveals that DST-NAT is done way before firewall filter rules … meaning that firewall filter rules will see dst-address with already replaced values.
And, to make things complete: SRC-NAT comes after firewall so in that case firewall will see original src-address.
Thank you. That is exactly what I wanted to find out.
Thanks mkx. Although I have seen that before, I figured it was a good one to bookmark.
This is like any consumer router, firewall rules take place after DST-NAT
However for the sake of debate, it matters little in the mikrotik setup.
We make a blanket rule that simply permits port forwarding and all the details are in the destination nat rule. THERE IS NO NEED FOR ANYTHING ELSE IN FIREWALL RULE.
add chain=forward action=accept connection-nat-state=dstnat
add chain=dstnat action=dstnat dst=address=WANIP dst-port=9898 protocol=tcp to-address=192.168.10.24 to-port=14145
In this example we have port translation and in other words, the port hitting the router (9898) hits the server at 14145 and the mikrotik firewall doesnt care.
In consumer routers or prosumer routers one has to be cognizant of the changed port for firewall rules.
TL;DR: @anav, your personal preference of constructing firewall (filter rules and NAT rules) doesn’t matter in context of question by @OP.
The example above only takes care that access to forwarded port works. But what if fw admin wants to allow access to forwarded service only to certain clients? The task can be done in two ways:
- one adds filter criteria to NAT rule itself (e.g. src-address-list). This works fine if all the filter criteria work together in AND manner … one can not OR different criteria together
- one adds filter criteria to firewall filter rule. If one needs to OR criteria, that’s possible by adding additional rules, individual rules then work as if the critera was ORed together. And if one uses this approach, it’s essential to add filter critera which match NAT rule so that these criteria are selective (in case there are multiple NAT rules with different filter criteria)
Example would be e.g. SSH port forwarded where service is available if client comes from remote address present on cerrain address list … OR client uses certain source port number (well, this one is hard to achieve, but let’s use it for argument sake). It’s not possible to combine these two criteria into single rule. It’s also possible to selectively reject access to forwarded port using filter rules (where rules are subset of rules allowing access) while that’s not possible using NAT rule.
So all in all, using firewall filter rules to control accessibiliry of NATed service allow for fine tuned access rights.
Understood.