Troubleshooting Tip: How to troubleshoot if captive portal not getting triggered in the firewall

If the user is not getting the captive portal, it means the traffic is not matching the user-based policy. Configure the below settings in the firewall to get the captive portal triggered.

Configure user-based policy as shown below and keep it on top:
With source IP as the concerned user IP, destination IP as ALL, and in place of source add the user information.

After configuring this policy, the captive portal should trigger. If it is not triggering and can still access the internet, the traffic matches below IP-based policy.

To match the top user-based policy, configure the following settings:

config user setting
    set auth-on-demand always
end

Debugging:

To verify if FortiGate sends the captive portal page and keepalive page (if keepalive is enabled) to a user. 

diagnose debug application authd 255

diagnose debug console timestamp enable

diagnose debug enable

A sample output of debugging:

In the sample below, the user's IP address is 10.177.2.21, the FortiGate IP address for the captive portal is 10.177.1.181, the username is user1, and the related firewall policy is ID 1.

[authd_http_read_http_message:496]: called
[authd_http_is_full_http_message:446]: called
[authd_http_on_method_get:5829]: src 10.177.2.21 flag 00010000
[authd_http_send_https_redir:4772]: src 10.177.2.21 flag 30010000
[authd_http_prepare_javascript_redir:3962]: https://10.177.1.181:1003/fgtauth?00070488c173d35f <- Captive portal is sent

...

authd_fnbam_auth_user: process#=0, policy_id=1
authd_fnbam_locked_out: username=user1, src_addr=10.177.2.21, n_failures=0, record_ttl=-593
[_authd_fnbam_auth_user:1379]: called
_authd_fnbam_auth: Start auth
authd_epoll_work: timeout 16220
[authd_fnbam_read:529]: called
pid=2042, auth_rsp_data=0x7ffd42be1990
pid=2042, user=user1
pid=2042, svr=user1, groups_len=0
user1(staff) authentication successful: timeout=36000 group_id=( 16777217 1 )

...

[authd_http_prepare_keepalive:4193]: src 10.177.2.21 flag 30018000
[authd_http_prepare_javascript_redir:3962]: https://10.177.1.181:1003/keepalive?0d0701030a000d10 <- Keepalive page is sent
[authd_http_send:1271]: src 10.177.2.21 flag 30018000

Note: 

It is recommended to make this change during the after-hours, as it might affect the internet connection, which might cause downtime.

When configuring this setting, traffic will match the user-based policy that has been created at the top, and the captive portal should get triggered.

Make sure to create IP IP-based DNS policy on top of the user-based policies, as shown below, to pass DNS traffic.

Open the CLI of the DNS policy and make sure to enable captive-portal-exempt as well: 

config firewall policy 

    edit <id> 

        set captive-portal-exempt enable 

end 

In the above policy example, the incoming interface (port2) is the LAN interface, and the outgoing interface (port1) is the WAN/public-facing interface.

Another possible reason is if the DNS Session Helper is enabled and traffic from the DNS session helper is shown as follows:

diagnose debug flow filter addr x.x.x.x---> x.x.x.x is the source ip
diagnose debug flow show iprope en
diagnose debug flow show function-name enable

diagnose debug console timestamp enable
diagnose debug flow trace start 10000

diagnose debug enable

   msg=ïprope_auth_portal_check() result:ret-matched, act-drop
   msg="run helper-dns-udp(dir=original)

After deleting the DNS session helper, the captive portal is triggered successfully. Enter the following command to delete the DNS session helper:

config system session helper

    delete 14
end
 

Related articles:

• Troubleshooting Tip: General captive portal explanation, flow and troubleshooting
• Technical Tip: The typical captive portal workflow for an end-user with a FortiGate/FortiWiFi