Diagnosing pfSense Captive Portal Authentication Failures

When a user cannot connect through a pfSense Captive Portal, the failure usually manifests as an infinite redirect loop, a "Connection Not Private" browser warning, or a silent timeout after submitting credentials. These issues typically stem from a mismatch between the firewall state, the SSL certificate, or the authentication backend rather than a failure of the portal daemon itself.

To resolve these failures, you must isolate whether the issue is at the network layer (traffic reaching the portal), the security layer (SSL/TLS trust), or the identity layer (credential validation).

Diagnostic Matrix

Symptom	Likely Cause	Diagnostic Focus
Portal page never loads; browser times out	DNS failure or firewall rule block	Network Layer
Browser shows "Your connection is not private"	Self-signed or mismatched SSL certificate	Security Layer
Login spins or fails with valid credentials	RADIUS/LDAP timeout or unreachable server	Identity Layer
Users are randomly disconnected/kicked	RAM exhaustion or short session timeouts	System Resources

Step 1: Verify Network Path and DNS

The Captive Portal intercepts traffic on a specific interface. If a client cannot resolve DNS, the browser cannot initiate the HTTP request required to trigger the redirect to the portal daemon.

• DNS Verification: Ensure clients are assigned a valid DNS server via DHCP (typically the pfSense interface IP). If the client cannot resolve a public domain, the redirect trigger will fail.
• Firewall Rule Order: The interface hosting the portal must allow DNS (UDP/53) and HTTP (TCP/80) traffic. A "Deny All" rule placed above the portal's implicit requirements will block the initial handshake.

Check: From a test client terminal, run nslookup google.com. If this fails, verify your DHCP DNS settings and firewall rules for the client subnet.

Step 2: Resolve SSL/TLS Certificate Errors

Modern browsers enforce strict HTTPS. If the portal uses a self-signed certificate or one where the Common Name (CN) does not match the accessed FQDN, browsers may block the redirect entirely to protect the user from a perceived man-in-the-middle attack.

Navigate to Services > Captive Portal > [Your Zone] and inspect the HTTPS Certificate selection.

• The Fix: Replace self-signed certificates with a valid certificate from a trusted Certificate Authority (CA), such as Let's Encrypt via the ACME package. Ensure the certificate's Subject Alternative Name (SAN) matches the portal's DNS name.
• Verification: Access the portal from a mobile device. If the browser displays a secure padlock without warnings, the certificate chain is correctly trusted.

Step 3: Diagnose Authentication Backends

When using external RADIUS or LDAP servers, authentication failures often occur because pfSense cannot reach the identity provider, often due to VLAN segmentation or firewall blocks on the WAN/LAN interfaces.

Log Analysis: Navigate to Status > System Logs > Captive Portal. Look for entries indicating "timeout" or "server unreachable" coinciding with the client's IP address.

Connectivity Test: Run the following command from the pfSense shell (Diagnostics > Command Prompt) to verify the RADIUS port is open:

nc -zv [RADIUS_SERVER_IP] 1812

Replace [RADIUS_SERVER_IP] with your actual server IP. This requires root permissions.

• Expected Result: A "succeeded" message. If it hangs or returns "Connection refused," check the firewall rules on both pfSense and the RADIUS server for UDP 1812/1813.

Step 4: Resource and Session Limits

Session state for the Captive Portal is stored in system RAM by default. In high-density environments, memory pressure can cause the portal daemon to restart or drop existing sessions.

• Check: Navigate to Status > System Logs and search for "captive portal" restarts or OOM (Out of Memory) killers.
• Fix: Increase system RAM or implement a RADIUS backend to offload session management. Review the Hard Timeout and Idle Timeout settings in the portal configuration to prune stale sessions more aggressively.

Verification and Escalation

To verify a fix, clear the browser cache on the test client and attempt a fresh connection. A successful login resulting in a session cookie and subsequent internet access confirms the resolution.

Escalate to network engineering if:

• The nc command fails despite open firewall rules (indicates routing or ISP blocking).
• Logs show "Invalid shared secret" despite matching configurations on the RADIUS server.
• The portal daemon crashes immediately upon enabling HTTPS with a valid certificate.