Skip to main content

Fortinet FortiAP and guest WiFi: captive portal setup with Purple

How Fortinet FortiAP access points managed in FortiCloud work with Purple guest WiFi using an external captive portal, RADIUS and a walled garden, without replacing your kit.

📖 2 min read📝 419 words📚 5 key definitions

Listen to this guide

View podcast transcript
Welcome to the Purple Architecture Briefing. Today we are diving into a critical integration for enterprise networks: deploying Purple WiFi alongside Fortinet infrastructure, specifically FortiAP access points and FortiGate firewalls. If you are an IT manager, a network architect, or a CTO managing a venue — whether that is a retail chain, a stadium, or a hospital — this session is designed to give you the actionable blueprint for making these two powerful platforms work together seamlessly. Let us set the context. Fortinet is renowned for its robust security posture. FortiGate Unified Threat Management appliances provide deep, Layer 7 traffic inspection. However, when it comes to guest WiFi, you do not just want security — you want business value. You want to capture demographic data, understand visitor behaviour, and drive marketing return on investment. That is where Purple comes in. By integrating Purple as an external captive portal, you offload the heavy lifting of guest identity management, GDPR consent, and social logins to Purple's cloud RADIUS, while letting the FortiGate do what it does best: secure the perimeter. So, how does this actually work under the hood? Let us get into the technical deep-dive. The architecture relies on standard RADIUS protocols and HTTP redirection. When a guest device associates with your open guest SSID broadcasted by the FortiAP, the FortiGate intercepts that initial web request. Instead of serving a basic, locally stored portal page, the FortiGate redirects the client to Purple's cloud-hosted splash page. Now, here is the critical concept: the Walled Garden. During this pre-authentication phase, the guest does not have internet access. But they need to load the portal graphics, and they might need to reach Facebook or Google to log in. The Walled Garden is a strict allowlist configured on the FortiGate that permits traffic to these specific domains. Once the user authenticates, Purple's platform sends a RADIUS Access-Accept message back to the FortiGate. The FortiGate then flips the switch, changing the session state to authenticated, and drops the user into your post-authentication firewall policy. Let us talk about the RADIUS configuration in more detail, because this is where precision matters. Purple provides you with two sets of RADIUS credentials: one for authentication on port 1812, and one for accounting on port 1813. Both must be configured. The accounting server is not optional. It is the mechanism by which the FortiGate reports session data back to Purple — duration, bandwidth consumed, and session termination events. Without accurate accounting data, your Purple analytics dashboard will show incomplete or inaccurate visitor metrics. Set your accounting interim interval to 120 seconds. This provides a good balance between real-time visibility and network overhead. A very common scenario involves FortiAuthenticator. Many enterprises use FortiAuthenticator for their staff WiFi — using 802.1X and PEAP to authenticate corporate devices against Active Directory. The question is always: can I keep my FortiAuthenticator for staff and use Purple for guests? The answer is absolutely yes, and the rule of thumb here is strict segregation. You maintain your staff SSID pointing to the FortiAuthenticator. You create a completely separate, open SSID for guests pointing to Purple's external captive portal and cloud RADIUS. The FortiGate routes the authentication requests based on the SSID. Staff identity stays on-premise with the FortiAuthenticator. Guest identity goes to the Purple marketing cloud. Zero crossover, maximum security. This architecture also has a significant compliance benefit. Under PCI DSS requirements, guest WiFi networks must be completely isolated from any network segment that handles cardholder data. By placing the guest SSID on a dedicated VLAN and enforcing strict firewall policies on the FortiGate to block all RFC 1918 private IP space destinations, you satisfy this requirement cleanly. Now let us move on to implementation recommendations. When you are setting this up, you have a crucial decision to make regarding IP assignment: NAT mode versus Bridge mode. If you are deploying a small retail branch with perhaps fifty to a hundred concurrent guest connections, NAT mode is perfectly adequate. The FortiGate hands out DHCP addresses to guests from a dedicated internal subnet and translates them as traffic exits the firewall. It is simple and requires minimal additional infrastructure. But if you are deploying a high-density environment — say, a five-hundred-room hotel, a conference centre with multiple concurrent events, or a stadium — you must use Bridge mode. In Bridge mode, the FortiAP drops the guest traffic directly onto a dedicated VLAN, allowing your core enterprise DHCP servers to handle the load. This prevents the FortiGate from becoming a DHCP bottleneck during peak connection events. Bridge mode also ensures the Purple platform sees the true client IP address, which is vital for accurate analytics and troubleshooting. Let us talk about the step-by-step configuration sequence, because order matters here. Start in the Purple portal. Retrieve your RADIUS server credentials — the server IP addresses, shared secrets, the captive portal URL, and the redirect URL. These are the four critical pieces of information you need before touching the Fortinet configuration. Then, move to the FortiCloud Dashboard or your FortiGate management interface. Define your RADIUS servers first — authentication on 1812, accounting on 1813. Then create your guest SSID, set authentication to Open, enable External Captive Portal, and input the Purple portal URL and redirect URL. Configure your Walled Garden. And finally, define your post-authentication firewall policy with your UTM profiles. What about pitfalls? Where do deployments usually go wrong? The number one issue, without question, is an incomplete Walled Garden. If a guest connects and gets a blank screen or a connection timeout, it almost always means the FortiGate is blocking access to Purple's CSS files, JavaScript assets, or the social login APIs before authentication. You must ensure every required domain is explicitly allowed in that pre-authentication policy. Purple provides a comprehensive list of required domains — use it in full. Also, do not forget DNS. Unauthenticated clients must be allowed to resolve DNS queries, or the redirect simply will not work. The device needs to resolve the Purple portal hostname before it can even attempt to load the page. The second most common pitfall is certificate errors. Ensure your FortiGate is presenting a valid, publicly trusted SSL certificate for the redirection interface. If you use the default self-signed certificate, modern iPhones and Android devices will throw significant security warnings, and your guests will abandon the connection entirely. This is a particularly acute problem in hospitality environments where guest experience is paramount. The third pitfall is RADIUS timeout errors. If the portal loads but authentication consistently fails, verify that the shared secrets match exactly between your FortiGate configuration and the Purple portal. Even a single character difference will cause all authentication attempts to fail silently. Also verify that no intermediate firewall is blocking UDP ports 1812 and 1813 between your Fortinet infrastructure and Purple's cloud RADIUS servers. Let us wrap up with a rapid-fire question and answer session based on the most common questions we hear from clients. Question one: does using Purple bypass my FortiGate security policies? Absolutely not. Purple handles the authentication and identity capture. Once authenticated, all guest traffic flows through your FortiGate's post-authentication policy. This is precisely where you apply FortiGuard Web Filtering, block peer-to-peer traffic, and shape bandwidth. Think of it this way: pre-authentication is permissive to allow login; post-authentication is punitive to protect the network. Question two: do I need to deploy local RADIUS servers? No. Purple provides RADIUS-as-a-Service. You configure the FortiGate to point directly to Purple's cloud RADIUS IP addresses. There is no need to deploy and maintain FreeRADIUS, Windows NPS, or any other local RADIUS infrastructure for the guest network. Question three: can Purple work with FortiWLM? Yes. The integration approach is consistent — configure the external captive portal URL, RADIUS server credentials, and walled garden within the FortiWLM controller, following the same logical sequence as the FortiGate configuration. Question four: what about GDPR compliance? Purple captures explicit consent at the portal level, presenting your terms and conditions and data processing notices before authentication. This consent data is stored within the Purple platform and is auditable. The FortiGate's role is purely network enforcement — it does not need to handle consent data directly. To summarize the key takeaways from today's briefing. First: segregate your staff and guest SSIDs absolutely. Staff on FortiAuthenticator with 802.1X. Guests on Purple with external captive portal. Second: meticulously configure your Walled Garden. It is the most common failure point and the most important pre-authentication configuration element. Third: use Bridge mode for any high-density deployment to avoid DHCP bottlenecks and to ensure accurate client IP visibility. Fourth: configure both RADIUS authentication and accounting servers. Accounting is not optional if you want meaningful analytics. Fifth: leverage Fortinet's UTM features post-authentication. Web filtering, application control, and bandwidth shaping should all be applied in the post-authentication firewall policy. By executing this integration correctly, you transform guest WiFi from a cost centre into a compliant, secure, and revenue-generating asset. The combination of Fortinet's security depth and Purple's marketing intelligence is genuinely powerful for any venue operator who wants to take their guest experience and data strategy seriously. Thanks for listening to the Purple Architecture Briefing. If you would like to discuss your specific deployment requirements, visit purple.ai to speak with the solutions team.

