Staff & Editor

Technical Tip: Configuring shared FQDN for Captive Portal on the FortiGate using Loopback interfaces

Forum|Forum|5 months ago
December 18, 2025
0 replies
1364 views

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:

Simplified and consistent setup. All users go to a singular FQDN, which only requires a single certificate with the FQDN in the Subject Alternative Name (SAN) field (no need to customize each captive portal; one certificate and FQDN can be used for multiple captive portals).

Cons:

Each DNS record for the shared FQDN must resolve to a single IP address and not multiple IPs, otherwise clients may attempt to connect to an unreachable IP address due to DNS round-robin.
Single FQDN cannot be configured to resolve to separate IP addresses unless multiple DNS servers are used (clients on different networks query different DNS servers, which each resolve the shared FQDN to a different IP)

Pros:

Allows administrators to associate separate FQDNs with each FortiGate interface (and IP address) that is performing captive portal authentication.
Only one DNS server is necessary since there are unique DNS records for each captive portal FQDN.

Cons:

A single certificate may be used, but it requires either adding additional SAN entries to accommodate additional captive portals OR using a wildcard FQDN. Alternatively, separate certificates may be used for each captive portal FQDN.
Multiple FQDNs would need to be defined and managed as the number of captive portal configurations is increased.
Requires FortiOS v7.0.6 or later.

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-exempt and security-exempt-list)).

Captive Portal settings on user-facing interface

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.

Captive Portal settings on loopback interface

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.

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

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.

Captive Portal Web Browser Example.png

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').

Firewall Users Dashboard Example.png