Description
This article describes how to stop the captive portal from triggering in another tab on a browser and how to prevent the authentication page being insecure.
Scope
FortiOS v7.0 and above.
Solution
Pre-request:
DNS traffic should be exempted on the interface in which the captive portal is configured and an IPv4 policy should be set up to allow this traffic (it is possible to enhance the same with a DNS-filter) if using a public or external DNS server.
Topology:
PC -> [port2] FortiGate [port1] -> Internet.
In the lab setup used to test the process in this article, port2 (192.168.1.222) is enabled with security-mode set to captive-portal.
- Once the user opens the browser (such as Chrome) and tries to access google.com (or any site), the firewall inbound interface (port2) on which captive-portal is enabled will trigger an auth redirection portal for user identification on port 1003.
- However, this auth page will also be triggered in another tab instead of the actual tab in which user tries to access google.com
- This was observed due to a connectivity check traffic trigger from the chrome browser to 'www.gstatic.com/generate_204' before handling the user's request towards 'google.com'.
- Even if the user authentication is completed on the second tab, the error 'ERR_EMPTY_RESPONSE' occurs.
- The expectation here is to redirect the user to google.com itself post authentication.
- This can be achieved by exempting certain traffic like 'www.gstatic.com', 'www.msftconnecttest.com', 'edge-http.microsoft.com', 'detectportal.firefox.com' under the captive portal settings as mentioned below.
Note:
The FortiGate DNS server IP and user PC DNS server IP are expected to be the same to match the destination address to be exempted.
- By default, FortiGate will redirect to the unencrypted HTTP auth portal. To avoid warnings about communication over an unencrypted channel the secure redirect should be enabled in the Authentication settings.
However, using encrypted communication over TLS, the certificate used will be 'Fortinet_Factory' with the CN containing the serial number and due to which the browser will show a 'not secure' error. The 'portal-addr' defining the FQDN, which must resolve to the FortiGate interface IP, must be present on the certificate SubjectAlternativeName. Ideally, this FortiGate already has a publicly trusted certificate as required for unmanaged guest users in this Wi-Fi. For the sake of testing, this article is using a self-signed certificate. It can be only valid for managed guest devices that can trust its CA.
Technical Tip: How to generate a self-signed certificate from FortiGate was followed to set up the CN/SAN name 'lab.fortigate.local'; this certificate was signed by the CA 'Fortinet_CA_SSL'. It is also viable to create a CSR and have it signed by a public certificate authority.
- The configuration in the FortiGate CLI defined the re-direction URL to match the CN defined. 'User & Authentication -> Authentication Settings' mapped the certificate created.
- Install the CA certificate (Fortinet_CA_SSL) on the local PC under 'trusted root certificate'.
config firewall auth-portal
set portal-addr "lab.fortigate.local"
end
config user setting
set auth-cert "Captive-portal"
set auth-ca-cert "Fortinet_CA_SSL"
set auth-secure-http enable
end
- If another attempt is made to access google.com, the auth portal will be re-directed on the same tab to lab.fortigate.local:1003.
Note:
Ensure the auth-portal redirection URL is being resolved to the IP assigned on the inbound interface. In this case, it is port2 (192.168.1.222).
Warning:
Exempting the mentioned webpages may lead to certificate errors when the webpage loaded is negotiated using HTTPS.
Related articles:
Technical Tip: Captive Portal Authentication Network Interface.
Technical Tip: How to generate a self-signed certificate from FortiGate.
