Using PfSense Captive Portal for Simple Guest Wi‑Fi Access

Problem: Guest users need temporary internet without exposing the LAN

In a small office, visitors often require Wi‑Fi access for a few hours. Setting up separate VLANs, a RADIUS server, and complex firewall rules can be overkill, yet leaving the LAN open poses a security risk. PfSense includes a built‑in captive portal that can present a login or acceptance page before granting any network traffic, keeping the solution lightweight and GUI‑driven.

Thesis: PfSense captive portal offers a quick, manageable way to secure guest Wi‑Fi

By enabling the captive portal service on the LAN (or a dedicated guest interface), configuring a simple local user database, and customizing the portal page, you can require authentication or an acceptable‑use policy without additional hardware. The trade‑off is modest CPU overhead and the lack of per‑user bandwidth controls, but for most small offices the convenience outweighs these limits.

Enabling the captive portal service

1. Log in to the PfSense web GUI as an administrator (https://pfsense.lan).
2. Navigate to Services → Captive Portal.
3. Click the + button to create a new portal instance.
4. Give it a name (e.g., guestportal) and enable the Enabled checkbox.
5. Under Interface, select the interface that serves the guest Wi‑Fi (commonly LAN or a dedicated OPTx).
6. Save the instance.

After saving, the service status should change to running on the Status → Services page. If it does not, verify that the interface is up and that no other service is blocking port 80/443 on that interface.

Configuring authentication options

For a small office, the local user manager is sufficient:

1. With the portal instance selected, go to the Authentication tab.
2. Choose Local User Manager as the authentication method.
3. Click Save.
4. Navigate to System → User Manager and add a user (e.g., username guest, password guest123). Assign the user to the Captive Portal group or leave the default.
5. Save the user.

If you already have a RADIUS server, you can select RADIUS instead and fill in the server IP, shared secret, and port.

Customizing the portal page and setting timeouts

1. Open the Page Content tab of the portal instance.
2. Replace the default HTML with a brief welcome message, your logo, and an Acceptable Use Policy checkbox. Example snippet:

   <h2>Welcome to Acme Corp Guest Wi‑Fi</h2>
   <p>Please accept the terms to continue.</p>
   <form method="post" action="$PORTAL_ACTION$">
   <input type="checkbox" name="accept" required> I accept the Acceptable Use Policy<br>
   <input type="submit" value="Continue">
   </form>
   

3. Switch to the Session Timeout tab.
4. Set Idle Timeout to 900 seconds (15 minutes) and Hard Timeout3600 seconds (1 hour) as appropriate.
5. Save.

Applying the portal to the interface and firewall rules

The captive portal only affects traffic that passes through PfSense. Ensure the interface you selected has an appropriate firewall rule:

1. Go to Firewall → Rules, select the interface (e.g., LAN).
2. Verify there is a rule allowing traffic from the interface subnet to any destination (the default LAN rule usually suffices).
3. No additional rule is needed; the portal intercepts HTTP/HTTPS requests before they reach the firewall.

Worked example: From enable to verification

1. Enable captive portal on LAN as described above.
2. Create local user guest / guest123.
3. Set portal to use Local User Manager, add a welcome message, idle timeout 900 s.
4. Save and apply changes.
5. Connect a smartphone to the guest Wi‑Fi (LAN). Open a browser and try to load any site.
6. Observe the redirect to the custom login page.
7. Enter guest / guest123 and submit.
8. After authentication, the browser should load the requested page.
9. Check Diagnostics → Captive Portal – you should see an active session for the guest user.
10. Review System → Logs → General for any authentication errors; none should appear.

Trade‑off and practical closing

The captive portal adds a small CPU load because each HTTP/HTTPS request is inspected and redirected until authentication succeeds. On modest hardware (e.g., an Intel Atom or similar) this load is usually negligible for fewer than 20 concurrent guests. It does not provide per‑user bandwidth shaping or dynamic VLAN assignment; those features require a full RADIUS deployment or additional packages like pfSense-pkg-bandwidthd.

For most small offices, the simplicity of a GUI‑driven portal outweighs these limits. Enable the portal, monitor CPU usage via Status → System Graphs, and adjust idle/hard timeouts if you notice guests being logged out too frequently or staying connected longer than needed.