1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.
Dismiss Notice

Welcome To SNBForums

SNBForums is a community for anyone who wants to learn about or discuss the latest in wireless routers, network storage and the ins and outs of building and maintaining a small network.

If you'd like to post a question, simply register and have at it!

While you're at it, please check out SmallNetBuilder for product reviews and our famous Router Charts, Ranker and plenty more!

NAT Loopback on restricted guest wifi network(s)

Discussion in 'Asuswrt-Merlin' started by bengalih, Sep 11, 2019.

  1. bengalih

    bengalih Regular Contributor

    Joined:
    Dec 13, 2016
    Messages:
    80
    I just spend this evening reloading my RT-AC68U with the latest firmware (384.13).

    Decided to try to setup my guest networks again as I had issues last time I attempted this because I don't use the built-in DHCP server for my LAN, but rather a server on my internal network. This caused issues because the client's on my guest SSID(s) were not able to get IP addresses.

    After tinkering around through various posts and configurations here I was able to create a proper dnsmasq.postconf file which allows my two guest networks to get DHCP from the local dnsmasq server to get Internet access while still being blocked from my local LAN.

    However, I am unable to use NAT loopback on those devices to allow me access to my internal servers using my public IP. For instance, I have several NAT mappings such as:

    myserver.mydomain.com:12345 > 10.10.10.102:8000

    On my internal LAN network (10.10.10.0/24) I am able to access this box using either of the above addresses. I tend to use the public IP via myserver.mydomain.com since NAT loopback works great on my internal LAN and I can more easily use/remember this even when remote.

    However, when I attempt to access this server via my guest wifi I am not able to reach it. Obviously I wouldn't expect to be able to get it via the local 10.10.10.102 address, as I turned off Intranet access from these networks.

    However, because the NAT loopback isn't working/configured appropriately I am unable to reach it even using the public address. I am hoping there is a way to fix/disable NAT loopback on these guest networks so devices on them can at least access my internal servers - at least by going out, and then back in again over the WAN interface.

    In addition to the proper DHCP configuration for the guest wifi networks, the hardest part to figure out was the iptables/ebtable rules which ended up looking something like this (for my wl0.1 guest wifi):

    Code:
    /usr/sbin/ebtables -t broute -I BROUTING -p arp -i wl0.1 -j DROP
    /usr/sbin/ebtables -t broute -I BROUTING -p ipv4 -i wl0.1 -j DROP
    /usr/sbin/ebtables -t broute -I BROUTING -p ipv6 -i wl0.1 -j DROP
    
    /usr/sbin/iptables -I FORWARD -i wl0.1 -j ACCEPT
    /usr/sbin/iptables -I FORWARD -i wl0.1 -d 10.10.10.1/24 -j DROP
    /usr/sbin/iptables -I INPUT -i wl0.1 -j ACCEPT
    /usr/sbin/iptables -I INPUT -i wl0.1 -d 10.10.10.1/24 -j DROP
    
    I can provide more in-depth iptables configuration if needed, but everything else should be default apart from what I have configured for my various port-forwards and the above rules needed for the guest wifi.

    Do I have any options to allow the devices on my guest wifi networks to access my servers via public interface while still restricting them from access the local intranet?
     
  2. Jack Yaz

    Jack Yaz Part of the Furniture

    Joined:
    Apr 20, 2017
    Messages:
    2,422
    You probably need to add an allow rule for iptables forward, with a source interface of eth0/ppp0 depending on your WAN type

    Your current rule will block any traffic destined for that server, irrespective of being lan or wan sourced. I don't think nat loopback is a problem here
     
  3. bengalih

    bengalih Regular Contributor

    Joined:
    Dec 13, 2016
    Messages:
    80
    Thanks. I'm kind of a dilettante with iptables, so I don't totally grasp your advice.
    Can I give you some more info that would help you give some better guidance?

    I'm a bit confused about WAN connection type - I'm definiely not ppp connection, I am ethernet connected to my ISP modem, but my public IP shows up on the vlan connection:

    Code:
    vlan2     Link encap:Ethernet  HWaddr 1C:B7:2C:xx:xx:xx
              inet addr:68.xx.xxx.225  Bcast:68.xx.xxx.255  Mask:255.255.252.0
              UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
              RX packets:319660 errors:0 dropped:0 overruns:0 frame:0
              TX packets:122086 errors:0 dropped:0 overruns:0 carrier:0
              collisions:0 txqueuelen:0
              RX bytes:168014286 (160.2 MiB)  TX bytes:24846329 (23.6 MiB)
    
    I modeled my rules based on some I found within the forums after several other configurations didn't work for me. These might not be the most ideal rule set, but it does appear that they are all necessary in combination to get the desired effect.

    I realize it will block anything going to the 10.10.10.x LAN, but if my guests are going out over the internet, are they technically accessing that LAN by hitting the WAN interface and NATting?

    Appreciate any more help you can give and I'm happy to most more configuration or take recommendations for a better setup.

    thanks
     
  4. Jack Yaz

    Jack Yaz Part of the Furniture

    Joined:
    Apr 20, 2017
    Messages:
    2,422
    Let me have a think about what rule changes are necessary, as having re-read your rules it may be more complicated than i first thought.

    What port forwards have you set up, how did you implement nat mappings, and what are you using as a test address?
     
  5. bengalih

    bengalih Regular Contributor

    Joined:
    Dec 13, 2016
    Messages:
    80
    I have about a dozen port forwards set up. I've configured them through the GUI (WAN > port forwarding).
    Here is my VSERVER chain from the NAT iptables :
    Code:
    Chain VSERVER (1 references)
     pkts bytes target     prot opt in     out     source               destination
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:54322 to:10.10.10.102
    55093 7142K DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:54322 to:10.10.10.102
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:54321 to:10.10.10.102
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:54321 to:10.10.10.102
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11462 to:10.10.10.102:8113
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11463 to:10.10.10.102:8114
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:51079 to:10.10.10.102
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:51079 to:10.10.10.102
       17   704 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:5000:5100 to:10.10.10.102
       37 16467 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:5000:5100 to:10.10.10.102
      202 11408 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11460 to:10.10.10.102:32400
        0     0 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpt:11460 to:10.10.10.102:32400
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11456 to:10.10.10.102:9896
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11457 to:10.10.10.102:9897
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11458 to:10.10.10.102:9898
       21  1260 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11459 to:10.10.10.102:9899
        1    40 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpts:5101:5199 to:10.10.10.140
        1   441 DNAT       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:5101:5199 to:10.10.10.140
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1007 to:10.10.10.102:1007
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:1688 to:10.10.10.102:1688
        0     0 DNAT       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            tcp dpt:11461 to:10.10.10.102:8920
    
    I'm not sure what you mean as a test address? I don't want to provide my actual IP for security purposes, but an example of my usage is:

    http://access.mydomain.com is configured via external DNS provider to URL redirect to https://access.mydomain.com:11456 which resolves to the WAN side of my router.
    Router then NATs that as shown in the table above to https://10.10.10.102:9896 internally.

    My next project was to install nginx as I have one application that is problematic with https and therefore I need to terminate the SSL connection at the router and reverse proxy it back to the server. I haven't worked with nginx yet and so will be getting into that config over the next week or so. I'm not sure how that will change my forwards, as I think with nginx I can send everything to 443 and it will proxy to the correct server based on the incoming hostname (e.g. server1.mydomain.com > 10.10.10.102:8000, server2.mydomain.com > 10.10.10.10:9000, etc, etc...).
    Perhaps once I have nginx this issue might resolve (or perhaps it breaks NAT loopback even from my main LAN!).

    So, let me know if you have any ideas but don't kill yourself yet because I'd like to get nginx up and running and then work all the little annoyances like this out.
     
  6. bengalih

    bengalih Regular Contributor

    Joined:
    Dec 13, 2016
    Messages:
    80
    So I setup nginx today and got all my access setup through there. It appears that I don't have any issues accessing my nginx interface and having it do the redirects on any of my networks. So while it would still be fascinating to understand the complexities of getting this working via iptables, I guess there isn't a need for it in my case any longer.

    I need just a single iptables command to allow 443 traffic into my nginx server and the rest just works.

    thanks.
     
    Jack Yaz likes this.