Tech Support: Not Reaching Domain via HTTPS Server Behind PfSense Firewall

Some domains fail to resolve via HTTPS when hosted behind a PfSense firewall due to misconfigured virtual host rules, missing port forwarding, or incorrect SSL certificate binding. This issue typically arises because the reverse proxy cannot correctly route incoming requests to the specific Spring Boot backend associated with each domain name.

Verify Port Forwarding and NAT Rules

The first step in troubleshooting is ensuring that traffic from the internet can actually reach your internal server. PfSense acts as a gateway, so if the correct ports are not forwarded, external requests will be dropped before they hit your application. You must verify that both HTTP (port 80) and HTTPS (port 443) are forwarded to the internal IP address of your Linux server hosting the Spring Boot application. Navigate to Firewall > NAT > Port Forward in the PfSense web interface. Ensure there is a rule for each protocol you intend to support. The destination should be your server's local IP, and the foreign address should be set to "any" unless you have a specific static public IP requirement. If you are using a dynamic DNS service, ensure that the WAN interface is correctly identified and that no conflicting aliases are blocking the traffic. Additionally, check the Firewall > Rules > WAN section. There must be an allow rule corresponding to the port forward rules created above. Without this explicit allow rule, the default deny policy will block the connection even if the NAT translation is correct. It is common to overlook this step when setting up new services, leading to intermittent connectivity issues where some domains work while others do not, depending on existing firewall configurations.

Configure Virtual Hosts and Reverse Proxy

Once network connectivity is established, the next layer of failure usually occurs at the application level. If you are running multiple domains on a single server, your web server (such as Nginx, Apache, or Traefik) must distinguish between them based on the Host header. If all domains point to the same IP but only one resolves correctly, it indicates that the reverse proxy is either defaulting to a single backend or failing to match the hostname. In your reverse proxy configuration, ensure that separate server blocks or location contexts exist for each domain. For example, in Nginx, you would define distinct server_name directives for each domain, routing them to different upstream ports or containers running your Spring Boot instances. Misconfiguration here often results in a "404 Not Found" or a generic error page for all domains except the primary one configured by default. If you are using a load balancer or a more complex setup, verify that the X-Forwarded-Proto and X-Forwarded-For headers are being passed correctly. Spring Boot relies on these headers to understand that the original request was HTTPS, especially when sitting behind a TLS-terminating proxy. Without these headers, your application might redirect HTTP traffic back to itself, creating a loop or causing mixed content errors that browsers reject.

Check SSL Certificate Binding

HTTPS requires valid certificates for each domain. If you are using a wildcard certificate, ensure that the domain names fall within the wildcard scope. If you are using individual certificates, such as those obtained from Let's Encrypt, verify that the certificate files are correctly linked to the virtual host configuration. A common pitfall is configuring the proxy to listen on port 443 but failing to specify the correct certificate path for a specific domain. When accessing a domain over HTTPS, the browser performs a handshake. If the server presents a certificate for example.com when the user requests api.example.net, the browser will display a security warning. In many cases, automated scripts or API clients may treat this as a failure, making the domain appear unreachable. Use tools like openssl s_client or online SSL checkers to verify that the correct certificate is being served for each domain. Furthermore, ensure that the certificate renewal process does not break the configuration. If you use Certbot or similar tools, verify that the hooks updating your web server configuration are executed successfully after renewal. A broken symlink or a permission issue on the private key file can cause the web server to fail to start or reload, taking down all associated domains simultaneously.

Debugging Network and Application Logs

If the above steps do not resolve the issue, you need to look deeper into the logs. On the PfSense side, enable packet capture (Diagnostics > Packet Capture) to see if packets are arriving at the WAN interface and being translated correctly. Look for SYN packets from your public IP addressing the forwarded port. If you see them but no return traffic, the issue lies within your Linux server's firewall or application configuration. On the Linux server, check the logs of your web server and the Spring Boot application. Web server logs will show whether the request reached the proxy and which virtual host matched. Spring Boot logs will reveal if the request was processed and what response was generated. Pay attention to any exceptions related to SSL context initialization or database connectivity, which might occur only under specific domain routing scenarios. You can also use curl -v https://domain.com from a machine outside your network to simulate a real user request. The verbose output will show the exact point of failure, whether it is a DNS resolution issue, a TCP handshake timeout, or an SSL handshake error. This diagnostic step provides concrete evidence to narrow down the scope of the problem.

Frequently Asked Questions

Why do some domains work while others fail?

This usually happens when the reverse proxy has a default server block that handles unmatched requests, while other domains lack proper configuration. Check your web server config to ensure every domain has a dedicated server block with correct server_name and upstream definitions.

How do I test if PfSense is forwarding traffic correctly?

Use the built-in packet capture tool in PfSense under Diagnostics. Filter for the public IP and port 443, then attempt to access the domain from an external network. If you see incoming SYN packets but no SYN-ACK responses, the issue is likely on the Linux server side.

Can a wildcard certificate solve multi-domain issues?

Yes, a wildcard certificate covers all subdomains of a base domain (e.g., *.example.com). However, it will not work for completely different root domains. Ensure your certificate matches the exact hostname requested by the client to avoid SSL handshake failures.

What headers must Spring Boot receive from the proxy?

Spring Boot needs X-Forwarded-Proto set to "https" and X-Forwarded-For to identify the real client IP. Configure your reverse proxy to inject these headers automatically, otherwise, redirects may loop or security checks may fail.

Is it safe to disable SSL verification for testing?

Disabling SSL verification is useful for debugging during development but poses significant security risks in production. Always use valid certificates and proper chain validation in live environments to prevent man-in-the-middle attacks and ensure browser compatibility.