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]

Hi, Yes, client sees SSID, connects to it, gets the correct IP, gateway and interface DNS. no portal triggered,  if you browse to a web page to trigger it, it just says "connection is not private in the browser" if you try a http connection, it just times out, WIFI says connected. they can ping the FAC interface via FQDN.. 

[Markus_M]

in reply to your previos comment about DNS. It always has to work and client must be able to resolve stuff. Either through an exemption policy or if the FortiGate is the DNS server.

Regarding this comment here I hijack:

connection isn't private will be expected as FortiGate must block the attempt and it tries to do so by mitm'ing the connection and presenting its own certificate.

The HTTP connection however has to work. If you say "times out" - does it time out when trying to reach that page or by connecting to FortiGate or to FortiAuthenticator? The address bar will be important to see then as it signifies what the browser claims to time out on.

[funkylicious]

in FAC documentation described in the tutorial, at step 3 :Configuring a captive portal policy on FortiAuthenticator , do you have the exact same SSID configured that the users connect to and it's defined on the FGT ?

[Jasys]

its a sub string in the policy substring_match ="GUEST"  but I dont think its getting that far, the Fortigate needs to interrupt the traffic, but it clearly isn't  :(

[Jasys]

I removed the GUEST GROUP from the Web Policy and I can see apple devices using DNS.. they are not authenticated, so don't know how they are using it?

[Markus_M]

config firewall auth-portal
set portal-addr "guest.auth.mypublicdomain.com"
end
is required to be the FortiGate, although not intuitive. It affects only redirect #1, that is the articles step 3). And yes, I place a lot of value on that article :)

When you test (and the group is removed from the policy), get a packet capture from the client that contains DNS AND port 443+1003.

diag sniffer packet any 'host <client IP>' 6 0 a

will usually do.

[Jasys]

Yes, thats on the Fortigate, always has been. Did some further testing , have removed the Group from the policy.  client connects, gets an IP, and can ping the FQDN of the FAC, so this proves the interface DNS is working. Still no portal, installed Firefox when to the portal address http://detectportal.firefox.com  and it times out. if the client browses to the portal address, they get the 403 Forbidden error. I am now completely confused as to what is wrong :(  I did a diag sniffer packet,on the client address, it shows the ping to the FAC and the failed HTTPS to the portal address, nothing else

[Markus_M]

The problem will then be why the HTTP page times out. FortiGate has to block it and answer it. The rest should work. Why would your packet capture however not show http://detectportal ... that is port 80 and unless you filtered it out, should be visible, all the same.

The "timeout" message on browser means that the client tried reaching it but didn't receive a response from anywhere. If not in your capture, where does the client send its requests?

It would fit the logic if the client tries to reach the page via another interface. If it doesn't try to reach the page via FortiGate, FortiGate cannot redirect anything. In my beloved article, step2 would be going wrong. So check from the PCAP what the page detectportal.firefox.com resolves to, with the DNS response. From that client, ping that resolved address. Do you see the ping on the FortiGate?

[Jasys]

There is a web filter on with cert inspection, but thats for after the authenticate, so shouldn't be affected, and its always been there, you are right, the portal is just not being triggered and it makes zero sense, literally 2 weeks ago this was all working and something has killed it! and I cant find it. there is only the one connection from the client to the fortigate, no other ones, I cant test again now untill Monday :(

[Markus_M]

The web filter will indeed only take place at a policy hit. You can take out all UTM, just in case.

Basically DNS should resolve some address that the client will try to reach via HTTP.  That part seems to not even work, so FortiGate cannot redirect (traffic that it doesn't see). You want to test that ping as mentioned and routing table for oddities, like a default route that specifies only the internal network for example.

Likewise, another client is also worth testing. If traffic doesn't reach FortiGate for some odd reason, it is quite unlikely two clients would show the same behavior. If that were true though, you would like to check the DHCP settings on FortiGate as DHCP can push static routes (in "Additional DHCP Options").