FortiAuthenticator Guest Captive Portal Cannot be reached from Client

[Jasys]

Had this working briefly, but somehow , something has changed in the environment, I have followed:

https://docs.fortinet.com/document/fortiauthenticator/6.5.0/cookbook/578250/fortiauthenticator-as-a-...

A few tweaks here and there, but essentially, the Client connects to the OPEN ssid, the interface uses system DNS to look up the address of the external portal., then should be able to access the captive portal, this part is completely broken, no traffic arrives at the FAC, meaning the client just cant resolve the FQDN (it used too!)  I checked the clients ipconfig, and it gets the right DHCP IP, gateway (Fortigate wifi interface) and correct DNS (it picks up public DNS, but there are DNS-DATABASE entries for the FAC) 

there is an EXEMPT captive portal rule, from the GUEST source network, to the FAC on HTTPS, so that it can use the form to register, before browsing. there are no hits on this rule. I have tried everything now, I just dont know what is missing, I tried using interface DNS, system DNS on the WIFI interface, the SSID is correct , open with external captive portal.. the FAC is working as the other WIFI is working as well as SSL VPN users.. any suggestions would be great.

[Markus_M]

Indeed, there is no captive portal reaction by this FortiGate. Just looking at one IP:
2025-07-16 09:30:04.358695 GUEST-WIFI in 192.168.204.56.51787 -> 81.134.106.99.80: syn 1876561636
2025-07-16 09:30:05.364672 GUEST-WIFI in 192.168.204.56.51787 -> 81.134.106.99.80: syn 1876561636
2025-07-16 09:30:07.362974 GUEST-WIFI in 192.168.204.56.51787 -> 81.134.106.99.80: syn 1876561636
2025-07-16 09:30:11.381285 GUEST-WIFI in 192.168.204.56.51787 -> 81.134.106.99.80: syn 1876561636
2025-07-16 09:30:19.382550 GUEST-WIFI in 192.168.204.56.51787 -> 81.134.106.99.80: syn 1876561636
There is no response to the client to any of those which is by the handshake SYN is repeated in 1,2,4,8 seconds.
On your policy 24, that would offer network access after authentication, what is the service there entailing. It is called "Web Access", exists on my lab FortiGate like this:
config firewall service group
   edit "Web Access"
       set member "DNS" "HTTP" "HTTPS"
   next
end
Make sure yours looks the same. Other than that, I would have a stupid assumption and wanting to restart either the FortiGate or kill the "authd" process which is responsible for captive portal (and FSSO). Or debug it and see what happens when the client tries to reach an HTTP page.
To debug:
diag debug app authd -1
To kill (and restart)
fnsysctl killall -11 authd

[Jasys]

Yes, its the same, I manually added the three services, in case the object was being a bit flakey! 

set name "Guest Internet Access"
set srcintf "GUEST-WIFI"
set dstintf "INTERNET"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "HTTP" "HTTPS" "DNS"

set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set av-profile "wifi-default"
set webfilter-profile "GUEST"
set logtraffic all
set nat enable
set port-preserve disable
set groups "GUEST-WIFI"

Will restart the authd now and have asked for a reboot and upgrade to 7.4.8 (currently on 7.4.7, but have checked the known issues)

[Markus_M]

You could try a flow debug and see what policy we would be hitting for that particular traffic and try the packet capture, but only for port 80. Could be a bit messy, but it makes sure to capture the possibility that the SYN is actually passing FortiGate fine, but blocked elsewhere, after the FortiGate.

Your sniffer command prompts don't look like it, but be also aware that another VDOM might be blocking the traffic as well, if your FortiGate is using VDOMs and the GUEST-WIFI isn't in internet facing VDOM.

flow trace:

diag debug console timestamp enable
diag debug flow filter port 80
diag debug flow show iprope enable
diag debug enable
diag debug flow trace start 20
20 is the count of packets, if you cannot time the test well, you may need increasing the count.

sniffer:

diag sniffer packet any 'port 80' 4 0 l

The upgrade would do the reboot of course.

[Jasys]

No VDOMs, will see what the upgrade does, more testing tomorrow and will run the debugs anyway. not looking hopeful though, its just not intercepting! 

[Jasys]

Hi Markus, Thanks again for taking the time, I have run the debug, going through it now, I have uploaded it too:

https://jasys.co.uk/uploads/DIAG_DEBUG.txt 

[Markus_M]

