NAT Reflection Port - Help
-
Why can't you just plug in the internal IP address then? What am I missing here?
-
This software requires the public IP. Otherwise, the user can't connect correctly from the outside.
When I use the external ip (98.169.x.x) to connect to the server (10.0.0.1) through the client (10.0.0.50), the server log always show I am connecting from 10.0.0.1 (Gateway/Router). And, when the server want to sent data back to the client, the data is being sent to 10.0.0.1 (Gateway/Router). I need to be able to login with (98.169.x.x:9981) in the LAN.
All I need to do is be able to forward 9981 correctly with NAT Reflection. Is it possible when Split DNS doesn't work?
-
But in the case in question, you are inside the LAN, so can't you use the internal IP in that situation? As I said, given how NAT reflection works, I don't think this can work without the source being the pfsense.
-
Maybe I'm missing something, but port 9981 is not a large port range, it's a single port. The actual port number shouldn't matter at all. I don't understand why NAT Reflection as built-in to pfSense wouldn't work in this case. I've done it before (for under 10-15 reflected ports in my case for things like an Exchange server), the limit is either ranges containing over 500 ports, or reflecting more than 500 ports total, I'm not sure. But either way, I don't see why publicIP:9981 to privateIP:9981 reflecting automatically won't work if you turn on NAT Reflection. It should Just Work once it's on. Happy to be corrected if I'm wrong though.
-
David, you might got something there. Maybe something that you have changed in the setting?
This is a huge problem for me. Before I use the NAT Reflection, when I type in the external ip in the browser, the browser will bring me to the router login page, which is 10.0.0.1. This problem has been resolved with NAT Reflection.
However, when I use the external ip (98.169.x.x) to connect to the server (10.0.0.1) through the client (10.0.0.50) Port 9981, the server log always show I am connecting from 10.0.0.1 (Gateway/Router). And, when the server want to sent data back to the client, the data is being sent to 10.0.0.1 (Gateway/Router).
-
I think you misunderstood David. He doesn't have a problem, he is saying nat reflection should work. On the other hand, I think he missed that it isn't that reflection doesn't work, but that you want the real IP, not the firewall's. However, as I've said already, I don't think you can get that to work, and you never answered my question about why you aren't using the internal IP when you are inside.
-
Dan, you are right, and good catch. I missed that it's the IP that's important. But port forwarding from outside the firewall in wouldn't show the firewall's WAN address either as the source. I agree I don't see a way for requests to appear to come from the original LAN or WAN IP with reflection. Split DNS would give you the LAN IP of the client as the source if it was usable, and wouldn't touch the firewall. I don't see a way to do what bczeon wants without custom code, but I'd consider it a bug in the software not the firewall :-)
-
Yeah, unfortunately, the individual processes doing the netcat is how pfsense does reflection. I don't see anyone changing that anytime soon (then again, I haven't looked at any open tickets that might contradict that statement LOL).
-
I've actually worked on an alternate implementation with just pf rules. It is currently being used when you enable reflection on 1:1 mappings on 2.0 beta (where it probably isn't reasonable to use inetd + netcat for every single port), but might be used for port forwards (or possibly both available for port forwards?) when I finish some things on it.
That implementation does send the correct source IP when the server is on a different interface than the client (and later versions will when just on a different subnet). However, I've tried setting the source IP to the WAN IP, but it just doesn't work. I thought it might work, but the network stack (or pf?) must be blocking the reply since it is to a different IP address. I have not yet tried playing around with the built-in firewall rules to see if there is some way to get it working.
-
isn't the issue that the web server is looking at the host address in the html header not the IP transmission info?
In reality, the request could appear to be destined for any IP address but the destination address typed in the browser must be http://98.169.xxx.xxx
In the same way you use host header info to host multiple websites on one server.If the web server were configured to look for a host name rather than an IP address you could use Split DNS. If the webserver cannot be configured to do this you must either use NAT reflection or possibly some sort of HTML proxy to rewrite the HTML header?