pfSense captive portal setup for guest WiFi (Ireland)

Captive portals on pfSense are one of those features that almost works out of the box — until you try to launch with one and realise nine settings have to line up correctly or it does nothing.

Here's the field-tested setup we use for Irish hotels, restaurants and venues. Assumes pfSense Plus 23.09 or later on a Netgate appliance.

Step 1 — interface and VLAN

The captive portal binds to a network interface, not a subnet. Create a dedicated GUEST_WIFI VLAN (e.g. VLAN 30) on your LAN trunk. Assign it a /22 so you have room for 1,000+ concurrent devices without re-architecting on a Bank Holiday.

Firewall rules on this VLAN:

• Allow DNS to your chosen upstream (Cloudflare / Google — NOT your router)
• Allow HTTP/HTTPS to anywhere
• Block any traffic to RFC1918 destinations (10/8, 172.16/12, 192.168/16) — this is what stops guests from poking your back-office
• Block TCP/445 SMB outbound — stops WannaCry-style propagation from a guest device

Step 2 — captive portal zone

Services → Captive Portal → Zones → Add. Pick the GUEST_WIFI interface. Enable. Critical settings:

• Maximum concurrent connections per IP: 4. Stops one rogue device hogging session slots.
• Idle timeout: 60 minutes. Hard timeout: 24 hours. Don't leave them at zero (infinite).
• Disable concurrent logins: tick this. Stops one credential being shared infinitely across a coach party.
• MAC filtering: leave off. MAC addresses are randomised on modern phones; you'll annoy guests.

Step 3 — GDPR-compliant T&C page

The default 'login page' is a placeholder. Replace it with branded HTML containing:

• Your hotel/venue logo and name
• Plain-language WiFi T&Cs (max 250 words — guests don't read more)
• One required checkbox: 'I agree to the WiFi acceptable-use policy'
• One optional checkbox (must default UNTICKED): 'I'd like occasional emails from [Hotel Name]' — this is the GDPR-compliant marketing opt-in
• Link to your privacy policy

Upload via Services → Captive Portal → File Manager and reference from the HTML.

Step 4 — bandwidth shaping

Services → Captive Portal → [zone] → Bandwidth. Set defaults: 8 Mbps down, 4 Mbps up per session. Then use per-user bandwidth from RADIUS attributes if you want VIP guests to bypass this. Most hotels don't need RADIUS — flat per-user shaping is fine.

Step 5 — vouchers (optional but recommended)

For private events, conferences, or 'paid WiFi' tiers, enable Voucher authentication. Generate a roll of single-use codes, print them on table cards or reception slips. Each voucher = one device session with the bandwidth/duration you specify.

Four pitfalls we see most often

1. DNS is set to the router. Guests get the captive portal, hit Submit, and... nothing loads. Because your router can't resolve google.com fast enough during peak load. Point the captive portal's DHCP DNS at 1.1.1.1 and 8.8.8.8.
2. HTTPS sites don't trigger the portal. Modern phones expect HTTPS everywhere; many never trigger a captive-portal redirect. Enable 'HTTPS protocol' in the portal settings AND ensure the captive-portal cert is signed by a real CA, not pfSense's self-signed default.
3. The portal URL contains the LAN IP. Anyone screenshotting the URL sees 192.168.30.1 — embarrassing. Use the FQDN by setting a hostname under System → General Setup and a DNS A record on your domain pointing at the GUEST interface.
4. No HA failover. When the pfSense box reboots for an update, every guest disconnects. For 20+ room properties, run pfSense in HA pair (CARP) so the portal survives reboots.

When to call us

If any of the above gave you a queasy feeling: we're a Netgate partner. We do this for a living. Book a free pfSense site survey.