Scheduled maintenance: Community will be offline Monday June 17th, 1:00 AM - 6:00 AM (PT)
New Member
Posts: 21
Registered: ‎10-21-2017
Accepted Solution

Guest network unable to reach external public website on the corporate network

Hello,

I'm running into a strange issue on my Unifi Security Gateway Pro, and I'm hoping someone here has seen this before and knows the fix. I feel like I'm missing a setting somewhere...

 

On my corporate network, I have a public, externally accessible website. The firewall and port forwarding are set to send port 80 and 443 traffic to the webhost on the corporate network.

 

The guest wifi network, which is setup as a guest network on a different subnet using the Unifi's DHCP and a public DNS, works perfectly - except when it comes to the website. DNS is pointing guest users to the correct external IP, but it seems like the Security Gateway does not allow the traffic to go "out" then come back "in" on the same WAN IP. The guest network and the corporate network both share the same external public IP, which I'm guessing has something to do with my issue.

 

Any help or guidance would be appreciated. Thanks.


Accepted Solutions
Established Member
Posts: 814
Registered: ‎12-05-2016
Kudos: 263
Solutions: 82

Re: Guest network unable to reach external public website on the corporate network

Something like this should work on the "Guest In" section:

Firewall_Part1.PNG

Firewall_Part2.PNG

Firewall_Part3.PNG

Firewall_Part4.PNG

Cain Tech Solutions | Hosted UniFi/UNMS | Other Services | Serving Eastern NC and more!

View solution in original post

Ubiquiti Employee
Posts: 1,537
Registered: ‎02-28-2017
Kudos: 497
Solutions: 153

Re: Guest network unable to reach external public website on the corporate network

[ Edited ]

@dmveron 
"So my questions are

1) Is this what's supposed to happen?

2) If the answer to 1) is yes, then is my best workaround to have my Guest LAN use a DNS server that returns the website's private IP instead of public one?"

1 -- No, you're supposed to be able to hit the public IP address the hostname resolves to, then the DNAT rule will translate that public address to the private one. This is the NAT hairpin method.
2 -- You can do that, that's generally the recommended method which is called split DNS. Split DNS has a lot of benefits over NAT hairpin, as the server will be able to see the true client IP address rather than having to translate addresses.


I have a post with instructions on how to use split dns by using the USG to return the private address when the hostname is queried: https://community.ubnt.com/t5/UniFi-Routing-Switching/NAT-hairpin-with-public-IP-not-assigned-to-WAN...
Keep in mind with this method, the guest LAN would need to point to the USG for DNS.

I do think I know why your hairpin NAT method is working, though. On my setup, I used the regular "port-forward" node which enables hairpin by default, but since you're doing it in the "service-nat" node, it needs to be done manually. 

Take for example your rule:

