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.

[Jasys]

To recap, This behaviour is on all clients trying to connect, I rebooted the FAC over the weekend to see if something was hung or needed a kick, no joy.

In Summary, client connects, gets DHCP, gets interface DNS and is able to "ping" the FQDN of the FAC, so that tells me, DNS is fine.

Portal is not triggerred, if going to a http site, the browser just times out, with page cannot be reached, with a https site, it says "this connection is not private" which is expected, 

if they browse to the portal FQDN they get the expected 403 Fortinet forbidden.

am really stumped and lost all hope! 

[Markus_M]

Hey, don't lose hope, the community will help!

That beloved KB is important and defines basically what to look at.

If HTTP times out on the client, see what really times out.

The FortiAuthenticator reboot won't help if the client is timing out on the first steps. The KB article is totally linear and if one step fails, all the others after the failure won't take place and are not worth to look at.

Packet capture is the best, in doubt you can share it as well.

See what exactly times out as the browser bar will say. Expected destinations that CAN timeout would only be the HTTP captive portal detection pages, the FortiGate on port 1003 and the FortiAuthenticator and nothing else. The rest is irrelevant but only those three.

[Jasys]

Yes, don't get me wrong, the article is great for the flow, it tells me where its failing, but not what could be wrong or possible fixes. I have done multiple sniffer packets, it just shows syn packets going out on HTTPS to the FAC, when they try and go direct, the web traffic rule doesn't get hit at all, nor does the exempt rule (unless they try the FAC Portal FQDN directly)

[Markus_M]

Something isn't right on this. If the HTTP to outside would time out (and by this I understand steps 1+2), the HTTPS to FortiAuthenticator wouldn't be attempted (steps 8+9). Check again what exactly times out.

If the FortiAuthenticator web portal doesn't react, then the page shouldn't be loaded, as previously tested.

If the TCP handshake is failing and never arrives at FortiAuthenticator, check on FortiGate where the SYN is going in and out (the sniffer 4-6 would tell).
diag sniffer packet any 'host <fac-ip>' 4 0 a

If the SYN is arriving at FortiAuthenticator, but there is no response, do the same packet capture on FortiAuthenticator:

exec tcpdump -i any host <client-IP>
replace client IP if the FortiGate policy is doing NAT, then of course FortiAuthenticator won't see the client IP.

So for example

This message would mean my FortiAuthenticator isn't responding, which means I have to check how my client and the FortiAuthenticator are actually talking to each other. TCP handshake should be quite visible, but in that error case I'd assume that this isn't the case. That handshake somehow fails ("too long to respond"), because otherwise the error message will be different.

[Jasys]

Ill run some more packet sniffers when the engineer is back there later, it is worth pointing out that the FAC has a business WIFI using EAP-TLS, and thats working fine, as does the SSL VPN on the same firewall, using LDAP on the FAC, so it is just the portal part that broken, ill see what dumps I can get.

[Markus_M]

SSLVPN is either using LDAP or more likely RADIUS, EAP is using RADIUS. Portal uses HTTPS and would only show that the network generally is fine from these FortiGates. However, as LDAP/RADIUS are FortiGate originating, this won't say anything about what the client can communicate or not with the FortiAuthenticator through the FortiGate, which requires itself an own fw policy.

[Jasys]

Agreed, was just pointing out, I dont think the FAC is at fault, considering the other services are working on there, EAP-TLS for Business WIFI and the SSL VPN is using the LDAP connection. will get some sniffer traffic asap

[Jasys]

Will have captures tomorrow, but from the logging on the Firewall, all previous attempts dont touch the web access rule, and the only hits on the portal exempt rule are when I asked them to try going direct to the FAC and getting the 403 error.

[Markus_M]

403 sounds alright in that test. Then lets see what the rest brings up. Important is to capture port 53 (DNS), 80 (captive portal detection pages, HTTP unencrypted or manually browsing it and triggering it), 443 (towards FAC) and port 1000 or port 1003 (both to FortiGate, 1003 if "auth-secure" in config user setting is enabled). Theoretically a packet capture on the FortiGate will have all of it with when using the client IP as a filter. It may be good to have at the same time in parallel a packet capture with those ports on the client itself. Use the Wireshark filter if needed: port53 or port 80 or port 443 or port 1000 or port 1003. Double-check to run Wireshark on the correct interface as admin (since we don't trust any end user ;) ).

[Jasys]

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

I have uploaded the logs to my personal website here:  

I dont think there is much to decipher, have a scroll through, the traffic towards 10.31.1.212 is when he tried the portal URL direct