Explorer III

Solved

Fortigate wifi external portal authentication with FortiAuthenticator

Forum|Forum|4 years ago
March 23, 2022
10 replies
21567 views

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?

Best answer by Fabio

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

jhussain_FTNT

Staff

You can enable the auth secure settings with below command to redirect the captive portal with https page

config user setting
set auth-secure-http enable (default = disable)
end

FabioAuthor

Explorer III

No, not going. Until the request goes to FortiAuth is ok but after the authentication it's redirect to Fortigate and an error page shows.. and the url change the port "10.12.0.1:1003/fortiauth" ( before was 10.12.0.1:1000/fortiauth)

FabioAuthor

Explorer III

and the problem it's also for the replace messages that don't they are no longer reachable.. maybe for the change port..?

Markus_M

Staff & Editor

Hello Fabio,

the port 1000 is the HTTP port on FGT, the port 1003 is the HTTPS variant, as indicated by the previous poster.

On FAC, inside the portal settings, top right, you will see an excellent explanation of the complete captive portal flow. The flow roughly is (ignoring TLS):

1) DNS request for IP of some external page

2) HTTP connect to that IP

3) FGT blocks the request, replies with a 302/303 redirect that contains https://fac.xxzxzxzxx.YY/portal

4) DNS request for IP of fac.xxzyzyzyy.YY

5) HTTP request to fac.xxzyzyzyy.YY/portal

6) HTTP redirect from FAC with 301 (moved) to instruct client to go to http://fac.xxzyzyzyy.YY/portal/

7) Same as 4)

8) HTTP request to fac.xxzyzyzyy.YY/portal/

You can of course save some step 6-7 if you add the / after your link.

A packet capture will help you greatly to see when the error comes up and what resource is requested, what port is the client then talking to and to want device.

Best regards,

Markus

FabioAuthor

Explorer III

Hello Markus,

thank you for your answer.

I didn't find on top of the roght in FAC the portal setting and the workflow as you describe.

My Fac is 6.4.0 release, it's right?

I will upgrade to 6.4.2 in few days.

Thank you for replay

FabioAuthor

Explorer III

Debbie it’s OK, works and i don’t have anymore warning in the browser for Windows notebook but for Apple device ( macOS and iOS) don’t start the captive portal for authentication even if I open a browser.. any idea ..?

FabioAuthor

Explorer III

i find this :

Apple devices make use of Captive Network Assistant (CNA) which can detect the use of a captive portal. The apple device attempts to visit the page captive.apple.com. If the apple device is successful, the CNA doesn't load, but if it unsuccessful, then it launches a browser to prompt the user with the login page from the captive portal. When this browser is inadvertently closed or ignored, the device is disconnected from the network. Often times the user is unaware and does not know why email and updates are not being downloaded.

fonte: https://docs.fortinet.com/document/fortigate/5.4.0/cookbook/937300/captive-portal-bypass-for-apple-updates-and-chromebook-authentication

FabioAuthor

Explorer III

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

Markus_M

Staff & Editor

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=60:03:08:8f:5e:b6&apmac=08:5b:0e:08:d4:ee&apip=192.168.30.41&ssid=test&apname=FWF60D4613003326&bssid=00:00:00:00:00:00
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

Staff

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.

FabioAuthor

Explorer III

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

FabioAuthorAnswer

Explorer III

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

Staff & Editor

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

FabioAuthor

Explorer III

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

it's a error with keyboard ?

Fabio

packetman_

New Member

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.

FabioAuthor

Explorer III

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

Sign up

Login with SSO

Login to the community

Login with SSO

Scanning file for viruses.

This file cannot be downloaded