Fortinet FortiAP access points, managed from the FortiCloud dashboard, run the radio side of your network. Purple adds the guest layer on top: the captive portal your visitors see, the sign-in journey, and the first-party data you collect. It does not replace any of your Fortinet kit.

How Fortinet FortiAP works with Purple guest WiFi

Purple is a cloud overlay. Your FortiAP access points keep running the WiFi; Purple runs the guest experience through standard mechanisms FortiCloud already supports.

  • External captive portal. The guest SSID is set to use a captive portal pointed at your Purple splash page, so a new device is redirected there instead of being let straight on. The visitor signs in, and the page hands control back.
  • RADIUS. FortiCloud holds a RADIUS server entry for authentication on port 1812 and one for accounting on port 1813, checked against Purple's RADIUS service. The accounting data is what powers your visitor analytics.
  • Walled garden. FortiCloud calls the allow-list a walled garden, a short list of addresses a device can reach before it signs in, so the splash page and any payment or social-login steps can load.

That is the whole model: Fortinet moves the packets, Purple owns the sign-in and the data. Because it runs on standard external web authentication and RADIUS, it works the same way across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme and Fortinet. Purple is hardware-agnostic by design.

What you need

  • Fortinet FortiAP access points managed in FortiCloud, with admin access to the dashboard.
  • A Purple venue with your splash page and sign-in journey set up.
  • Your Purple RADIUS details and walled garden addresses, from your Purple dashboard.

Set it up with Purple

The exact settings, the network, the RADIUS server entries for authentication and accounting, the SSID captive portal configuration and the walled garden, are documented step by step in Purple's support guide, with the precise values to enter.

Fortinet FortiCloud AP setup guide

Follow that guide for the configuration. This page explains how the pieces fit together, so you know what each step is doing.

What you get

Once guests sign in through Purple, every visit becomes verified, conscious-choice opt-in first-party data: who visited, how often, and how to reach them with permission. That is the difference between WiFi that connects people and WiFi that builds a marketing audience you own. Purple is GDPR-aligned and ISO 27001 certified, with 99.999% uptime across more than 80,000 live venues.

Key Definitions

Cloud overlay

Purple sits on top of your existing hardware and runs the guest sign-in and data, without replacing the access points that move the traffic.

External captive portal

The SSID redirects a new device to an externally hosted sign-in page, your Purple splash page, before granting internet access.

RADIUS

The standard protocol used to check sign-ins and report usage, with separate FortiCloud entries for authentication on 1812 and accounting on 1813.

Walled garden

FortiCloud's name for the allow-list of addresses a device can reach before it has signed in.

FortiCloud

Fortinet's cloud dashboard for managing FortiAP access points and the guest network settings.