Cannot reach domain via HTTPS on the same server behind a PfSense Firewall

Question

I am hosting a platform on a server which has multiple domain names, let's say example.com and anotherexample.com. I am running a Spring Boot backend on that server, which uses the domain example.com and tries to communicate with anotherexample.com. My problem is that I can't seem to connect with the other domain over HTTPS, it simply does not even connect. I have tried the following tests which return different results:

1. Using curl on a machine not behind the firewall to https://anotherexample.com, works perfect
2. Using curl on the server, but instead using http://anotherexample.com, works perfect
3. Using curl on the server to https://anotherexample.com, no response, eventually times out
4. Using curl on the firewall to https://anotherexample.com, no response, eventually times out
5. Using openssl s_client -connect anotherexample.com:443 -servername anotherexample.com on the server, no response, eventually times out
6. Changing /etc/hosts on the server to 127.0.0.1 anotherexample.com, when running openssl s_client -connect anotherexample.com:443 -servername anotherexample.com, I get a response.

What could be the issue causing me to not be able to connect to any domain hosted on machines behind the firewall, is it something wrongly configured on the server (Ubuntu 22.04) or on the PfSense firewall (2.7.2).

My structure is the following:

• PfSense Firewall which uses NAT to make sure the public IP gets to the internal IP of the server
• Server running NGINX with port 80 and 443 open. Certificates are done via LetsEncrypt and work perfectly in the browser

Answer 1

That's normal; DNAT ("port forwarding") doesn't work when both the source and the actual destination are on the same subnet (or indeed are the same system). Many earlier threads have been posted regarding the same issue with home gateways (search for "NAT hairpin") but it applies equally to any NAT implementation including pfSense, so search the earlier posts for a full explanation; the basic problem is that the firewall only has the opportunity to rewrite packets in one direction but not in the other.

A common workaround is to have pfSense also rewrite the source IP address, making it seem to the web server as if the connection actually comes from the firewall instead of itself. To do that, enable NAT Reflection in your firewall. In other places it would be called "NAT loopback", "NAT hairpin", or just a custom SNAT rule without a specific name.

Note that this will have slight performance implications because each packet necessarily goes through Ethernet to pfSense and back, instead of being able to stay entirely within the machine. Your webapps will also need to expect the firewall IP if you're using IP-based access.

So I would personally recommend the 127.0.0.1 /etc/hosts entries for all domains instead of relying on NAT reflection.