Quick questions from a noob.
- Has the first rule precedence over the second?
- Could or should I un-tick the Masquerading-checkbox in "Firewall - Zone Settings".
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
ubus call system board
cat /etc/config/network
cat /etc/config/wireless
cat /etc/config/dhcp
cat /etc/config/firewall
fw4 print
1 Like
My guess is, that the first rule has precedence because of its position and that it shows some traffic. And with that, un-ticking Masquerading is optional but doesn't hurt. Would be nice if someone confirms that.
But this also means that if I would have some type of dynamic WAN-type interface, I am not able to set Static Port Outbound NAT in LUCI because it can be only done with a static IP. 
The order of firewall rules matters.
First Match Wins:
When a packet matches the conditions of a rule (source, destination, protocol, etc.), the corresponding action (allow, deny, reject) is executed, and the firewall stops processing further rules for that packet.
This is not entirely true for the accept action in nftables.
If a packet is accepted and there is another chain, bearing the same hook type and with a later priority, then the packet will subsequently traverse this other chain. Hence, an accept verdict - be it by way of a rule or the default chain policy - isn't necessarily final. However, the same is not true of packets that are subjected to a drop verdict. Instead, drops take immediate effect, with no further rules or chains being evaluated.
If masquerading for a zone is enabled, the masquerading rule will always be appended at the end of the srcnat_<zone_name> chain.
Thus, any custom SNAT rules will take precedence and a packet may not reach the general masquerading rule if it meets the conditions of the custom rule.
Note that SNAT is faster than masquerading, but it requires a static IP address, and if that address changes, the router clients will lose access.
3 Likes
Kinda sad. Is there no alternative for a dynamic WAN on OpenWRT? Thanks anyway, like always, @pavelgl .
Just use masquerade?
1 Like
That is not doing Static Port Outbound NAT.
If you do not have a static address but a dynamic address you do a "dynamic port outbound nat" aka masquerade 
Sure but that has consequences, a worse connectivity. And there is stuff like game consoles, smartphones etc. where I want to have very good connectivity. So it is somewhat sad, that OpenWRT has no solution to this. I really want to 
OpenWRT and I do for the footprint and price but there is also stuff that doesn't move forward at all it seems. 
Please tell me more....
And you need static Port Address Translation for that? What?! What for?
It's not OpenWrt, but nftables. And if you need SNAT, then you do SNAT. With a static IP.
(Or you use IPv6. You know. It's the year 2025 already.)
If your interface addresses are dynamic, then you have to use MASQUERADE... OR: write yourself a hook, and if the address on the wan-interface changes, you manipulate your SNAT-rule.
2 Likes
No coder at all, just complaining. Someone should do it for all of us though.
It is easy, you can even sneak in 1st rule on existing chains/hooks.
/etc/nftables.d whatever.nft
chain my_snat {
# snat to {ip1,ip2} persistent
continue
}
chain snat_wan{
jump my_snat
}
flush and re-add my_snat via hotplug script when one of wan IPs change.
obviously fallback is masq.
Dude. It's a few lines of shell script not a C program for wireless hardware driver support...
Edit. https://openwrt.org/docs/guide-user/base-system/hotplug
1 Like
On a second thought...
Yeah maybe... An fw4 wrapper for these kind of SNAT would be nice or at least handy.
Or even just a small hot plug script included in some hot plug extra scripts package. But still the user has to handle these - let's call them - edge cases.
But from a networking perspective, these kinds of setups just suck and introduce so much more confusion. Every layer of NAT just makes it worst. And many NATs to each other is still not nice.
Using IPv6 was no joke. Identify the services or devices which can not do IPv6 and for these you should do such hacky solutions. But only this lagacy shit.
Everything else should be done properly. Just plain routing, or terminate services on a reverse proxy.
Btw for what exactly do you need SNAT rules with static IP address and port number?
Static IPs OpenWRT can do... Here are some examples. Others would be WiFi-Calling on phones and general p2p stuff. I understand why it is not the default but I want to make exceptions myself, regardless of what type of WAN-type IP I have (static or dynamic). Right now, I am using a *Sense router and it can do it out of the box. I think OpenWRT should do somethink like this too (and some other stuff), without scripting on the user part... But I am waiting and will shut up now.
Imo fill a feat request to do snat for multiple static ips.
ruleset way it is possible but no checkbox yet.
If you can't or want do it by yourself then you should at least open up an issue on GitHub with this feature request.
Otherwise literally no one has this on their radar.
The task itself should be kind of low hanging fruit with an hotplug shell script.
A little more of brain with fw4 and lua integration but still a good task.
I don't want to say that your request is stupid or useless or something. No. But OpenWrt has a slightly different target user group. Sure there are people who want to see OpenWrt Hardcore noob friendly, but as it is now it's a framework for people who build networks on their own.
And SNAT with dynamic addresses just call for trouble. Maybe that's the reason no one implemented it.
I ask another time: what exactly requires SNAT in your case? I just want to ensure that that their is really no other option available.
1 Like
I made a feature request in the forum and on github. My original questions in this thread was already answered by pavelgl and this thread should be closed.
Then please mark his post as the thread solution... Thx.
I was wrong the whole time, see here. Sorry for the noise.