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 that on Windows, excluding 'www.msftconnecttest.com' will prevent automatic triggering of the captive portal when switching the network.
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 1:
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).
Note 2:
The same problem may be faced with a Captive Portal configured via firewall policy, as seen in Technical Tip: How to create FortiGate captive portal using policy.
To solve the problem in this scenario, it is necessary to add the following services onto a new firewall policy: HTTP, HTTPS, and DNS permitting traffic to the FQDN addresses (FortiGate administration guide) of the URLs mentioned above.
Note 3:
In cases where Captive Portal is configured via firewall policy, and where the procedure indicated in note 2 does not solve the issue, see
Technical Tip: How to configure exemptions for Captive Portal for an explanation of how to configure a security-exempt-list.
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.
