Description
This article describes a configuration where the FortiGate has captive portal authentication enabled on multiple interfaces and the captive portal redirects to a single FQDN that is associated with a local Loopback interface.
This configuration is be useful in cases where administrators want to have a single FQDN that can be used by multiple different captive portal networks, and it is an alternative option to the configuration proposed in the following KB article: Technical Tip: FortiGate configured with multiple captive portals and as a DNS server
Scope
FortiGate, Captive Portal
Solution
By default, the URL used for local captive portal authentication on the FortiGate is based on the interface IP address assigned to the FortiGate (e.g., https://192.168.100.1:1003/fgtauth?[...]).
This can be overridden on the FortiGate to use an FQDN instead (which is generally required when configuring proper HTTPS communication with certificates) and can be done either globally or on a per-interface basis. See also: Technical Tip: Multiple addresses for the authentication portal
In the case of a single captive portal setup on the FortiGate, either option may be used with little difference. However, consider the following pros/cons between the two options when multiple captive portals are configured on the FortiGate:
|
Single shared FQDN used across multiple captive portals (e.g. 'portal.example.com') |
Multiple separate FQDNs used for each captive portal (e.g. 'portal1.example.com', 'portal2.example.com', etc.) |
|
Pros:
Cons:
|
Pros:
Cons:
|
This article will focus on the former case and will use a loopback interface to overcome the downsides mentioned above. A loopback interface will allow the shared captive portal FQDN to resolve to a single address, and administrators can allow captive portal clients to make connections to this destination IP address/interface for authentication purposes without needing to grant access to other physical networks connected to the FortiGate.
Note:
Administrators who want to implement per-interface captive portal FQDNs should instead refer to the KB article linked in the Description above.
Configuring Shared Captive Portal FQDN using a Loopback interface
Use the following steps to configure captive portals that redirect to a loopback interface for authentication. This configuration is an enhancement that builds on top of a basic captive portal configuration. Review the following document for more info on basic captive portal setup: Captive portals
Additionally, this example configuration will demonstrate using the FortiGate as a local DNS server to handle resolution of the captive portal FQDN, though an external DNS server could be used instead:
- Set the global FQDN used for captive portal authentication:
config firewall auth-portal
set portal-addr 'portal.example.com'
end
- Navigate to Network -> Interfaces and configure the FortiGate's user-facing interface (e.g., the user VLAN, wireless SSID, etc.) for a basic captive portal configuration (including enabling DHCP Server functionality and specifying a DNS server that can resolve the captive portal FQDN). Note the following key modifications:
- User access can be set to either Restricted to Groups (only specified user groups are allowed to authenticate) or Allow All (user groups are based on those defined in Firewall Policies).
- Access to the Loopback interface IP address must be exempted from captive portal authentication. This can be done by either adding the address to the Exempt destinations/services section OR by creating a Firewall Policy that has captive-portal-exempt enabled. Both can be done, but only one is required (see also: Technical Tip: How to configure exemptions for Captive Portal on the FortiGate (captive-portal-exemp...).
- Navigate back to Network -> Interfaces and select Create new, then create a new interface of Type -> Loopback Interface. During setup, ensure that an IP address is assigned and that the Security mode setting is enabled and set to Captive Portal.
- Enabling captive portal functionality on the loopback is necessary to accept incoming captive portal connections. If this setting is not enabled, then the user's connections to the captive portal will time out and fail.
- The captive portal-related settings may be left on defaults (i.e., User access set to Allow all, no need to specify user groups or any exemptions) since the loopback interface settings will go unused. Any user group filtering for the captive portal will instead be handled by the FortiGate interface/SSID that users are connecting from.
- Navigate to Policy & Objects -> Firewall Policy and create two new Firewall Policies:
- The first policy should allow the Captive Portal interface (in this case, VLAN160) to send traffic to the Loopback interface (e.g., lo0). Additionally, this policy should have set captive-portal-exempt enable added via the CLI; otherwise, the user's connections to the captive portal will time out (unless an exemption was already made on the interface settings in Step 1, in which case this specific setting may be omitted).
- The second policy should grant users access to the allowed destinations after authentication is completed (for example, Captive Portal interface to SD-WAN). This policy should include the User Groups that are allowed to match/use this policy after authentication.
config firewall policy
edit 1
set name 'Captive Portal Users to Loopback'
set srcintf 'VLAN160' <----- Captive Portal interface for users.
set dstintf 'lo0' <----- Loopback interface.
set action accept
set srcaddr 'all'
set dstaddr 'all'
set schedule 'always'
set service 'ALL'
set captive-portal-exempt enable <----- Traffic matching this policy is exempt from the captive portal.
next
edit 2
set name 'Captive Portal Internet'
set srcintf 'VLAN160'
set dstintf 'SDWAN'
set action accept
set srcaddr 'all'
set dstaddr 'all'
set schedule 'always'
set service 'ALL'
set nat enable
set groups 'LAN_Users'<--- Users in this group can match this Firewall Policy.
next
end
- Optional: Navigate to Network -> DNS Servers and add a DNS Database entry for the captive portal FQDN (only required if using the FortiGate for local DNS resolution). In this example, this would involve creating a DNS zone for the example.com domain and adding an entry for 'portal.example.com':
config system dns-database
edit 'example.com'
set domain 'example.com'
config dns-entry
edit 1
set hostname 'portal'
set ip 172.31.255.1
next
end
next
end
Verification:
After configuring the above, users who connect to the captive portal network will be redirected to the portal-addr FQDN specified under config firewall auth-portal. This FQDN will be resolved via DNS to the IP address of the loopback interface, and from there, the user will be presented with a captive portal for authentication.
Once the user is successfully authenticated, a corresponding entry will be created in the Firewall Users dashboard widget that shows the authenticated user information (the same information is also visible in the CLI with the command 'diagnose firewall auth list').
Related documents:
Technical Tip: FortiGate configured with multiple captive portals and as a DNS server
Technical Tip: Multiple addresses for the authentication portal
Technical Tip: Change the FortiGate Captive Portal Port
Troubleshooting Tip: How to troubleshoot if captive portal not getting triggered in the firewall
Troubleshooting Tip: General captive portal explanation, flow and troubleshooting
