Posted: Mon Oct 23, 2017 4:11 Post subject: NAT Hairpinning on Isolated WLAN?
I've got a stumper here. Why can't I hit the WAN interface from an isolated WLAN interface?
Setup is simple (see diagram): LAN is on default br0, WLAN (eth1) is on br1. Firewall rules put in place to isolate br1 from br0 so that guest wireless devices on br1 cannot access the LAN on br0.
Problem: While firewall rules effectively isolate br1 from br0, they also prevent br1 from accessing the WAN interface which is problematic because I still want guest wireless devices to be able to hit my WAN IP and access port-forwarded services. Basically, "NAT Hairpinning" or "WAN NAT redirection" is not working. It seems like anything that prevents access to br0 also prevents hairpinning.
Here are the FW rules to isolate br1 from br0 (from wiki):
Code:
iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP (breaks hairppinning)
iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP (allows hairpinning but breaks isolation)
iptables -I FORWARD -i br1 -d `nvram get lan_ipaddr`/`nvram get lan_netmask` -m state --state NEW -j DROP (breaks hairppinning)
iptables -I INPUT -i br1 -m state --state NEW -j DROP (allows hairpinning but breaks isolation)
All of these rules are necessary to isolate the bridges while allowing wireless devices access to the internet. However, all of these rules either break hairpinning or allow communication between bridges which is problematic. I want guest wireless devices to be isolated from the LAN while able to access the internet and the WAN interface. Expert input is appreciated.
Don't really know what you have there.
What router you have?
What dd-wrt build is on it?
What router does WLAN on eth1 or eth2?
Did you make VLANs and bridge the wireless to it?
I guess I must be missing something ... or maybe just been up too long
Thanks, I've already got guest WiFi configured (just like in the link you provided) but the issue here is how do I allow the guest WiFi access to the WAN interface (public IP of the router).
There has got to be a way to isolate a WLAN (prevent it from accessing other LANs) while at the same time allowing it to access the WAN interface. This is referred to as "hairpinning" and is supported by DD-WRT as evidenced by the ability of devices on the primary LAN to ping the WAN IP without any issues. Devices on the WLANs however are unable to. _________________ Hardware: RT-AC68U - Firmware: DD-WRT v3.0-r35898 std - Kernel: 4.4.131
Thanks, I've already got guest WiFi configured (just like in the link you provided) but the issue here is how do I allow the guest WiFi access to the WAN interface (public IP of the router).
There has got to be a way to isolate a WLAN (prevent it from accessing other LANs) while at the same time allowing it to access the WAN interface. This is referred to as "hairpinning" and is supported by DD-WRT as evidenced by the ability of devices on the primary LAN to ping the WAN IP without any issues. Devices on the WLANs however are unable to.
I'm just sayin if you had a new build 'bout all that is done for you when you set it up
That actually looks very interesting as it entails placing the WLANs on a different bridge. I see potential, will give it a try. Thanks! _________________ Hardware: RT-AC68U - Firmware: DD-WRT v3.0-r35898 std - Kernel: 4.4.131
No method of creating a guest wireless network on the DD-WRT allows WAN NAT Hairpinning (even with upgraded firmware). Guest devices can only reach the internet but not the WAN interface. _________________ Hardware: RT-AC68U - Firmware: DD-WRT v3.0-r35898 std - Kernel: 4.4.131
Last edited by diyegr on Wed May 09, 2018 4:36; edited 1 time in total
To throw a wrench in your testing, I believe NAT hairpinning has become broken for *all* scenarios during the time this thread was idle. I just upgraded from a build from early November (working) to the current build (not working). My scenario isn't even across isolated networks.
To progress on your testing, I'd suggest using build 11-04-2017-r33679 , which from my personal experience worked with "normal" hairpinning, so you can test your isolation scenario.
I believe NAT hairpinning has become broken for *all* scenarios...
yea it is generally screwed on most routers using last couple public releases ... and completely screwed on EA8500 with any k4.9 or k4.14 builds of last several weeks
k3.18.x completely broken NAT loopback on wndr3700v4 last two public releases ....yea this is atheroes --- but the point is
Rather than SNAT'ing the inbound traffic w/ the router's own lan IP *only* when the connection attempt comes from inside the LAN, it also does the same when coming from the internet side of the WAN, which is unnecessary.
Odd, that doesn't match my experience, if I understand correctly. I've never configured a GUI option relating to NAT loopback, but it has always "just worked", without SNATing unnecessarily.
For example, I run a couple common services (HTTP and Windows Remote Desktop) on my PC, and forward these through non-standard ports to sidestep the majority of lazy port scans. My http logs correctly show internet-based source addresses for my traffic. And when my phone is on my internal WLAN, I can (usually, it's broken this month as we know) use my public-facing dynamic dns hostname and remapped port to connect to my local PC's remote desktop. In fact, the reason I'm onthe forum looking up discussions of loopbacks is to confirm this is a known new issue.
Does my description match what you'd expect to find? A local device can use the firewall's remapped ports and external IP to connect to a local device, and yet internet traffic flows through with its original source address.
This is why in my own PBR scripts ( https://pastebin.com/u/eibgrad ), I don't allow either NAT loopback nor QoS (which also uses marks) to be used at the same time as my scripts. Just too much risk of a conflict. However, I do reimplement NAT loopback, but without using marks. In fact, I implement it very close to the way tomato does!
Makes sense, I haven't had cause to script to these tables, but I see the risk you mention. Related to your linked scripts, though, I did recently try and set up an openvpn server on several devices with current builds and found that to send my CPU to 100% of a core. Same issue tracked here:
http://svn.dd-wrt.com/ticket/5807 so I gave up for now on setting up the vpn.