FortiAuthenticator Guest Captive Portal Cannot be reached from Client

I can answer the part about "SSL deep inspection using an already trusted CA certificate" and the answer no. To do SSL deep inspection you need the private key that a CA uses to prove it is not being impersonated and that being publicly available makes it no longer trustworthy.

hi,

i would enable dns server listening on the ssid, where you have an entry for the captive portal hostname.

in the dhcp settings set to use the interface ip and then it should work.

make sure that you also have the fw rule from ssid intf to fac.

https://docs.fortinet.com/document/fortigate/6.2.9/cookbook/960561/fortigate-dns-server 

Hey,

I recommend going through this article. It is basically a step-by-step of what must happen for the captive portal to work fine.
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-General-captive-portal-explanation-flow-and/ta-p/355925
If a step isn't happening, that tells you where to look.
In your case - a client must, regardless of captive portal, be able to access the FortiAuthenticator FQDN, without certificate warnings. That'd be in the article step 8.

The FortiGate must have an exemption for the client to reach the FortiAuthenticator IP. Exempt either with policy or with the SSID itself (it has the option for exempt destinations).

Do a packet capture towards the client IP or on the client and see what DNS and HTTP traffic does and follow the articles steps.

In very short:
There must be some DNS query for one of those captive portal detection pages, then tcp handshake, HTTP GET. FortiGate must block/answer it with its own URL resolving to its own interface. Cycle repeats but FortiGate answers with the FortiAuthenticator URL ... and cycle repeats (DNS for FAC FQDN, TCP handshake, HTTP(S)). If there is another portal behind FortiAuthenticator, i.e. social login or even SAML IdP - then add another of those cycles (DNS, TCP, HTTP).

In any case, the client must be able to reach ALL captive portal instances without the need to authenticate first to reach the instance to authenticate to! That'd be a catch 22, so the authentication targets must be exempted.

Best regards,

Markus

You want to then check exactly what happens when a client wants to browse the FortiAuthenticator. Check against FQDN and IP, just in case. What is the browsers complaint about it?

I would also refrain from adding the group on both the interface and the policy. Go for the interface and remove the group from the policy. It can only match anyway if the interface allows the group after authentication.

So the exempt policy works fine then.

Browsing an internet page will likely fail because captive portal is in place. From that article step 1 needs to happen which is plainly that the client must(!) try reaching some HTTP page unencrypted which will trigger the redirect to FortiGate. You can always test that with browsing one manually, packet capture and see how it behaves. http://detectportal.firefox.com is one of those pages. Browse it manually to start at step 1 and check whether the rest would work. If it does, you need to see why the client seems to not do this automatically, ending up asking the user to "you must login to use this network".

Have you also removed the group from the policy (this will cause issues)?

Hey,

 it is enough to keep the group on the SSID OR the policy. Both can trigger a captive portal on their own. Keeping however both may conflict with each other. Your config otherwise looks fine. There are common mistakes to have config firewall auth-portal contain the FortiAuthenticator FQDN, which however I don't read from your config bits, the rest seems also OK.

Best regards,

Markus

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.

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").

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.