FortiGate captive portal setup with an external portal server

On FortiGate, an external captive portal needs four things. Set the SSID or interface security mode to captive portal with an external portal URL. Point authentication and accounting at a RADIUS server. Exempt the portal and social login domains from authentication, and install a trusted certificate so the HTTPS post-back raises no browser warning.

What does a FortiGate external captive portal actually do?

A captive portal is the web page a visitor must complete before the network lets their traffic out. In an external setup, FortiGate enforces the portal and a separate server hosts the page. With Purple, that server is our Guest WiFi platform.

The login runs in five stages:

1. The guest joins an open SSID (the network name) broadcast by a FortiAP, or a network behind a FortiGate interface. They receive an IP address.
2. The device makes its first web request. FortiGate intercepts it and redirects the browser to the external portal URL. It appends parameters that identify the session, the client MAC address and the FortiGate's own login address.
3. The guest completes the Purple splash page: a form, a social login or a terms acceptance.
4. The portal posts credentials back to the FortiGate's authentication listener. By default this listens on TCP 1000 for HTTP and TCP 1003 for HTTPS.
5. FortiGate sends a RADIUS Access-Request to Purple. On Access-Accept, it marks the device as authenticated and applies the guest firewall policy. Accounting messages then report the session start, interim usage and stop.

RADIUS (Remote Authentication Dial-In User Service) is the protocol FortiGate uses to ask "can this device on?" It is defined in RFC 2865, with accounting in RFC 2866.

The division of work is the point. FortiGate keeps enforcement: firewall policy, NAT and session state. Purple handles identity, consent and guest data. You can change the splash page across every site in Purple without touching FortiOS.

Built-in portal or external portal?

FortiOS ships its own captive portal. It works, and for a single site with a disclaimer page it may be enough. The table shows where the two approaches part ways.

	FortiGate built-in portal	External portal with Purple
Where the page lives	Replacement message HTML on each FortiGate	Hosted by Purple, one design for every site
Login options	Authentication, disclaimer and email collection portal types	Forms, social login and terms acceptance
How access is granted	Local or remote firewall user groups	RADIUS to Purple on UDP 1812
Consent handling	Email capture only; opt-in records are yours to build	Conscious-choice opt-ins recorded per guest
Changing the page across 40 sites	Edit each FortiGate or push through FortiManager	One change in Purple
Reporting	FortiGate logs and FortiAnalyzer	WiFi Analytics dashboards by venue
Mixed-vendor estates	Fortinet hardware only	Same portal on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet
Best fit	One site, disclaimer-only access	Multi-site estates that want first-party data

What do you need before you start the FortiGate captive portal setup?

Gather these before you open the FortiGate GUI. Most failed deployments trace back to a missing item on this list.

• A FortiGate on a supported FortiOS build. Either the FortiGate manages your FortiAPs as a wireless controller, or one of its interfaces serves the guest network. Interface mode covers third-party access points and wired guest ports.
• A guest network segment. Put guests on their own VLAN (virtual LAN, a separate Layer 2 broadcast domain) or a dedicated SSID interface. Never share a subnet with staff or payment devices; PCI DSS expects cardholder systems to be segmented from untrusted networks.
• Your Purple account values. You need the external portal URL, the RADIUS server addresses and the shared secret. These come from Purple's FortiGate support article and your Purple dashboard. They are specific to your account, so never copy them from a forum post.
• Outbound reachability. The FortiGate must reach Purple's RADIUS servers on UDP 1812 for authentication and UDP 1813 for accounting.
• A publicly trusted certificate. It must cover a hostname that resolves to the FortiGate's guest interface address. The certificate section below explains why.
• An exempt list inventory. Decide which login methods you will offer, because each one adds domains to your walled garden.
• Coverage you trust. A portal cannot fix a weak signal. If guests complain about drop-outs, run a survey first; our guide to WiFi site surveys covers the method.

What changes between FortiOS versions?

Fortinet moves and renames captive portal settings between major FortiOS releases. On some builds, options such as the exempt list or the authentication certificate are easier to set, or only available, in the CLI. Bridge-mode and tunnel-mode SSIDs can also behave differently, depending on firmware.

Three habits protect you:

• Read the Administration Guide for your exact FortiOS release in the Fortinet Document Library, not the latest one.
• Check the release notes for captive portal and RADIUS changes before every upgrade.
• Re-run your full test matrix after every firmware upgrade, before guests find the problem for you.

How do you set up a captive portal on FortiGate with an external portal server?

