Trouble with NAT-reflection on 2.3
-
I'm having some issues with NAT reflection.
From an external IP there's no problem to connect by the domain-name (so port is forwarded correctly) but when I try from within the LAN the browser says (trying to translate) "Waiting for available place" (bad translation), then it waits a long time, several minutes, and sometime the connection times out…
I've tried with both pure NAT and NAT + proxy.
EDIT: Fixed it by running "pure NAT" and enable "Enable NAT Reflection for 1:1 NAT" and "Enable automatic outbound NAT for Reflection"
-
Yeah. had same issue.
I had NAT+Proxy.
Pure NAT fixed the issue for me too :)
Thanks for the tips -
That you use nat reflection seems pointless to me.. Why do you not just resolve this fqdn on boxes inside your network to whatever it this private IP address is that your forwarding too. Now your not going through pfsense just to be forwarded back in to access something sitting on your own local network.
-
That you use nat reflection seems pointless to me.. Why do you not just resolve this fqdn on boxes inside your network to whatever it this private IP address is that your forwarding too. Now your not going through pfsense just to be forwarded back in to access something sitting on your own local network.
Not sure what you mean here, not that well versed in network…
I only want to use one setting for all my mobile-clients be it they are outside or inside the LAN(moving back and forth), this is where I use NAT-reflection.
Is there a better way of doing this? -
If the LAN clients are using the DNS on pfSense (which then goes out to the real internet to resolve names by whatever means - resolver or forwarder style), then add the names as host overrides that point to the local (and normally private) IP address in the internal network, e.g.
server1.mycompany.com => 192.168.42.43Then when a device is inside the internal network, it will resolve the name to 192.168.42.43 and go straight there.
When it is out on the public internet it will resolve the name to the public IP. -
If the LAN clients are using the DNS on pfSense (which then goes out to the real internet to resolve names by whatever means - resolver or forwarder style), then add the names as host overrides that point to the local (and normally private) IP address in the internal network, e.g.
server1.mycompany.com => 192.168.42.43Then when a device is inside the internal network, it will resolve the name to 192.168.42.43 and go straight there.
When it is out on the public internet it will resolve the name to the public IP.Isn't this exactly what NAT-reflection does, only without the need to manually add those entries in DNS override?
-
If the LAN clients are using the DNS on pfSense (which then goes out to the real internet to resolve names by whatever means - resolver or forwarder style), then add the names as host overrides that point to the local (and normally private) IP address in the internal network, e.g.
server1.mycompany.com => 192.168.42.43Then when a device is inside the internal network, it will resolve the name to 192.168.42.43 and go straight there.
When it is out on the public internet it will resolve the name to the public IP.Isn't this exactly what NAT-reflection does, only without the need to manually add those entries in DNS override?
NAT-reflection passes the traffic destined to the public IP, back to the internal IP, changing the source/destination in the packets… lie NAT does. That means the traffic keeps passing through pfSense, even though the client and server might be on the same internal LAN.
Using split-DNS (host override) the client actually learns the internal address of the server, and then talks directly to it. -
If the LAN clients are using the DNS on pfSense (which then goes out to the real internet to resolve names by whatever means - resolver or forwarder style), then add the names as host overrides that point to the local (and normally private) IP address in the internal network, e.g.
server1.mycompany.com => 192.168.42.43Then when a device is inside the internal network, it will resolve the name to 192.168.42.43 and go straight there.
When it is out on the public internet it will resolve the name to the public IP.Isn't this exactly what NAT-reflection does, only without the need to manually add those entries in DNS override?
NAT-reflection passes the traffic destined to the public IP, back to the internal IP, changing the source/destination in the packets… lie NAT does. That means the traffic keeps passing through pfSense, even though the client and server might be on the same internal LAN.
Using split-DNS (host override) the client actually learns the internal address of the server, and then talks directly to it.I see.
And this works even if the port on the WAN and the LAN differs? (in my case I have the NAT-rule answer to a certain port and then translates it to the port used by the mashine on the LAN)
-
And this works even if the port on the WAN and the LAN differs? (in my case I have the NAT-rule answer to a certain port and then translates it to the port used by the mashine on the LAN)
That is not going to work with just the split-DNS. The client would have to (somehow) work out itself which port number to use when on the external internet and internal intranet. If you can, I would just make the server application listen on the same port number that is being used for external connects to WAN.
-
Just in case anyone else had the same issue I had with NAT reflection not working after checking the 2 boxes and selecting pure NAT check your aliases. I was using a hostname for the alias for my NAT rules and my guess based on the pure NAT comments is that it didn't know the IP at the time it was creating the reflection rules? Less convenient to have to maintain the alias and the DHCP reservation but it worked. Something to look at if you're having problems I guess.
-
Just in case anyone else had the same issue I had with NAT reflection not working after checking the 2 boxes and selecting pure NAT check your aliases. I was using a hostname for the alias for my NAT rules and my guess based on the pure NAT comments is that it didn't know the IP at the time it was creating the reflection rules? Less convenient to have to maintain the alias and the DHCP reservation but it worked. Something to look at if you're having problems I guess.
This was my issue as well. Put an IP address in the alias instead of a host name, and problems disappeared.
Does anyone know if this is a bug or expected behavior?