that indeed looks like the captive portal isn't working as FortiGate doesnt seem to see the need for it.In my lab I produced debug for it:
id=65308 trace_id=1860 func=print_pkt_detail line=5932 msg="vd-root:0 received a packet(proto=6, 192.168.195.11:50653->34.107.221.82:80) tun_id=0.0.0.0 from port10. fl
ag [S], seq 950070810, ack 0, win 64960"
id=65308 trace_id=1860 func=init_ip_session_common line=6124 msg="allocate a new session-00000dc1"
id=65308 trace_id=1860 func=__vf_ip_route_input_rcu line=1989 msg="find a route: flag=00000000 gw-192.168.200.1 via port1"
id=65308 trace_id=1860 func=__iprope_tree_check line=524 msg="gnum-100004, use int hash, slot=99, len=4"
id=65308 trace_id=1860 func=get_new_addr line=1274 msg="find SNAT: IP-192.168.200.100(from IPPOOL), port-61052"
id=65308 trace_id=1860 func=ip_session_confirm_final line=3131 msg="npu_state=0x100, hook=4"
id=65308 trace_id=1860 func=av_receive line=482 msg="send to application layer"

so there's no policy match done, but it's sent away for authentication.

In your case, no policy is found after checking all policies. Please show the relevant config bits again:
show wireless vap GUEST
show user setting

show firewall policy | grep -f GUEST-WIFI

show user group GUEST-SUBNET
show firewall address GUEST-WIFI-SUBNET

Best regards,

Markus

[Jasys]

edit "GUEST"
set ssid "GUEST"
set security open
set external-web "https:/xxxxxxxxxxxxxx/portal/" 
set captive-portal enable
set selected-usergroups "GUEST"
set security-exempt-list "GUEST-exempt-list"
set security-redirect-url "https://www.google.co.uk"
set intra-vap-privacy enable
set schedule "always"
unset broadcast-suppression
set quarantine disable
set beacon-advertising name
next
end

config user setting
set auth-type https
set auth-cert "GuestAuthWifi2025"
set auth-secure-http enable
end

config firewall policy
edit 22
set name "Guest Registration Portal"
set uuid d65c6dc8-fbff-51ee-208c-66533def9d25
set srcintf "GUEST" <---
set dstintf "INSIDE-NETWORK"
set action accept
set srcaddr "all"
set dstaddr "Fortiauthenticator"
set schedule "always"
set service "ALL"
set inspection-mode proxy
set logtraffic all
set nat enable
set port-preserve disable
set captive-portal-exempt enable
next
edit 24
set name "Guest Internet Access"
set srcintf "GUEST" <---
set dstintf "WWW"
set action accept
set srcaddr "all"
set dstaddr "all"
set schedule "always"
set service "Web Access"
set utm-status enable
set inspection-mode proxy
set ssl-ssh-profile "certificate-inspection"
set av-profile "wifi-default"
set webfilter-profile "GUEST" <---
set logtraffic all
set nat enable
set port-preserve disable
set groups "GUEST" <---
next

config user group
edit "GUEST
set member "Fortiauthenticator"
config match
edit 1
set server-name "Fortiauthenticator"
set group-name "GUEST-WIFI"
next
end

config firewall address
edit "GUEST-WIFI-SUBNET" <---
set associated-interface "GUEST" <---
set color 18
set subnet 192.168.204.0 255.255.255.0
next
end

I have used the name Fortiauthenticator, but its the actual real address that I am using, I can paste the real name here ;)

The set group-name is a radius attribute sent from the FAC as per the guide.

THANKS

[Markus_M · Accepted solution]

I literally didn't see this in the first posts, but your auth-type is wrong for this use case.

I reproduced your problem in my lab with auth-type = https only. Default includes http and telnet+ftp. You may include http at least here, which leads to triggering the captive portal with HTTP plaintext.

config user setting

    set auth-type http https
end
I can add http and my traffic gets redirected, I can remove http and my captive portal detection stops and times out on the detection page.

The setting itself means which protocols will be blocked and redirected by the FortiGate.

Good luck!

Best regards,

Markus

[Jasys]

That was it Markus, you absolute legend! I hadn't changed that setting , someone else may have in my absence! and the Fortinet guide says this:

To configure the firewall user settings from the CLI:

1. Enter the following commands to set to the firewall user settings:

   config user setting

   set auth-type https

   set auth-cert "STAR-Aug21" #auth-cert must be a valid certificate that has been imported to the FortiGate and matches the FQDN used for the interface IP of the SSID. A wildcard certificate may be used.

   set auth-secure-http enable

   end

so, is that an error in the documentation?

either way, with your patience and expertise , you have nailed the issue. I am extremely grateful, A true credit to this community. 

[Markus_M]

Documentation referring to:
https://docs.fortinet.com/document/fortiauthenticator/6.5.0/cookbook/798845/configuring-firewall-aut...
but that is a very good point. As to my understanding this will not work in the regular captive portal environment as HTTP unencrypted is used in order to do the redirect and not cause certificate warnings. The auth-type https is valid in a few scenarios, but I would assume this is for managed environments only in which the client PC is set to trust all those FortiGate-issued certificates. In those environments, the automatic message to the end user wouldn't work as these still rely on HTTP unencrypted. I'll have the docs double-checked.

Best regards,

Markus