Description
This article describes a known-issue where users are stuck in an HTTP redirection loop after authenticating via captive portal (both for wired and wireless clients), and it also describes the auth-src-mac CLI option that affects this behavior. The following are symptoms associated with this issue:
- After authenticating to the captive portal (either the FortiGate-internal portal or an external captive portal), users may see the web-browser constantly switching between the FortiGate's captive portal address and the configured 'Redirect after Captive Portal' URL (aka security-redirect-url in the CLI).
- Devices not connected to the same broadcast domain as the FortiGate's captive portal interface (for example, the device is behind an L3 core switch/router that routes traffic upstream to the FortiGate) are experiencing this issue, whereas devices that are on the same broadcast domain/subnet as the FortiGate's captive portal interface (such as a tunnel-mode SSID on FortiAP) are not.
- Users may or may not be able to access the Internet, even after closing the web browser, re-opening it, and heading to a new web destination.
- Users may also experience this issue if the device's Source MAC address changes after authentication for some reason.
Scope
FortiGate, Captive Portal, Firewall User Authentication
Solution
In the original design, Firewall Authentication on the FortiGate was Source IP-based only: users would authenticate to the FortiGate (using a captive portal, for example) and be allowed through as long as the Source IP of the incoming traffic matched an existing authenticated Firewall User entry.
In FortiOS 5.6.4, 6.0.0 and onward, security was enhanced by allowing the FortiGate to bind the MAC address of the user's device to the Firewall User entry. This allows the FortiGate to check the Source MAC address of incoming traffic, which in-turn prevents users from attempting to impersonate other authenticated devices based on Source IP alone. However, this security feature only works if the FortiGate can see the MAC address of the actual authenticated device, which means that the device must be in the same broadcast domain/subnet as the FortiGate itself (in the same VLAN, for example).
If the device is behind another Layer 3 network device (such as a core switch or a router) then the FortiGate will see the MAC address of the L3 network device and not the MAC address of the actual authenticated device, and so the FortiGate will reject the traffic. When using captive-portal authentication, this can result in a loop where the client completes authentication to the FortiGate captive portal, attempts to reach a website behind the FortiGate, and is then caught and redirected back to the captive portal since the Source MAC does not match the authenticated Firewall User entry.
To solve this issue, FortiOS 6.0.2, 6.2.0, and onward added the following configuration option to allow administrators the flexibility to disable this security feature if necessary. This setting should be disabled when clients are behind L3 network devices to prevent the HTTP redirect loop from occurring:
config user setting
set auth-src-mac [enable** | disable] << **enabled by default
end
Additional Reading
FortiOS CLI Reference - config user setting
