|
As a primer, captive portals on the FortiGate work by intercepting client web traffic and redirecting the connection to an authentication portal hosted on the FortiGate. By default this authentication/captive portal URL is based on the FortiGate's interface IP address, but it is possible to override this and set a globally-used FQDN address to use instead. For example:
config firewall auth-portal
set portal-addr 'fgt.test.lab'
end
One issue with setting a global captive portal address is that it is shared with all captive-portals hosted on the FortiGate, which means that users on each network segment must be able to both resolve the FQDN via DNS and also access the IP address that the FQDN resolves to. This can be a difficult issue to solve since it would require DNS to conditionally resolve one shared FQDN to a different IP address depending on which network segment the client is connected to (not possible to solve with a single DNS server, generally speaking).
To solve this issue, FortiOS 7.0.6 and later have added the ability to set separate captive portal addresses on a per-interface/per-SSID basis, as well as the ability to set separate certificates to use for the authentication portal:
Per-Network Interface:
config system interface
edit <name>
set security-mode captive-portal <----- Must be set first before the other options appear.
set auth-cert <certificate_name>
set auth-portal-addr <fqdn_string>
next
end
Per-Wireless SSID:
config wireless-controller vap
edit <Name>
set captive-portal enable <----- Must be set first before the other options appear.
set auth-cert <certificate_name>
set auth-portal-addr <fqdn_string>
next
end
While it is not strictly mandatory to set an FQDN for usage with the captive portal, it is necessary in order to have a seamless user experience with encrypted authentication between the user and the FortiGate. For reference, the following is a typical captive portal authentication flow:
- Client connects to network (wired or wireless) and makes a web request. The client device will likely do this automatically by reaching out to a well-known captive portal detection URL.
- FortiGate intercepts this connection and redirects the client to the captive portal URL (which can either be the interface IP or an FQDN).
- If auth-secure-http under config user setting is set to enable then users will always be redirected to the captive portal using HTTPS. Otherwise the client will use the same protocol as the triggering traffic (i.e., the client making an HTTP web request results in a redirect to the HTTP captive portal on the ForiGate).
- If the HTTPS captive portal is used then the client may receive a TLS certificate warning in the web browser if the captive portal URL does not match the Common Name/Subject Alternative Name found in the captive portal's certificate.
- For more information on the subject of HTTPS redirection for captive portals, refer to the following KB article: Technical Tip: Using secure authentication (HTTPS) on a FortiGate and redirecting the authentication....
- Assuming there are no certificate errors, the client will proceed with authenticating to the FortiGate captive portal.
For a seamless user experience, ensure that an FQDN (e.g., 'captiveportal.example.com') is specified using the auth-portal-addr setting, and also ensure that the auth-cert setting is set to a certificate that includes the captive portal FQDN in the Subject Alternative Name field.
For a comparison of the global portal-addr vs. per-network auth-portal-addr settings, along with a practical configuration example for how to use the FortiGate as a local DNS server to resolve these captive portal FQDNs, refer to Technical Tip: FortiGate configured with multiple captive portals and as a DNS server.
Related document:
Technical Tip: Change the FortiGate Captive Portal Port
|