The sequence below works for FortiAP SSIDs and FortiGate interfaces alike. Purple's FortiGate support article holds the exact values and screenshots for each step. Use it alongside this summary.

Step 1: add Purple as a RADIUS server

Create a RADIUS server object on the FortiGate. Enter the Purple server addresses and the shared secret from your account. Enable accounting so FortiGate sends session start, interim and stop records to Purple.

If the FortiGate has more than one WAN link, set the RADIUS source address explicitly. RADIUS requests should always leave from the address Purple expects; otherwise a failover silently breaks logins. Use the built-in connectivity test on the RADIUS object before moving on.

Step 2: create a firewall user group

Create a user group of the firewall type and add the Purple RADIUS server as a remote server. The captive portal will authenticate guests against this group. Keep one group per authentication source so troubleshooting stays clear.

Step 3: set the security mode to captive portal

For FortiAP, edit the guest SSID. For wired or third-party access points, edit the guest interface. Then:

• Set the security mode to captive portal.
• Choose the authentication portal type and select the external portal option.
• Paste the external portal URL from Purple.
• Select the user group from Step 2.
• Choose the redirect after login: the guest's original URL or a page you specify.

On FortiAP, assign the SSID to the FortiAP profile used by your access points. Fortinet's documentation uses tunnel mode as the reference for captive portal SSIDs. If you bridge locally, confirm your firmware supports captive portal in that mode.

Step 4: build the exempt list

Create firewall address objects for every destination guests must reach before authentication. Attach them to the SSID or interface as the security exempt list. The next section lists what belongs there and what must stay out.

Step 5: write the guest firewall policy

Create a policy from the guest SSID or interface to the WAN, with NAT enabled. Apply the web filter and application control profiles your acceptable use policy requires. Make sure guests can resolve DNS before they authenticate, or the redirect never fires.

Step 6: install the certificate and use HTTPS for the post-back

Import your publicly trusted certificate and set FortiGate to use it for authentication. Point the portal's post-back at the HTTPS listener, using the hostname on that certificate. This removes the warning guests would otherwise see at the moment they submit the form.

Step 7: align timeouts

FortiGate's authentication timeout decides how long an authenticated device stays on the list. Purple's session settings decide what a returning guest sees. If your firmware honours the RADIUS Session-Timeout attribute (RFC 2865), let Purple set session length from one place.

What should the FortiGate exempt list include?

The exempt list is FortiGate's walled garden: destinations a device can reach before it authenticates. Too short, and the portal breaks. Too long, and guests browse without ever signing in.

Category	Example entries	Why	Exempt?
Purple portal and assets	Hostnames listed in Purple's FortiGate support article	Loads the splash page, images and scripts	Yes
Social login providers	Sign-in domains for Facebook, Google, Apple and Microsoft, as wildcard FQDN objects	The OAuth sign-in must complete before authentication	Yes, only for providers you enable
Your own information pages	A hospital's patient information site, a stadium's match-day page	Visitors reach essential information without signing in	Optional
OS captive network detection	captive.apple.com, connectivitycheck.gstatic.com, www.msftconnecttest.com	The probe must fail so the device opens the login sheet	No, never
General browsing	News, search and streaming sites	Defeats the portal	No

Two rules prevent most walled garden failures.

Use FQDN objects, not IP addresses. Social login providers serve sign-in pages from content delivery networks whose addresses change constantly. A static IP list goes stale within weeks.

Make the FortiGate and the guest agree on DNS. FortiGate resolves FQDN address objects itself. Wildcard FQDN objects are populated from DNS responses that pass through the FortiGate. If DHCP hands guests a public resolver, the guest and the FortiGate can receive different CDN addresses, and the exempt entry misses. Hand out the FortiGate, or the resolver it uses, as the guest DNS server.

For Healthcare sites, exempting a patient information page lets visitors find ward times without signing in. Keep such entries to a short, named list and review it quarterly.

Why does the FortiGate captive portal show a certificate error?

Two different moments produce certificate warnings. They have different causes and different fixes.

Warning 1: the guest opens an HTTPS site before signing in

Most browsing is HTTPS. To redirect it, FortiGate must answer the TLS handshake itself, presenting its own certificate for a site it does not own. The browser sees a name mismatch and warns. No certificate can fix this, because no certificate is valid for every website.

Sites on the HSTS preload list (HTTP Strict Transport Security, which tells browsers to refuse insecure connections) cannot be clicked through at all. Banking and email sites usually fall into this group.

The fix is to rely on operating system captive network detection. iOS, Android, Windows and macOS each probe a plain HTTP URL on joining a network. FortiGate redirects that probe and the device opens the login sheet before the guest opens a browser. This is why detection domains must never sit in the exempt list.

