NAT loopback/hairpin mode between VLAN's
-
Hi,
My Pfsense firewall has multiple VLAN's. Consider the 'trusted VLAN' and the 'Guest VLAN.
On our trusted VLAN, we have a server/service that is accessible from the outside world via https (port forwarding).
This works correctly.
However it is not accessible from the Guest VLAN, via the WAN-address of the server.I have tried enabling pure NAT-mode (link)
But this doesn't work.
Any pointers? -
@Tommyboy nat reflection of any type would not be optimal setup.. If you have a local service that you want to access while your local. Accessing it locally would be best method.
Either access it directly via its local IP, or setup fqdn that locally resolves to the local ip.
Nat reflection is to me an abomination to all things networking ;) So prob not going to be much help in troubleshooting it.. Another option if its https.. Is just user haproxy vs just straight port forward.. This you should have no issue accessing from remote side or from the lan side via the public IP that haproxy is listening on.
-
@johnpoz I understand. However I don't know what the best way forward would be.
We are using a 'Home Assistant' instance, that isn't accessed very much, but it should be accessible from the other VLAN via the WAN-url.
It is plain/simple forwarded from WAN to LAN. No HAProxy because that would be wayyyy overkill.
Using a LAN url is not possible because the app is configured to be used with 1 url.Any suggestions?
-
@Tommyboy said in NAT loopback/hairpin mode between VLAN's:
configured to be used with 1 url.
So lets say your application goes to app.somedomain.tld that resolves to your public IP lets call it 1.2.3.4
You forward that 1.2.3.4 port X that hits your wan to say 192.168.1.100 port X via a port forward..
If your device is using pfsense for dns, you can create a host override that while your device is local using your local dns app.somedomain.tld vs resolving to 1.2.3.4 resolves to 192.168.1.100 and it will just directly access it vs having to worry about bouncing off your router..
This takes 2 seconds to setup.. And now devices local on your network would resolve it to the local IP, and devices outside your network resolve it to your public IP..
The only time this is a problem is when the device is hard coded to use some external DNS, or the access to whatever is hard coded to your public IP.. But if your accessing it via a url, ie a fqdn then just setup your local dns to resolve that to your local IP..
-
This was the answer !
Creating a host override in the DNS resolver solved it beautifully!
Thanks for the tip!
-
@johnpoz Well, I have here a scenario in it's not possible for the packets to go through the local/internal network.
I have a pfSense with a /29 public IP (one address in the WAN and others as VIPs). In the LAN side, I have a PBX IP running in a VLAN1, and a STUN/TURN Server running on another VLAN2.
For the PBX I have a VIP with NAT Port Forward Rules, and NAT Outbound Rules;
For the STUN/TURN Server, I also have a VIP with NAT Port Forward Rules, and NAT Outbound Rules;
The IP Phones/Softphones located "in the world" can access the STUN/TURN Server via VIP address.
But the PBX, can't access the VIP address of STUN/TURN Server.
And why do I need this? Because the STUN/TURN Server needs to receive/recognize the Public IP address of the PBX and send back this information to the PBX put this on the SIP packets.
If the PBX reaches the STUN/TURN Server internally, the STUN will return the internal IP to PBX, and this info will be informed in the SIP packets, and then no one on the internet can find the RTP address of PBX.But I didn't find how to make it work here. Any idea?
BR,
