Host override & NAT
-
@Alek Using an internal IP does not break SSL/TLS as long as a valid cert matches the name. Unless you’re using a reverse proxy and no cert on the server?
What does Diagnostics/DNS Lookup return? Does the host using curl have only pfSense for DNS?
-
@SteveITS
I'm using Cloudflare tunnel as proxy. From WAN, I can access my webapp without problem.
On a different vlan with pfsense as DNS only (Other DNS requests are blocked), I can ping the DNS name but can't access it via browser. -
@Alek
Tried without Cloudflare tunnel, 443 straight exposed and nated, same problem. -
@Alek If you're connecting to a CloudFlare IP that's not reflection; reflection would be using your WAN IP from inside pfSense.
I honestly don't know, is CloudFlare usable if you're connecting from the target IP? Or do they block that assuming it will be a local connection?
Is reflection enabled in the NAT rule? See:
@Alek said in Host override & NAT:
On a different vlan with pfsense as DNS only (Other DNS requests are blocked), I can ping the DNS name
Windows in particular does not process DNS in order, it prefers the last-known-good one first. When you say ping works, it uses the pfSense WAN IP?
-
@Alek said in Host override & NAT:
I'm using Cloudflare tunnel as proxy. From WAN, I can access my webapp without problem.
So is your SSL certificate provided by Cloudflare?
Does DNS resolve your domain to the same IP, when requesting from the internet and inside your network?
-
@SteveITS
I'm using direct connection on port 443 no proxy in front, no Cloudflare tunnel.Using A record to my public IP + Let's Encrypt.NAT reflection is activated :
Tried via Debian, the DNS used is Pfsense :
When I ping my DNS name, it's working :
ping vhost.ex.com -c 4 PING vhost.ex.com (Public_IP) 56(84) bytes of data. 64 bytes from vhost.ex.com (Public_IP): icmp_seq=1 ttl=64 time=0.399 ms 64 bytes from vhost.ex.com (Public_IP): icmp_seq=2 ttl=64 time=0.604 ms 64 bytes from vhost.ex.com (Public_IP): icmp_seq=3 ttl=64 time=0.519 ms 64 bytes from vhost.ex.com (Public_IP): icmp_seq=4 ttl=64 time=0.499 ms --- vhost.ex.com ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3005ms rtt min/avg/max/mdev = 0.399/0.505/0.604/0.072 ms
From Debian, if I dig the webapp internal DNS name, I get :
From Debian, I can't ping the internal IP of my webapp :
Now if I curl the public DNS name I get :
curl -vv -fsSl https://vhost.ex.com * Trying Public_IP:443... * Failed to connect to vhost.ex.com port 443: Connection timed out * Closing connection 0 curl: (28) Failed to connect to vhost.ex.com port 443: Connection timed out
And in my pfsense log I have these denied connections :
-
@Alek
So is the access allowed on the interface, where the PC is connected to? -
Sorry didn't understand your question
-
@Alek
Show the VLAN50 rule set, please. -
@viragomann
The Debian VM is on Vlan DMZ :
The 3rd rule is disabled, I created it to test.
If enabled I can curl the webapp but using internal IP...The webapp is on Vlan 66 aka Untrusted :
-
@Alek said in Host override & NAT:
If enabled I can curl the webapp but using internal IP...
And what's the drawback of that?
As already mentioned, if the web application provides the proper SSL certificate for the requested host name, the browser should be happy and load the page, no matter if the resolved IP is public or private. -
@viragomann
I'm trying to do a complete VLAN isolation, no internal traffic allowed.And, FIDO type keys don't work when I pass by internal IP while they do if I pass by WAN.
-
@Alek said in Host override & NAT:
I'm trying to do a complete VLAN isolation, no internal traffic allowed.
That makes no sense. If allow client device access to a server it's pretty the same thing if it uses the internal or the public IP.
And, FIDO type keys don't work when I pass by internal IP while they do if I pass by WAN.
Maybe it's bound to a certain IP, what ever...
So first step is to care that the host name resolves to the public IP. You said you did this already, but the recent screenshot shows, that is is resolving to the private one in fact.