BUG: Port "Forwarding" does not work when NAT is disabled

[cdufour]

Hello,

My (AsusWRT-RMerlin 378.55) setup is such that I do not need NAT (the device acts as "router" rather than "gateway", though with firewall still enabled); consequently, I have disabled NAT in the general WAN settings.

Setting port "forwarding" (better said port "opening") when NAT is disabled does not work; in other words, nothing shows up in 'iptables -L -t filter'.

When NAT is disabled, one would expect for ad-hoc rules to appear in 'iptables -L -t filter' (firewall rules).
On the other hand, of course, nothing ought to appear (and actually doesn't) in 'iptables -L -t nat' (NAT rules).

Adding the 'iptables -L -t filter' rules by hand (firewall scripts) does solve the issue.

I don't know if this is the proper place to report such bug. Please correct me if not.

Also, I'm totally new to AsusWRT source code (on GitHub).
Where should I look for the web interface code ?
Where should I look for the code that translate "port forwarding" configuration into actual "iptables" commands ?

Thanks and best,

Cédric

 

[RMerlin]

Setting port "forwarding" (better said port "opening") when NAT is disabled does not work; in other words, nothing shows up in 'iptables -L -t filter'.

It's called "Forward" because that's what it actually does: it forwards ports using DNAT. It's not the same thing as opening a port, which is why it only works with NAT enabled. This is perfectly normal, and not a bug.

 

[cdufour]

Hello RMerlin,

Thanks for your reply.

I do agree that port forwarding has to do with DNAT. But for DNAT to work, it must go with a corresponding "iptables -t filter -A FORWARD" rule (DNAT it itself just rewrite destination IP and port; it does not allow implicitely the traffic to go through the firewall; that remains the "filter" table purpose).

When NAT is enabled, both 'iptables -t nat -A PREROUTING ... --jump DNAT' and 'iptables -t filter -A FORWARD ... --jump ACCEPT' are created.

Below an example taken from another RT-N66U that I have, running Tomato Shibby in NAT/gateway mode:

root@rt-n66u:/tmp/home/root# iptables -L -n -v -t nat
Chain PREROUTING (policy ACCEPT 1324K packets, 121M bytes)
253K 18M WANPREROUTING all -- * * 0.0.0.0/0 <public-ip>

Chain WANPREROUTING (1 references)
66557 4248K DNAT icmp -- * * 0.0.0.0/0 0.0.0.0/0 to:172.27.0.1
41435 2399K DNAT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 to:<lan-ip>

root@rt-n66u:/tmp/home/root# iptables -L -n -v -t filter
Chain FORWARD (policy DROP 0 packets, 0 bytes)
120K 6895K wanin all -- vlan2 * 0.0.0.0/0 0.0.0.0/0

Chain wanin (2 references)
42027 2473K ACCEPT tcp -- * * 0.0.0.0/0 <lan-ip> tcp dpt:22​

When NAT is disabled, the DNAT rule must no longer get created but the filter rule still must.

Best,

Cédric

 

[cdufour]

PS: unless there is some other firewall configuration page that I missed in the UI when NAT is disabled

 

[cdufour]

https://access.redhat.com/documenta.../html/Security_Guide/s1-firewall-ipt-fwd.html

"If you have a default policy of DROP in your FORWARD chain, you must append a rule to allow forwarding of incoming HTTP requests so that destination NAT routing can be possible"

 

[cdufour]

PS:
Actually port forwarding - allowing LAN resources to be accessible from the WAN - is more about "Chain FORWARD ... ACCEPT" than "Chain PREROUTING ... DNAT".
DNAT is required for port forwarding to work when the network topology mandates NAT.
But if the network topology does not mandate NAT, port forwarding is achieved without DNAT.

 

[Calisro]

I agree it may be a short coming (or potentially a bug?) but why bang your head against the wall. Just add the lines to the firewall script in /jffs/scripts and be done with it. I think 99% of the people use these routers for NAT to the internet and that's why it is geared for that. Just my 2 cents.

 

[cdufour]

Just wanted to contribute to the improvement of this wonderful firmware ;-)

If one can point me where in the source code the GUI/nvram configuration is "converted" to actual iptables commands, I might actually contribute the patch itself.

By the way, I just verified in AsusWRT-RMerlin - with NAT enabled - that the proper "filter" rule actually get created, thought a bit more elegantly than what Tomato Shibby does:

admin@rt-n66u:/jffs/scripts# iptables -L -n -v -t filter
Chain FORWARD (policy DROP 6 packets, 328 bytes)
0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ctstate DNAT​

(ha! that is clever!)

Thanks anyway and happy AsusWRT-ing to all,

Cédric

 

[RMerlin]

Just go with a firewall-start script to apply your own iptables customizations - no need to modify the source code for this.

If you really must, iptables rules get setup in router/rc/firewall.c.

 

[cdufour]

Just go with a firewall-start script to apply your own iptables customizations - no need to modify the source code for this.

Of course. First thing I did ;-)

If you really must, iptables rules get setup in router/rc/firewall.c.

Ooh my!... Now I understand why we'd rather avoid modifying the source code. That would need a heavy re-factoring :-(

As far as I can tell, based on the commit history, it seems Asus itself doesn't see "non-NAT" mode as a real-life scenario I'll try to report that "bug" upstream and see what gives (so much for being an open source contribution evangelist...)

Thanks for your clues,

Best,

Cédric