Modify

Opened 3 years ago

Last modified 20 months ago

#18057 assigned defect

NAT Loopback, NAT Reflection appears to be broken.

Reported by: wbr@… Owned by: jow
Priority: response-needed Milestone:
Component: base system Version: Barrier Breaker 14.07
Keywords: nat loopback reflection Cc:

Description

In LuCI, if I create a wan forwarding rule from port 2222 to port 22 on any router interface, and I check NAT Loopback, the reflection rules are not created in iptables. This broke somewhere between r42475 and r42682. It is still broken in r42801.

/etc/config/firewall

config redirect
	option target 'DNAT'
	option src 'wan'
	option src_dport '2222'
	option dest_port '22'
	option name 'Remote Admin'
	option dest 'lan'
	option proto 'tcp'

Then after firewall (or entire router) restart

root@WNDR3800:~# iptables-save | grep 22
-A zone_wan_prerouting -p tcp -m tcp --dport 2222 -m comment --comment "Remote Admin" -j REDIRECT --to-ports 22

Attachments (0)

Change History (32)

comment:1 Changed 3 years ago by wbr@…

Another aspect of this problem: If a destination IP is specified as any router IP, then that IP will not be honored in the resulting iptables rule. For example, if the above LuCI config had a dest_ip specified as a router IP, either LAN or WAN, that IP would not be part of the resulting iptables rule. The resulting rule would look exactly like the above rule - with no specified destination IP.

So to recap, unless a non-router-IP is specified, the resulting iptables rule(s) become a single REDIRECT with no destination IP, instead of a DNAT rule (with two accompanying NAT-reflection rules).

comment:2 Changed 3 years ago by nold@…

Same for me on Netgear WNDR3800. Forwarding to Router dosn't work.
Worked fine with any BB RCx.

comment:3 Changed 3 years ago by anonymous

Same for me on WD N750. Forwarding to Router dosn't work.
Worked fine with Barrier Breaker RC3.

comment:4 Changed 3 years ago by slartibardfast

I think this was introduced by commit 10b9190c9d846ae0f9cfd0b0af3d93a99136a40a
'redirect: emit -j REDIRECT rules for local port forwards' to firewall3.

attached is a patch that makes the local forwards REDIRECT only if reflection is turned off.

fixed it for me, but not sure if the approach is correct!

https://www.dropbox.com/s/jygilc190bn8ylt/0001-redirect-only-for-local-port-forwards-without-reflection.patch?dl=0

(*I updated the patch 20150216, the first one only fixed the problem for other stations, cheers!)

Last edited 3 years ago by slartibardfast (previous) (diff)

comment:5 Changed 3 years ago by seur18

Same for me on TP-Link TL-WR1043ND v2.1

Last edited 3 years ago by seur18 (previous) (diff)

comment:6 Changed 3 years ago by anonymous

Have you submitted the patch to jow (fw3 author/maintainer) ?

comment:7 Changed 3 years ago by wbr@…

Any update on this? Still appears to be broken in BB r44952.

comment:8 Changed 3 years ago by anonymous

I've recently also come across this bug under CC r45583 ...

Weirdly, fw3 produces correct reflection for rules for 5 out of 6 port forwards.

comment:9 Changed 3 years ago by seur18

I've yet the same problem on last build...

comment:10 Changed 3 years ago by anonymous

Anyone can confirm if this has been fixed on CC RC1?

comment:11 Changed 3 years ago by nold@…

Still broken in CC RC1 for me on WNDR3800:

# /etc/init.d/firewall restart
Warning: Section @redirect[3] (8443-2-SSH) refers to a destination address on this router, assuming port redirection

Results in:
# iptables -L -n -t nat
REDIRECT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:8443 /* 8443-2-SSH */ redir ports 22

But can't connect...

comment:12 Changed 3 years ago by anonymous

Is this still broken?

comment:13 Changed 2 years ago by nold@…

Still broken in RC3...

comment:14 Changed 2 years ago by anonymous

I have recently reach at this issue with my RC3 raspberry pi version. Is there any work at this side?

comment:15 Changed 2 years ago by anonymous

Excuse me. Does the NAT loopback problem exist in the latest version 15.05?

comment:16 Changed 2 years ago by anonymous

Sorry, I have flashed my router with openwrt, but I am not familiar to openwrt. I just arrived to this post about the NAT reflection. Have the problem been fixed successfully?
About comment 4, I would like to know how to put the code into openwrt to solve the problem.
I just learned about openwrt, and I don't know much about coding.
Please help. Thank you.

comment:17 Changed 2 years ago by nold@…

Still broken in CC 15.05 on WNDR3800...

comment:18 Changed 2 years ago by jow

  • Owner changed from developers to jow
  • Priority changed from normal to response-needed
  • Status changed from new to assigned