"1600": {
          "description": "Hairpin for web server",
          "destination": {
            "address": "1.1.1.1",
            "port": "80,443"
          },
          "inbound-interface": "eth0",
          "inside-address": {
            "address": "10.10.1.1"
          },
          "protocol": "tcp",
          "type": "destination"

The inbound interface here is eth0. I'm guessing that's your LAN interface, but what interface is tied to guest? Is it a VLAN on LAN? For example if it was vlan 20, it would be eth0.20. As far as I remember, the inbound interface has to match the exact interface and not just the parent, however I'm not 100% sure. A good test for that would just be to change that inbound interface to "eth+" instead of "eth0". That will assume all ethernet interfaces.

 

Brandon Jaffe | UniFi Routing & Switching | Austin, TX

View solution in original post


All Replies
Highlighted
Established Member
Posts: 814
Registered: ‎12-05-2016
Kudos: 263
Solutions: 82

Re: Guest network unable to reach external public website on the corporate network

Because you are going Guest -> Corp, you are going to need to add a Firewall exception for that server/ports.

Cain Tech Solutions | Hosted UniFi/UNMS | Other Services | Serving Eastern NC and more!

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

OK, but that's not the setup. The traffic is supposed to go from Guest to Internet to Corporate. I can understand creating internal firewall rules is DNS was returning an internal IP for the website, but as long as DNS returns the public IP of the website to the user on the guest network, I don't understand why I'd need additional internal rules.

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

Update: the guest network and the corporate network now both have their outbound traffic going out over different WAN IPs (but still the same physical interface). Still no-go. Opening internal firewall rules still does not make sense to me since I'm trying to open a webpage on a public IP, not a private one.

 

Thanks.

Established Member
Posts: 814
Registered: ‎12-05-2016
Kudos: 263
Solutions: 82

Re: Guest network unable to reach external public website on the corporate network

The USG has "hairpin Nat" enabled by default, so any outbound traffic destined for an internal resource (like your webpage) never leaves the USG.

Cain Tech Solutions | Hosted UniFi/UNMS | Other Services | Serving Eastern NC and more!

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

Do you know if there's a way to override the default rule for a specific source subnet/VLAN?

 

Thanks.

Established Member
Posts: 814
Registered: ‎12-05-2016
Kudos: 263
Solutions: 82

Re: Guest network unable to reach external public website on the corporate network

Something like this should work on the "Guest In" section:

Firewall_Part1.PNG

Firewall_Part2.PNG

Firewall_Part3.PNG

Firewall_Part4.PNG

Cain Tech Solutions | Hosted UniFi/UNMS | Other Services | Serving Eastern NC and more!

Ubiquiti Employee
Posts: 1,537
Registered: ‎02-28-2017
Kudos: 497
Solutions: 153

Re: Guest network unable to reach external public website on the corporate network

@dmveron  I agree with @cainmp here. I just tested this on my setup here at home:

May 14 14:45:29 USGXG kernel: [GUEST_IN-2001-A]IN=eth1.20 OUT=eth1.30 MAC=<> src=192.168.20.51 DST=192.168.30.20 LEN=52 TOS=0x00 PREC=0x00 TTL=127 ID=17218 DF PROTO=TCP SPT=50933 DPT=5202 WINDOW=65535 RES=0x00 SYN URGP=0


You'll need a guest in rule to accept the "source" address being the guest subnet or client on the guest subnet that's initiating the connection, and the destination address will be the post-natted address (private address) of the port forward. You can add the specific ports on the destination port field if you wish to tighten the rule.

The default rule that blocks this traffic on my setup is rule 3005 "drop packets to restricted subnets". If you don't have those restricted subnets setup in Guest Control > Access control, then the next rule 3006 would most likely block it, "drop packets to intranet" which means all of your "corporate" network subnets.

Brandon Jaffe | UniFi Routing & Switching | Austin, TX
New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

Thank you both. I will try this tonight or tomorrow and report back.

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

I'm having odd results, but perhaps it is working as intended.

 

Followed the steps in the GUI using @cainmp 's screen shots. Let's say my setup looks like this:

Corp LAN has a public IP of 1.1.1.1

Guest LAN has a public IP of 1.1.1.5

Website hosted on corp LAN (so external DNS is 1.1.1.1) is on 10.10.1.1

Guest LAN uses a public DNS, such as 8.8.8.8

 

Using the guest-in rules, here's what's happening when trying to get to the website from the guest network:

Accessing http://www.mywebsite.com/ fails to load

Accessing http://1.1.1.1/ fails to load

However, accessing http://10.10.1.1/ is successful

 

So my questions are

1) Is this what's supposed to happen?

2) If the answer to 1) is yes, then is my best workaround to have my Guest LAN use a DNS server that returns the website's private IP instead of public one?

 

Thanks.

Established Member
Posts: 814
Registered: ‎12-05-2016
Kudos: 263
Solutions: 82

Re: Guest network unable to reach external public website on the corporate network

@dmveron based on @UBNT-jaffe's comments, you will need to tweak my recommendation a bit. Screenshot 3 should be the public IP of the corp network, not the private address like I suggested.

Cain Tech Solutions | Hosted UniFi/UNMS | Other Services | Serving Eastern NC and more!

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

I tried @cainmp suggestion to change the destination IP from private to public, but still a no-go.

 

@UBNT-jaffe stated "the destination address will be the post-natted address (private address) of the port forward" so private IP still seems to be the correct one

 

I appreciate the help - I feel like I must be missing something somewhere. Thanks.

New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

Here's my config.gateway.json file if that helps (IPs changed to the example IPs from above)

