pfSense Captive Portal for Guest Wi-Fi: What It Actually Controls and Where It Leaks

You need guest Wi-Fi that signs users in, blocks LAN access, and shows terms of use, without buying a cloud controller. pfSense’s built-in captive portal can do that on a single box, but it is an HTTP redirect gate, not a full network access control system. Use it when the goal is simple sign-in and isolation for a low-to-mid traffic guest zone, and plan around its protocol limits.

What the portal actually does on pfSense

A captive portal intercepts HTTP and HTTPS traffic from an unauthenticated client on a chosen interface and redirects it to a local web page. The page can present terms acceptance, a username/password form, or a block notice. After successful authentication the portal creates a temporary allow rule for that client’s IP/MAC.

The portal is per-interface. That means you can enable it on OPT1 for guest Wi-Fi while leaving LAN untouched. pfSense supports custom HTML, logos, and optional back-ends such as local users, LDAP, or RADIUS. Authentication state is tracked in the captive portal tables, and idle/timeout settings control how long access remains.

Guest zone design with per-interface portal

A common engineering decision is to pair the portal with a dedicated guest interface and firewall rules that enforce isolation.

• Interface: OPT1 assigned to the AP’s guest SSID VLAN.
• Captive Portal: enabled on OPT1 only, zone name e.g., Guest.
• Firewall: allow Guest -> Internet, deny Guest -> LAN and Guest -> RFC1918 private ranges.
• Optional: DNS forwarder or pfBlockerNG for content filtering, with the understanding that multiple services increase CPU load and troubleshooting complexity.

The portal handles the user-facing sign-in. The firewall rules handle the actual isolation. Do not rely on the portal alone for containment.

Worked example: local auth portal on OPT1

This is a representative configuration pattern for a small office guest network. Adjust placeholders to your environment.

Services > Captive Portal > Add

• Interface: OPT1
• Zone ID: Guest
• Enable: checked
• Authentication method: Local User Manager
• Idle timeout: 30 minutes
• Hard timeout: 8 hours
• Allowed IP addresses: leave empty for dynamic assignment

System > User Manager > Users: create a local user for testing, e.g., user guest_test with a strong password. The portal will validate against this store.

Firewall > Rules > OPT1: create a pass rule for source OPT1 net to any, placed above the captive portal implicit deny. Then create a block rule for source OPT1 net to LAN net and to private RFC1918 ranges. Order matters.

System > General Setup > Captive Portal: upload a custom logo and edit the portal HTML if you need terms acceptance text. If you use HTTPS on the portal, use a certificate trusted by clients to avoid browser warnings. A self-signed certificate will trigger SSL warnings on many devices.

Risks to note: enabling the portal changes traffic flow for the interface. Misordered firewall rules can lock out the portal page itself. Changing authentication back-ends requires the back-end to be reachable from pfSense.

Trade-offs and limits you will hit

Performance: for typical home/SMB loads the extra inspection and redirect logic has minimal impact. In high-throughput environments you may see measurable latency increase. Measure CPU and memory before and after enabling the portal on your specific hardware to quantify impact.

Protocol coverage: the portal only intercepts HTTP and HTTPS. Non-HTTP protocols such as FTP, SSH, or custom apps bypass the redirect unless additional firewall rules block them. Treat the portal as a web gate, not a blanket access control.

User experience: browser caching can cause clients to skip the portal after first visit. iOS and Android captive portal detection varies. Self-signed portal certificates cause SSL warnings. Provide clear instructions for clearing cache or using a private window when users report stuck pages.

Operational complexity: combining the portal with pfBlockerNG, traffic shaping, or RADIUS adds CPU load and makes troubleshooting harder. Keep the guest zone minimal until you have baseline metrics.

How to verify it works on your hardware

Enable the captive portal on a test interface and connect a client device. Verify the redirect to the login page occurs for HTTP requests.

Log in with a test user and confirm access to Internet is granted while access to LAN resources is denied. Test from the client with attempts to reach a private LAN IP and a public site.

Measure CPU and memory usage before and after enabling the portal under expected client load. Observe portal logs under Status > System Logs > Captive Portal for authentication events and drops.

Document the timeout behavior and certificate choice. If you need stronger assurance than HTTP redirect, plan for additional controls such as VLAN isolation and explicit deny rules.

The portal is a pragmatic choice for guest sign-in and basic isolation on pfSense when you accept its HTTP-centric nature and verify behavior on your hardware and version.