Can anyone please explain to me what exactly is broken? There was one minor behaviour change in the past (no loopback for redirects destined to the router) but that got reverted.

I'd like to understand what brokeness you guys refer to in order to fix it.

comment:19 Changed 2 years ago by seur18

The issue is that when you create a firewall rule with nat loopback over wan and the router, you cannot access to your router using it.

comment:20 follow-up: Changed 2 years ago by anonymous

I am experiencing this as well, although not trying wan-to-lan but LAN-to-LAN

iptables -L -t nat | grep 22201

DNAT tcp -- anywhere anywhere tcp dpt:22201 /* INT-SSH-iPhone-Reflection */ to:192.168.1.223:22

comment:21 in reply to: ↑ 20 Changed 2 years ago by anonymous

Replying to anonymous:

I am experiencing this as well, although not trying wan-to-lan but LAN-to-LAN

iptables -L -t nat | grep 22201

DNAT tcp -- anywhere anywhere tcp dpt:22201 /* INT-SSH-iPhone-Reflection */ to:192.168.1.223:22

To clarify above ... when on the LAN, and trying to telnet to the router (lets say thats IP 192.168.1.254) so "telnet 192.168.1.254 22201" it doesnt connect, but telneting to "192.168.1.223 22" works

comment:22 Changed 2 years ago by jow

Did that lan-to-lan nat loopback ever work?
The dnat-to-router-wan-ip case should be fixed in trunk, if not please paste the relevant uci rules here.

comment:23 Changed 2 years ago by anonymous

If you mean lan-to-lan for port 22, today was the first day I tried it actually, (and found this article while researching why it wasnt working) ... if you mean lan-to-lan in general, then yes, I have several internals that work, below is an example of a working one

DNAT tcp -- anywhere anywhere tcp dpt:4433 /* INTERNAL-vSphere to ESXi */ to:192.168.1.251:443

comment:24 Changed 2 years ago by jow

Please provide an example of a working and non working rule. (Excerpts from uci, not the iptables listing).

Last edited 2 years ago by jow (previous) (diff)

comment:25 Changed 2 years ago by anonymous

WORKS:

config redirect

option target 'DNAT'
option src 'lan'
option dest 'lan'
option proto 'tcp'
option src_dport '4433'
option dest_port '443'
option name 'INTERNAL-vSphere to ESXi'
option dest_ip '192.168.1.251'

DOESNT SEEM TO WORK:

config redirect

option target 'DNAT'
option src 'lan'
option dest 'lan'
option proto 'tcp'
option src_dport '22201'
option dest_ip '192.168.1.203'
option dest_port '22'
option name 'INT-SSH-iPhone-Reflection'

comment:26 Changed 2 years ago by jow

Does one of the both IPs '192.168.1.251' and '192.168.1.203' belong to the router itself?

comment:27 Changed 2 years ago by anonymous

no, 251 is ESXI server and 203 is the iPhone ... but I just got it to work, although I dont quiet understand it ...

the difference with working and non-working is that the ESXi one has a WAN based rule as well as the LAN rule. The SSH one does not. I just added the external route for 22201 (which I dont actually want) and it worked. I started thinking that its just going outside to get back inside, but if you remove the LAN to LAN rule for 4433 for example, telnet to 192.168.1.254 4433 doesnt work anymore. I have included all the relevant rules below ... so is there a way to do the 22 one without needing the WAN rule?

config redirect

option target 'DNAT'
option src 'lan'
option dest 'lan'
option proto 'tcp'
option src_dport '22201'
option dest_port '22'
option dest_ip '192.168.1.203'
option name 'INT-SSH-iPhone-Reflection'

config redirect

option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '22201'
option dest_ip '192.168.1.203'
option name 'SSH-iPHone'
option dest_port '22'

###############################

config redirect

option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'tcp'
option src_dport '4433'
option dest_port '443'
option name 'vSphere to ESXi'
option dest_ip '192.168.1.251'

config redirect

option target 'DNAT'
option src 'lan'
option dest 'lan'
option proto 'tcp'
option src_dport '4433'
option dest_port '443'
option name 'INTERNAL-vSphere to ESXi'
option dest_ip '192.168.1.251'

comment:28 Changed 2 years ago by jow

Thats an entirely different use case. The kind of nat loopback this ticket is about refers to the creation of automatic DNAT+SNAT rule pairs to make external ports forwards (WAN->LAN) available from inside the LAN.

