Port forward firewall rule

RouterOS Beginner Basics
1

Finished setting up port forwarding and everything works fine. Before doing this I had a firewall forward rule that blocked access to LAN unless dstnat’d:

add action=drop chain=forward connection-state=new in-interface-list=public_facing connection-nat-state=!dstnat comment="drop access to clients behind NAT from WAN"

Is such a rule required after adding forwarding rules for specific port forward cases and if I have a

add chain=forward action=drop comment="Drop"

As my last forward rule? The old rule doesn’t seem to be catching any packets.

2

The first rule you posted is MT’s try to use single rule instead of two. And it only works with defaukt rules, as soon as you try to change NAT concepts (e.g. when adding hairpin NAT) it stops working.

In principle it’s possible to repkace the rule with two:

add action=accept chain=forward in-interface-list=public_facing connection-nat-state=dstnat connection-state=new
...
add action=drop chain=forward in-interface-list=public_facing

The last one really should be the last rule in forward chain … and it’s different than yours in acting only on connections ingressing through public_facing interfaces (your is indiscriminate and would drop also connections from LAN towards WAN if those packets “survive” other filter rules).
The first one is a general rule allowing all DST NATed traffic. The issue is with NAT rules, which are supposed to be selective (e.g. only allow conections from certain sources) … where there are two possibilities: 1) add matchers to NAT rules or 2) construct multiple firewall filter rules … while both approaches allow to reach the goal, they slightly differ on how packets are processed in software (which one is better depends on particular set of both NAT and filter rules).

When assessing which rule does the processing always keep in mind that rules are evaluated from top to bottom (inside the relevant chain) and the first matching rule executes (and stops processing).
Which means that without seeing complete chain of rules it’s impossible to comment on why certain rule does or doesn’t execute.

3

MT’s try to use single rule instead of two

Ok that’s kind of what I thought was happening so I don’t think I am missing anything as I believe I am covering what is allowed using more specific nat rules as you suggest:

/ip/firewall/filter
add action=accept chain=forward connection-state=new in-interface=wg dst-port=64002 protocol=tcp connection-nat-state=dstnat comment="Allow port forward"
add action=accept chain=forward connection-state=new in-interface=wg dst-port=64002 protocol=udp connection-nat-state=dstnat comment="Allow port forward"
/ip/firewall/nat
add chain=dstnat action=dst-nat dst-address=10.2.0.2 in-interface=wg dst-port=64002 to-address=10.0.40.20 protocol=tcp comment="Port forward"
add chain=dstnat action=dst-nat dst-address=10.2.0.2 in-interface=wg dst-port=64002 to-address=10.0.40.20 protocol=udp comment="Port forward"



your is indiscriminate and would drop also connections from LAN towards WAN

That was the idea, I’m also filtering some inter-vlan traffic which works correctly. Just wanted to get a sanity check, thanks.

4

When doing firewall filters which target specific DST-NAT rules, it’s important to keep in mind that in packet processing, DST-NAT is done sooner than firewall filter rules (see excellent description of packet fliw in ROS). So firewall filter rules have to match rewritten (by DST-NAT rule) dst-* values.
Example of this: if there was DST-NAT rule, forwarding TCP port 22222 to LAN server to port 22, then filter rule would have to match against LAN IP address and TCP port 22. Pair of rules you showed in previous post is fine because DST-NAT rule doesn’t rewrite dst-port.

A related remark: SRC-NAT is done quite late so firewall filter rules have to act on the original (yet unchanged) src-* properties (if applicable).