Port forward to server firewall zone won't work unless forwarded thru LAN zone

[mk24]

If your router is the local DNS server for all these networks, you don't need to list it as a DNS server anywhere. option dns is something that beginners like to throw around without knowing what it actually is needed for. In a main router the only place to use it is in the wan configuration when you don't want to use the ISP's default DNS servers.

All these networks need to be in non-overlapping IP4 subnets for the routing to work.

Firewall rules act only when all the conditions are matched. This means that the more conditions you specify, the less likely the rule is to work. In particular on a port forward don't specify the destination zone at all. It is inherent from the destination IP address.

[Azure-Agst]

My bad on the .0 IP, that leg of the network hasn't been fully set up yet on the hardware side so it wasn't in use. Good catch, has been fixed, appreciate it!

@trendy

The rules don't have any hits, try to access it again and repost the iptables-save -c

Bit confused on what you mean by "access it again" here, assuming it means trying the forward again. Still no luck.

However something I think might be of note thanks to @mk24's message: when I unset the internal zone, it still doesn't work; but when I open the config modal in LuCI again, it auto configures to LAN. If I hit save from there, the forward works.

Relevant output of iptables-save -c | grep "DNAT" after the forward is configured with LAN internal zone:

root@cerberus:~# iptables-save -c | grep "DNAT"
[2:96] -A zone_lan_prerouting -s 10.0.0.0/24 -d [Redacted WAN IP]/32 -p tcp -m tcp --dport 8000 -m comment --comment "!fw3: Test (reflection)" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_lan_prerouting -s 10.0.0.0/24 -d [Redacted WAN IP]/32 -p udp -m udp --dport 8000 -m comment --comment "!fw3: Test (reflection)" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_wan_prerouting -p tcp -m tcp --dport 8000 -m comment --comment "!fw3: Test" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_wan_prerouting -p udp -m udp --dport 8000 -m comment --comment "!fw3: Test" -j DNAT --to-destination 10.1.1.5:8000

And the same lines after configuring it with SERVER internal zone:

[0:0] -A zone_servers_prerouting -s 10.1.1.0/24 -d [Redacted WAN IP]/32 -p tcp -m tcp --dport 8000 -m comment --comment "!fw3: Test (reflection)" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_servers_prerouting -s 10.1.1.0/24 -d [Redacted WAN IP]/32 -p udp -m udp --dport 8000 -m comment --comment "!fw3: Test (reflection)" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_wan_prerouting -p tcp -m tcp --dport 8000 -m comment --comment "!fw3: Test" -j DNAT --to-destination 10.1.1.5:8000
[0:0] -A zone_wan_prerouting -p udp -m udp --dport 8000 -m comment --comment "!fw3: Test" -j DNAT --to-destination 10.1.1.5:8000

EDIT: Also regarding both of your posts, I've removed all of the internet DNS config from each of the interfaces and set the DHCP option accordingly.

[trendy]

Okay I got what is wrong and you were describing it wrongly. Your problem is not on the port forward itself, which you never tried because in all cases the hits on the firewall are zero, but on the hairpin nat (or nat reflection) which works when you switch the destination zone, because you are trying to access it from the lan zone.

Instead of trying to access the server by the wan IP when you are in the lan, use the internal IP. If you need a hostname instead of IP, then create one.

[lleachii]

@Azure-Agst

Correct, I used my cell phone on 5G for testing.

@trendy

you are trying to access it from the lan zone.

I apologize for any confusion...I must have not been clear when I inquired. I got an opposite answer.

Yep, you must test from WAN to verify WAN rules.

[Azure-Agst]

No, No, he's right. Initially for testing at the start of the thread I was using my cell phone and the forward was not working as intended. However between now and then, I flicked a few switches thanks to tips from here, Reddit, and even my boss via cell phone. Something changed, and sure enough it is now contactable. In choosing to be hasty in my later replies, I did my testing from the same machine I was configuring from, thus no hits. My bad, pebcak error, I'll take the blame.

I plan on configuring my DNS server so that requests from WAN resolve to the public IP, whereas local requests resolve to the local IP, similar to how @lleachii suggested earlier in the thread. Similarly, If I can figure out exactly what switch I flicked to get this to work, I'll update the post too.

Thanks to everyone for dealing with me and your help.