Those magic rules are usually done automatically but only under these conditions:

  • the src zone has masquerading enabled (essentially an indicator whether it is external (i.e. "wan")
  • the IP the forward is redirecting to is not the router itself

The following redirect:

config redirect           
        option name 'SSH J400'
        option src 'wan'      
        option dest 'lan'   
        option proto 'tcp'
        option src_dport '22014'
        option dest_port '22'
        option dest_ip '10.11.12.14'

Will translate to these iptables rules:

-A zone_wan_prerouting -p tcp -m tcp --dport 22014 -m comment --comment "SSH J400" -j DNAT --to-destination 10.11.12.14:22
-A zone_lan_postrouting -s 10.11.12.0/24 -d 10.11.12.14/32 -p tcp -m tcp --dport 22 -m comment --comment "SSH J400 (reflection)" -j SNAT --to-source 10.11.12.13
-A zone_lan_prerouting -s 10.11.12.0/24 -d 95.1.2.3/32 -p tcp -m tcp --dport 22014 -m comment --comment "SSH J400 (reflection)" -j DNAT --to-destination 10.11.12.14:22

As you can see there three IPs involved:

  • 95.1.2.3 - the router wan ip
  • 10.11.12.13 - the router lan ip
  • 10.11.12.14 - the lan host we redirect to

In your LAN-to-LAN forward case the required additional SNAT and DNAT rules are not created automatically and you need to define them yourself.

I'm not sure what you intend to achieve with the iPhone rule, redirect any port 22 TCP traffic from any LAN host to port 22 of 192.168.1.203 ? That will most likely fail if you request e.g. 192.168.1.1:22 and suddenly 192.168.1.203 replies because an intermediate router changed the destination IP. For this reason you need a corresponding SNAT rule where the router will put itself as source so that replies from the redirected .203 get back to the router and then the router needs yet another DNAT rule translating the destination IP of .203's replies back to the IP of the original requesting host.

comment:29 follow-up: Changed 2 years ago by jow

Getting back to the original issue. I assume this ticket is about missing automatic reflection rules in case the destination IP is on the router itself.

A while back I made a change to translate such rules into REDIRECT ones since those are essentially a port remapping (http://nbd.name/gitweb.cgi?p=firewall3.git;a=commitdiff;h=10b9190c9d846ae0f9cfd0b0af3d93a99136a40a). I've reverted that change since (http://nbd.name/gitweb.cgi?p=firewall3.git;a=commitdiff;h=18a503d0125aebc3a8d62dad1c02e6bb1da92eb6) but the corresponding version is not part of CC yet and only available in trunk.

In case you see a case of broken nat loopback, please report back with:

  • Exact used version of the firewall package (opkg list_installed firewall)
  • Relevant parts of /etc/config/firewall
  • Output of iptables-save | grep NAT

comment:30 in reply to: ↑ 29 Changed 2 years ago by KyleS

Replying to jow:

In case you see a case of broken nat loopback, please report back with:

  • Exact used version of the firewall package (opkg list_installed firewall)

root@OpenWrt:~# opkg list_installed firewall
firewall - 2015-07-27

  • Relevant parts of /etc/config/firewall

config redirect

option target 'DNAT'
option src 'wan'
option dest 'fswan'
option proto 'tcp'
option src_dport '14567'
option dest_ip '10.24.96.50'
option dest_port '14567'
option name 'ZNC'

  • Output of iptables-save | grep NAT

-A zone_fswan_postrouting -s 108.180.xxx.xxx/22 -d 10.24.96.50/32 -p tcp -m tcp --dport 14567 -m comment --comment "ZNC (reflection)" -j SNAT --to-source 108.180.xxx.xxx

In my case, I have multiple LAN zones going to a single WAN zone, so reflection seems to be completely broken in this regard.

comment:31 Changed 2 years ago by jefferyto

For anyone affected by this, looks like the commit jow mentioned (18a503d0) didn't make it into CC (it's on 980b7859, one commit behind).

comment:32 Changed 20 months ago by tim@…

Hi Jow, I just upgraded from 12.04 to 15.05.1. I had redirection rules from the router's WAN port to its own LAN IP and these don't work any more with 15.05.1. Here is the output:

# opkg list_installed firewall
firewall - 2015-07-27

# excerpt from /etc/config/firewall

config redirect

option enabled '1'
option target 'DNAT'
option src 'wan'
option dest 'lan'
option proto 'udp'
option src_dport '1195'
option dest_ip '10.1.4.1'
option dest_port '1195'
option name 'OpenVPN port UDP 1195 to unchanging inside IP'

# iptables-save | grep NAT

(no references to the rule above)
...
-A zone_lan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_lan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT
-A zone_wan_forward -m conntrack --ctstate DNAT -m comment --comment "Accept port forwards" -j ACCEPT
-A zone_wan_input -m conntrack --ctstate DNAT -m comment --comment "Accept port redirections" -j ACCEPT

# iptables-save | grep 1195

-A zone_wan_prerouting -p udp -m udp --dport 1195 -m comment --comment "OpenVPN port UDP 1195 to unchanging inside IP" -j REDIRECT --to-ports 1195

Any help is appreciated!
Tim Miller Dyck

Add Comment

Modify Ticket

Action
as assigned .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.