No connection from inside subnet
We are currently switching ISP and firewall and I am trying to make one of our webservers available now through the new pfSense firewall and the net ISP/modem.
What I got is quite simple. ISP gives IP via DHCP with transparent modem.
IP: 172.16.1.2, GW: 172.16.0.1, Mask: 255.255.255.0
IP: 192.168.1.100, Mask: 255.255.0.0
Now I got a simple NAT 1:1 and Firewall Rule to pass HTTP and HTTPS to my webserver:
NAT: 18.104.22.168/32 -> 192.168.1.114/32
Note that my external IP is completely different to my modem/firewall address. So far no problems.
From outside (my home or anywhere) I can access the webserver via the DNS record I set on my providers DNS Service or the IP address (22.214.171.124). But from inside my company I can't access the webserver. I tried "tcpdump port 443" on my webserver and it showed nothing. The stange thing is my firewall logs say the packets get passed:
PASS Apr 15 13:08:53 LAN 192.168.1.123:48834 126.96.36.199:443 TCP:S
PASS Apr 15 13:08:53 WAN 172.16.1.2:32390 192.168.1.114:443 TCP:S
Any ideas or suggestions??
GruensFroeschli last edited by
This forum has a search function:
(but for like the 1000th time here the solution directly from the FAQ ;) )
Oh sorry, it seems I forgot to say: NAT reflection is enabled, or at least it is not disabled. Split DNS is not an option for me since I can't change my DNS server that easily and experimental routing… well I would consider this a last emergency option.
I think the problem is that, as the FAQ says, NAT reflection is not possible with 1:1 NAT, so I would have to use a port forward but as I understand it a port forward does not resemble a NAT setup, or am wrong on this?
thanks, and sorry for being a noob
GruensFroeschli last edited by
Port forwards are as much NAT as 1:1 NAT.
With normal forwards you can setup the exact same behaviour as with 1:1.
Personally i never use 1:1 since i can use my available IPs much more efficient with normal forwards.
If you insist on 1:1 you can create normal forwards on top of 1:1 to invoke the reflection.
Wow, thanks, it seems I completely misunderstood all this NAT stuff. I already requested budget for the pfSense book so, hopefully I will never have to ask here again.
Just one little thing: Are Aliases not allowed als Ports in NAT Port Forward? I tried my WebPorts alias but it did not work from inside my network again, but by specifying both ports (80 and 443) explicitly everything works as expected.
EDIT: To be specific, when using the Alias I do get an "ssl_error_rx_record_too_long" in firefox instantly. My webserver does not even seem to get any packages when I try to capture anything by tcpdump.
EDIT2: I tried everything now and I do get thsi SSL error just if I use an alias as the port range. My WebPorts alias is as described in at least a thousand tutorials 22,80,443. My NAT rule is like:
External address: <my virtual="" ip="">Protocol:TCP
External port range: WebPorts
NAT IP: <my local="" ip="">Local port: WebPorts
For the virtual IP I tried Proxy ARP and other, both with the same result: ssl_error_rx_record_too_long from inside my network, perfectely working from outside. Using two rules, one for HTTP and one for HTTPs also works from inside and outside. This is very very strange.</my></my>
Grrrr, ok, problem solved. And of course for documentation reasons here my solution: I does make a difference in which order the ports in your Alias appear. I do have a RewriteRule in Apache that rewrites everything from http to https and although this was not directely the problem it did mess in some way with pfSense. Now I set 443 as my first port in my alias and at least https works. Via http a correct rewrite still isn't done but at least it works in some way now.
Via http I get:
Bad Request Your browser sent a request that this server could not understand. Reason: You're speaking plain HTTP to an SSL-enabled server port. Instead use the HTTPS scheme to access this URL, please. Hint: https://myurl.com
So either my apache rewrite is incorrect (which I am pretty much sure it is not) or pfSense does not really handle Aliases in Port forwards correctely. It seems to me that the forward does not try to map external and internal to be the same but does map them in the order they appear in the aliases which would be a quite stange behavior.