Fortigate wifi external portal authentication with FortiAuthenticator

Fabio · ‎03-23-2022

My Fortigate environment for wifi guest user is a external authentication portal by FortiAuthentication; i replace the Fortinet certicate SSL with my own CA ( Sectigo ) to avoid warning certificate from browser.
The workflow begin with the external page of FortiAth " https://fac.xxzxzxzxx.YY/portal"; authentication is processed by Fortiauth but the browser goes redirect at internal page in this url "10.12.0.1:1000/fortiauth.... " without also the HTTPS form... This is the IP internal interface of Fortigate for the specific SSID. The browser warning that it's insecure because it's not in HTTPS and show the warning to trasmit the credential in a non secure channel...
How do I avoid this warning and continue the protected session?

Fabio

Fabio · ‎03-30-2022

OK guys I solved !

I configured a entry in my DNS server and all is going OK. But it's strange because if i worked with hosts file the resolution didn't work...

Thank you all

Fabio

View solution in original post

Fabio · ‎03-29-2022

This is the capture Packet when Apple device tries to connect to wifi and the Fortigate replies with 303 redirect not to FAC but to FGT itself.. it's strage ..

The address portal it's fac.XXXYYY.ZZ and not falcon.XXXXXX.it ( the Fortigate ) ..

GET /hotspot-detect.html HTTP/1.0

Host: captive.apple.com

Connection: close

User-Agent: CaptiveNetworkSupport-428.0.0.0.1 wispr

HTTP/1.1 303 See Other

Location: https://falcon.XXXXXX.it:1003/fgtauth?02062921c99fa5fd

Connection: close

Content-Length: 231

Cache-Control: no-cache

Content-Type: text/html

X-Frame-Options: SAMEORIGIN

"<html><head><title>Firewall Authentication</title></head><body>Redirected to the secure channel.<a href="https://falcon.notartel.it:1003/fgtauth?02062921c99fa5fd">Click here</a> to load the secure authentication page.</body></html>"

Fabio

Markus_M · ‎03-30-2022

Hey Fabio,

here is a copy and paste from the 6.4 captive portal flow ( GUI > Authentication > Portals > Policies > Upper right there is the blue question mark) - that should explain how the redirect works:

The typical captive portal workflow for an end-user with a FortiGate/FortiWiFi goes as follows:

End-user browser attempts to go through the FortiGate/FortiWiFi to access a website.
(Optional step) FortiGate/FortiWiFi sends a MAC Authentication Bypass (MAB) RADIUS authentication request using the end-user's MAC address to the FortiAuthenticator.
(Optional step) FortiAuthenticator processes the MAB request. It return an Access-Accept response and authorized group name RADIUS attributes if the MAC address is authorized, or an Access-Accept response without the authorized group name RADIUS attribute otherwise.
(Optional step) Upon an Access-Accept response and correct group membership, the end-user browser bypasses the captive portal and is allowed through to the requested website. Workflow stops here.
FortiGate/FortiWiFi intercepts the request and redirects the browser to the FortiAuthenticator's captive portal. The redirect takes the form of an HTTPS request including parameters containing information unique to this particular authentication session. Here is a FortiGate/FortiWiFi redirect sample:
https://192.168.30.47/portal/?post=http://192.168.30.1:1000/fgtauth&magic=040d028c9aaae999&usermac=6...
FortiAuthenticator successfully authenticates the end-user.
FortiAuthenticator redirects the end-user browser to the FortiGate/FortiWiFi's captive portal API specified in the "post" parameter of the original captive portal redirect, e.g. http://192.168.30.1:1000/fgtauth in the above sample. The API call also contains the "magic" parameter (also from the original redirect), in addition to a username and password.
FortiGate/FortiWiFi uses the "magic" parameter to associate the API request to the firewall session that triggered the original redirect and triggers a RADIUS authentication request to the FortiAuthenticator using the username and password from the API request.
FortiAuthenticator verifies the credentials from the RADIUS authentication request. If valid, it returns a RADIUS Access-Accept response containing the appropriate RADIUS attributes.
FortiGate/FortiWiFi redirects the end-user browser to a website. The specific website depends on the FortiGate/FortiWiFi configuration.

What exactly is your redirect link on the FortiGate? You could crosscheck if the link has a / appended to it. It should be similar to "https://[FAC IP/FQDN]/portal/". If that / is missing the iOS may fail as we've seen the iPhone might not handle the HTTP response code 301 from the FortiAuthenticator webserver later.

Best regards,

Markus

anobre_FTNT · ‎01-09-2024

Hi Markus,

I have some issue in the step 7 (from typical captive portal workflow) that I create a new account, receive a confirmation on the website that is ok, but after this the website don´t redirect automatically to the credential login to put the user/pass created.

what can I check why is not open the credential login?

I force to appear it, but if I enter in a site as www.google.com I receive a message about HSTS, if I enter in another one with no HSTS the credential login page appear and I can login.

Alessandro Nobre

Fabio · ‎03-30-2022

hello Markus,

thank you for you patience :)

but my problems is before point 1 ... the rest is ok

After i click to my Wifi guest .. the normal scenario is show automatical browser page; in windows load the complete browser.. in Apple device load a WEBVIEW a minibrowser..

and the issue happened when I change the auth-portal setting on FGT linke this:

config firewall auth-portal
set portal-addr "falcon.XXXXXX.it"
end

When I setup this in Windows enviroment the page authentication still appear, but in Apple devices ( Mac, iPhone, iPad .. ) no longer appears.

If I unset the portal-addr the redirect to FAC goes ok " https://fac.XXXXXXX.it/portal

Fabio

Fabio · ‎03-30-2022

OK guys I solved !

I configured a entry in my DNS server and all is going OK. But it's strange because if i worked with hosts file the resolution didn't work...

Thank you all

Fabio

Markus_M · ‎03-31-2022

Hi Fabio,

good to hear that. The hosts file should always work, unless the format might be wrong.

Example:

192.168.112.1 vpn.forti.lab vpn

Best regards,

Markus

Fabio · ‎03-31-2022

why you put a space between vpn.forti.lab and vpn ?

it's a error with keyboard ?

Fabio

Debbie_FTNT · ‎04-04-2022

Hey Fabio,

that DNS entry contains the IP, the full domain name, and the shortened hostname (vpn) without DNS suffix (forti.lab) - this could also be an alias for example, or a different domain that also resolves to the same IP.

-> DNS entries in the host file contain one IP and one or more names.

In this case, it would allow the client to reach the IP at 'vpn.forti.lab' or just 'vpn'.

Cheers!

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++

packetman_ · ‎09-23-2022

Sorry to thread necro, but I wanted to know if this is the standard way of having a captive portal for external guests that does not prompt them to submit information? Asking because this workflow is somewhat broken in the latest release, and I wish to understand if a bug is currently preventing me from configuring a best practice implementation.

Fabio · ‎09-23-2022

What version do you have installed?
For the FGT I have version 6.4.10 and for the FortiAth I have 6.4.0

Fabio

Fortigate wifi external portal authentication with FortiAuthenticator

Nominate a Forum Post for Knowledge Article Creation

You are leaving our website