Warning 2: the guest submits the portal form

After the guest completes the Purple page, the browser posts to the FortiGate's authentication listener. If that listener uses the factory certificate, the browser warns because the certificate is self-signed.

If the portal posts to the HTTP listener instead, Chrome warns that the form is not secure. The page is HTTPS, but the form submits over HTTP.

The fix is Step 6: a publicly trusted certificate on a hostname that resolves to the FortiGate's guest interface, with the post-back on HTTPS. Renew it before expiry. An expired authentication certificate breaks every login at once, across every SSID on that FortiGate.

How do you check the FortiGate guest portal works?

Test on real devices, not just a laptop. Build a matrix of iOS, Android, Windows and macOS, and run each check on every platform.

1. Join the SSID. The login sheet should open automatically within seconds. If it does not, check the exempt list for detection domains.
2. Complete each login method. Test the form, every social provider you enabled and the terms acceptance.
3. Watch for warnings. No certificate warning should appear at any point in the flow.
4. Confirm authentication on the FortiGate. The authenticated firewall users monitor should list the device against the guest group.
5. Confirm RADIUS from the CLI. diagnose test authserver radius tests the server object directly. diagnose debug application fnbamd -1, with debug enabled, shows each Access-Request and response in real time.
6. Confirm accounting in Purple. The session should appear with a start record, then interim updates, then a stop when the guest leaves.
7. Test the return visit. Reconnect after the timeout and check the guest sees the page you intended.

What goes wrong with a FortiGate captive portal, and how do you fix it?

Symptom	Likely cause	Fix
Login sheet never appears; device says "connected"	Detection domains in the exempt list, or a policy allowing traffic before authentication	Remove captive.apple.com and similar entries; check the guest policy requires authentication
Splash page loads blank or unstyled	Purple asset hostnames missing from the exempt list	Add every hostname in Purple's FortiGate support article
Certificate warning when browsing before login	FortiGate intercepting an HTTPS site	Expected behaviour; guests should use the login sheet or open an HTTP page
Certificate warning on submitting the form	Factory certificate on the authentication listener	Install a trusted certificate and post back over HTTPS
Social login spins or fails	Provider domains not exempt, or DNS mismatch between guest and FortiGate	Use wildcard FQDN objects; set the FortiGate as guest DNS
Portal accepts details, no internet follows	RADIUS reject or timeout: wrong shared secret, wrong source address, UDP 1812 blocked	Run the authserver test; read fnbamd debug output
Guests asked to sign in too often	Short authentication or idle timeout	Align FortiGate timeouts with Purple session settings
Sessions missing from reports	Accounting disabled or UDP 1813 blocked	Enable accounting on the RADIUS object; open UDP 1813
Logins break after a firmware upgrade	Settings moved or defaults changed in the new release	Re-check against release notes and re-run the test matrix

How does this play out at real venues?

Scenario 1: a 200-room hotel replacing a previous guest WiFi provider

Situation. A 200-room hotel ran a FortiGate with 30 FortiAPs and a tunnel-mode guest SSID. Guests on iPhones saw no login sheet and opened Safari instead. Those who did reach the page met a certificate warning on submitting it.

What was done. The engineer found captive.apple.com in the exempt list, left by the previous provider, and removed it. They installed a publicly trusted certificate on a hostname resolving to the guest interface and moved the post-back to HTTPS. They added Purple's RADIUS servers with accounting enabled.

Outcome. In the post-change test matrix, the login sheet opened automatically on all four platforms. Zero certificate warnings appeared in the login flow. Session records with start, interim and stop entries reached Purple for every test session. For more on hotel deployments, see Hotels.

Scenario 2: a 40-store retail chain managed by an MSP

Situation. An MSP ran one FortiGate per store for a 40-store Retail chain. Shoppers reported intermittent failures with Google and Apple sign-in, but only in some stores.

What was done. DHCP in the affected stores handed shoppers a public DNS resolver. The FortiGate resolved the providers' CDN hostnames to different addresses, so the exempt entries missed. The MSP switched the providers to wildcard FQDN objects and made the FortiGate the guest DNS server. They piloted the change in three stores before rolling it out through FortiManager.

Outcome. All three social login methods completed in every pilot test, on every platform. The MSP then applied the same template to the remaining 37 stores. If you resell guest WiFi to clients like this, our guide to white label captive portal software covers the commercial checks.

Scenario 3: a council library with wired guest kiosks

Situation. A council library network offered guest WiFi on third-party access points and four wired public kiosks. Both connected through one FortiGate. The council wanted one terms page and one audit trail.