{
  "interfaces": {
    "ethernet": {
      "eth2": {
        "address": [
          "1.1.1.1/24",
          "1.1.1.2/24",
          "1.1.1.3/24",
          "1.1.1.4/24",
          "1.1.1.5/24"
        ]
      }
    }
  },
  "service": {
    "nat": {
      "rule": {
        "1100": {
          "description": "DNAT for web server",
          "destination": {
            "address": "1.1.1.1",
            "port": "80,443"
          },
          "inbound-interface": "eth2",
          "inside-address": {
            "address": "10.10.1.1"
          },
          "protocol": "tcp",
          "type": "destination"
        },
        "1600": {
          "description": "Hairpin for web server",
          "destination": {
            "address": "1.1.1.1",
            "port": "80,443"
          },
          "inbound-interface": "eth0",
          "inside-address": {
            "address": "10.10.1.1"
          },
          "protocol": "tcp",
          "type": "destination"
        },
        "5100": {
          "description": "SNAT for web server",
          "outbound-interface": "eth2",
          "outside-address": {
            "address": "1.1.1.1"
          },
          "protocol": "tcp",
          "source": {
            "address": "10.10.1.1"
          },
          "type": "source"
        },
        "5500": {
          "description": "SNAT for Guest VLAN",
          "outbound-interface": "eth2",
          "outside-address": {
            "address": "1.1.1.5"
          },
          "protocol": "all",
          "source": {
            "address": "172.16.16.1/24"
          },
          "type": "source"
        }
      }
    }
  },
  "firewall": {
    "name": {
      "WAN_IN": {
        "rule": {
          "3100": {
            "action": "accept",
            "description": "Firewall for web server",
            "destination": {
              "address": "10.10.1.1",
              "port": "80,443"
            },
            "protocol": "tcp",
            "log": "enable"
          },
          "3110": {
            "action": "accept",
            "description": "Hairpin FW for web server",
            "destination": {
              "address": "10.10.1.1",
              "port": "80,443"
            },
            "protocol": "tcp",
            "source": {
              "address": "1.1.1.1"
            },
            "log": "enable"
          }
        }
      }
    }
  },
  "port-forward": {
    "hairpin-nat": "enable",
    "lan-interface": [
      "eth0"
    ],
    "wan-interface": "eth2",
    "rule": {
      "2100": {
        "description": "Hairpin Portfoward for web server",
        "forward-to": {
          "address": "10.10.1.1"
        },
        "protocol": "tcp",
        "original-port": "80,443"
      }
    }
  }
}

Thanks again in advance!

Ubiquiti Employee
Posts: 1,537
Registered: ‎02-28-2017
Kudos: 497
Solutions: 153

Re: Guest network unable to reach external public website on the corporate network

[ Edited ]

@dmveron 
"So my questions are

1) Is this what's supposed to happen?

2) If the answer to 1) is yes, then is my best workaround to have my Guest LAN use a DNS server that returns the website's private IP instead of public one?"

1 -- No, you're supposed to be able to hit the public IP address the hostname resolves to, then the DNAT rule will translate that public address to the private one. This is the NAT hairpin method.
2 -- You can do that, that's generally the recommended method which is called split DNS. Split DNS has a lot of benefits over NAT hairpin, as the server will be able to see the true client IP address rather than having to translate addresses.


I have a post with instructions on how to use split dns by using the USG to return the private address when the hostname is queried: https://community.ubnt.com/t5/UniFi-Routing-Switching/NAT-hairpin-with-public-IP-not-assigned-to-WAN...
Keep in mind with this method, the guest LAN would need to point to the USG for DNS.

I do think I know why your hairpin NAT method is working, though. On my setup, I used the regular "port-forward" node which enables hairpin by default, but since you're doing it in the "service-nat" node, it needs to be done manually. 

Take for example your rule:

"1600": {
          "description": "Hairpin for web server",
          "destination": {
            "address": "1.1.1.1",
            "port": "80,443"
          },
          "inbound-interface": "eth0",
          "inside-address": {
            "address": "10.10.1.1"
          },
          "protocol": "tcp",
          "type": "destination"

The inbound interface here is eth0. I'm guessing that's your LAN interface, but what interface is tied to guest? Is it a VLAN on LAN? For example if it was vlan 20, it would be eth0.20. As far as I remember, the inbound interface has to match the exact interface and not just the parent, however I'm not 100% sure. A good test for that would just be to change that inbound interface to "eth+" instead of "eth0". That will assume all ethernet interfaces.

 

Brandon Jaffe | UniFi Routing & Switching | Austin, TX
New Member
Posts: 21
Registered: ‎10-21-2017

Re: Guest network unable to reach external public website on the corporate network

@UBNT-jaffe changing the eth0 to eth+ did the trick!

 

You are correct, my corporate LAN on the native VLAN is eth0, so the guest network on VLAN 20 would be eth0.20, if I'm understanding correctly.

 

The hairpin rule in my json file came from a tool I found at 

https://codepen.io/codycode/full/aVWZvd/

which was extremely helpful when I first started and really did not know what I was doing.

 

I changed the destination IP back to private IP (to match the screen shots from @cainmp ), reprovisioned, and perfection!

 

I will look into the split DNS, but this will work for now so I can move on to other tasks. Are there any issues with using eth+ instead of specifying each interface? If there are issues I should be aware of, can I just create a list such as:

"inbound-interface": "eth0,eth0.20",

 ?

 

Once again, thank you.

Ubiquiti Employee
Posts: 1,537
Registered: ‎02-28-2017
Kudos: 497
Solutions: 153

Re: Guest network unable to reach external public website on the corporate network

Yeah I don't generally recommend that tool as it's not full-proof in various situations. There shouldn't be any issues with using eth+, I've recommended that method to multiple users in the past. The "inbound-interface" node will only allow you to select one interface, it can't be comma separated. You can create multiple rules with the same criteria, only changing the inbound-interface, but this method is more for convenience and future-proofing.
Brandon Jaffe | UniFi Routing & Switching | Austin, TX