Description
This article describes how FortiAuthenticator matches incoming Captive Portal requests to portal policies.
Scope
FortiAuthenticator.
Solution
FortiAuthenticator can provide Captive Portal services for Wi-Fi or wired authentication. To this end, Captive Portal policies can be configured similarly to RADIUS policies. For more details on configuring the portal policies, see here, select the correct firmware, and navigate to Authentication -> Portals -> Policies.
If there is more than one Captive Portal policy, then FortiAuthenticator has to apply some sort of logic to determine which captive portal policy should be matched.
FortiAuthenticator selects an appropriate policy based on the Portal Selection criteria (HTTP parameters), in a top-down order.
RADIUS client and/or Access Point do not impact what portal policy is applied!
As an example, when FortiGate redirects to a captive portal, the full redirect URL looks something like this:
https://fgt[.]forti[.]debbie/captive?login&post=https://10[.]0[.]1[.]3:1003/fgtauth&magic=[...]&usermac=aa:bb:cc:dd:ee:ff&apmac=00:11:22:33:44:55&apip=192.168.1.99&userip=192.168.200.99&ssid=Guest-SSID&apname=ap_test&bssid=66:77:88:99:aa:bb
That HTTP request contains some parameters like usermac, apmac, apip, userip, ssid, and apname.
These parameters can be configured as matching criteria in the portal policy.
To determine what parameters are sent to FortiAuthenticator, running developer tools in a browser and then triggering the redirect should provide the desired information.
Only redirect URLs that contain the specified HTTP parameters will match the specified rule.
If this rule is at the top:
Any incoming captive portal requests WITH the specified parameter (ssid=Guest-SSID) will match into the first portal policy, and all other requests will match into the second portal policy.
If a policy with NO HTTP parameters is at the top, then ANY incoming captive portal request will match that one:
Note: Newly created captive portal policies are added to the bottom of the policy list.
Due to this, captive portal policies WITH HTTP parameters should be put at the top of the policy list. Essentially, the policy list should go from more specific to less specific.
As policy matching is done ONLY based on HTTP parameters, captive portal requests can hit a policy with no matching RADIUS or Access Point configured.
This will cause the captive portal authentication to fail and is visible in the RADIUS Authentication debug log (with debug mode enabled):
2024-09-12T14:48:30.139333+01:00 FortiAuthenticator radiusd[3020]: Waking up in 0.6 seconds.
2024-09-12T14:48:30.140235+01:00 FortiAuthenticator radiusd[3020]: (8) Received Access-Request Id 73 from 127.0.0.1:38495 to 127.0.0.1:1812 length 82
2024-09-12T14:48:30.140247+01:00 FortiAuthenticator radiusd[3020]: (8) User-Name = "debbie"
2024-09-12T14:48:30.140250+01:00 FortiAuthenticator radiusd[3020]: (8) NAS-IP-Address = 127.0.0.1
2024-09-12T14:48:30.140254+01:00 FortiAuthenticator radiusd[3020]: (8) NAS-Port = 20
2024-09-12T14:48:30.140257+01:00 FortiAuthenticator radiusd[3020]: (8) NAS-Identifier = "FAC_GUEST:5:10.0.0.2"
2024-09-12T14:48:30.140259+01:00 FortiAuthenticator radiusd[3020]: (8) User-Password: ******
2024-09-12T14:48:30.140262+01:00 FortiAuthenticator radiusd[3020]: (8) # Executing section authorize from file /usr/etc/raddb/sites-enabled/default
2024-09-12T14:48:30.140746+01:00 FortiAuthenticator radiusd[3020]: (8) facauth: ===>NAS IP:127.0.0.1
2024-09-12T14:48:30.140756+01:00 FortiAuthenticator radiusd[3020]: (8) facauth: ===>Username:debbie
2024-09-12T14:48:30.140759+01:00 FortiAuthenticator radiusd[3020]: (8) facauth: ===>Timestamp:1615556910.139096, age:1ms
2024-09-12T14:48:30.141537+01:00 FortiAuthenticator radiusd[3020]: (8) facauth: ERROR: The AP of portal policy 5 does not contain client 10.0.0.2
2024-09-12T14:48:30.141547+01:00 FortiAuthenticator radiusd[3020]: (8) Invalid user (facauth: The AP of portal policy 5 does not contain client 10.0.0.2 [debbie] (from client localhost port 20)
The portal policy number listed in the RADIUS debug log refers to the database entry and is visible if hovering the mouse over the portal policy itself in GUI.