What was done. The engineer enabled captive portal on the FortiGate guest interface rather than an SSID. The same external Purple portal and RADIUS group served wireless visitors and kiosk sessions.

Outcome. Both wireless and wired sessions appeared in one accounting log in Purple, against one terms acceptance record. That gave the council a single answer when asked who used the network and when.

What does it cost, and what do you get back?

What it costs

The hardware cost is usually nil. Captive portal and the RADIUS client are part of FortiOS, so you configure the FortiGate and FortiAPs you already own. Purple is hardware-agnostic: the same portal runs on Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Our blog on why your next WiFi upgrade doesn't need new hardware makes the wider case.

The software cost is the Purple plan: Connect, Capture or Engage. Each prices differently depending on how you count sites, access points or guests. Our guide to captive portal pricing models compares per site, per access point and per user models.

The effort cost is engineering time per site. Template it once, test it on a pilot and push the template through FortiManager for an estate.

What you get back

• First-party data with consent. Purple records conscious-choice opt-ins per guest. Data handling is GDPR compliant, and Purple holds ISO 27001, Cyber Essentials and B Corp certification.
• One portal across the estate. Change the splash page once instead of on every FortiGate, including sites on other hardware.
• Reporting you can act on. Accounting data feeds WiFi Analytics: visits, dwell time and return rates by venue.
• A platform at scale. Purple runs at 80,000+ live venues and handled 440 million logins in 2024 (Purple's own data). For hospitality operators, our guide to WiFi in restaurants covers coverage and security in the UK.

Frequently asked questions

Does Purple work with my existing FortiGate and FortiAP hardware?

Yes, Purple runs on your existing FortiGate and FortiAP estate with no new hardware. FortiGate enforces the captive portal and sends RADIUS authentication and accounting to Purple, while Purple hosts the splash page. The same approach covers third-party access points behind a FortiGate interface. Purple also supports Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium and Extreme, so a mixed estate shares one portal.

Do I need an extra Fortinet licence for an external captive portal?

No, captive portal and the RADIUS client are standard FortiOS features, so the FortiGate needs no separate portal licence. You need a supported FortiOS build and, for wireless, FortiAPs managed by the FortiGate. The Purple plan, whether Connect, Capture or Engage, is licensed separately. Our guide to captive portal pricing models explains how per site, per access point and per user pricing compare.

Can I move from my current guest WiFi provider without downtime?

Yes, if you build the Purple configuration in parallel before switching. Add Purple's RADIUS servers and a new user group alongside the existing ones, then create a test SSID or interface using them. Run the full device test matrix on that test network. When it passes, repoint the live guest SSID and remove the old provider's exempt list entries, especially any captive network detection domains.

Is guest data captured through a FortiGate portal GDPR compliant?

Yes, when the portal runs on Purple, consent and data handling follow GDPR. Purple records conscious-choice opt-ins per guest, so marketing consent is separate from network access. Purple is ISO 27001 and Cyber Essentials certified. FortiGate passes session details such as the client MAC address to the portal, but guest records live in Purple. You remain the data controller and set your own retention and privacy notice.

Should I use the FortiGate built-in portal or an external portal?

Use the built-in portal for a single site that only needs a disclaimer page. Use an external portal when you run several sites, want social login or first-party data, or manage mixed hardware. The built-in page lives on each FortiGate and must be edited site by site. An external Purple portal changes in one place and records opt-ins and session analytics for every venue.

How much engineering effort does a FortiGate deployment take?

A single site is a configuration change, not a hardware project. You create one RADIUS server object, one user group, one SSID or interface change, one exempt list, one policy and one certificate. Most of the effort goes into testing on iOS, Android, Windows and macOS. For estates, build the configuration once as a FortiManager template, pilot it on a few sites, then push it everywhere.

Can an MSP run Purple across many client FortiGates?

Yes, MSPs run Purple across many client FortiGates from one account structure. Each client site uses the same configuration pattern, so you can template it in FortiManager and deploy in batches. Purple's hardware-agnostic design means clients on Cisco Meraki, HPE Aruba or Ruckus use the same portal. Check the commercial terms in our guide to white label captive portal software before signing.

Does the external portal work on wired guest networks?

Yes, FortiGate can enforce captive portal on an interface as well as on a FortiAP SSID. Enable captive portal on the interface serving the wired guest VLAN, select the external portal and point it at the same Purple RADIUS group. Kiosks, meeting room ports and third-party access points then share one splash page, one terms acceptance record and one accounting log with your wireless guests.