Description
This article describes a configuration where the FortiGate has multiple captive portal interfaces, each of which have their own separate FQDN for the authentication portal that clients are redirected to. This is paired with a DNS server (in this case the FortiGate) to allow clients to resolve these FQDNs to the respective FortiGate IP address.
Scope
FortiOS v7.0.6 and newer versions.
Solution
FortiGate captive portals work by intercepting user web traffic and redirecting those users to a local authentication portal. By default, the portal URL uses the FortiGate's IP address (e.g., https://192.168.100.1:1003/fgtauth?[...] ), but this can be changed to an FQDN instead.
Before v7.0.6, it was only possible to set a global FQDN using the portal-addr option under config firewall auth-portal.
However, in v7.0.6 and later it became possible to set this captive portal FQDN on a per-interface/wireless SSID basis using the auth-portal-addr option:
config system interface
edit <name>
set security-mode captive-portal <--- Must be set first before the other options appear.
set auth-cert <certificate_name>
set auth-portal-addr <fqdn_string>
next
end
For more in-depth information discussing these options, refer to the following KB article: Technical Tip: Multiple addresses for the authentication portal
Historical Background:
One issue with setting a global captive portal FQDN is that all captive portals on the FortiGate would share this FQDN. However, this is a problem since the captive portal FQDN must only resolve to a single IP address or clients may be unable to reliably connect to the portal (DNS round-robin may result in connection attempts to unreachable IP addresses).
One method of resolving this issue was to use separate DNS servers per captive portal network segment and have each server resolve the captive portal FQDN to a different IP address. Consider the following example topology:
- FortiGate has portal-addr set to 'portal.example.com' and captive portals enabled on the port2 and port3 networks.
- Clients in the port2 network are configured to query DNS Server 1, which resolves portal.example.com to 192.168.100.1 (the interface IP of port2).
- Similarly, clients in the port3 network are configured to query DNS Server 2, which resolves resolves portal.example.com to 192.168.200.1 (the interface IP of port3).
- Both sets of clients are able to successfully resolve the captive portal FQDN via DNS (albeit to different IP addresses) and are able to proceed with authentication.
The major downside of the above design is that it requires the administrator to manage multiple separate DNS servers (or alternatively requires a DNS server capable of resolving an FQDN with different IPs depending on where the query came from). If a single shared FQDN must be used across all captive portals on the FortiGate then consider using the following KB article instead, as it uses a loopback interface to solve the issue: Technical Tip: Configuring shared FQDN for Captive Portal on the FortiGate using Loopback interfaces.
Configuring separate FQDNs for each Captive Portal interface:
As noted above, FortiOS 7.0.6 and later adds the ability to set separate captive portal FQDNs and certificates on a per-interface/SSID basis. At least one DNS server is still necessary to resolve these FQDNs to the proper FortiGate interface IP, but in this case the FortiGate can function as that DNS server for each of the local network segments.
In the above example topology, port2 and port3 are both captive portal networks, and port1 is connected to the Internet. To configure the above design, use the following steps:
- Navigate to Network -> Interfaces in the GUI (or config system interface in the CLI) and configure the user-facing interfaces for a basic captive portal configuration. This includes enabling DHCP and specifying the FortiGate's interface IP as the DNS server (or specifying a separate DNS server that can resolve the captive portal FQDNs), as well as setting a separate auth-portal-addr for each captive portal interface.
- For guidance on basic captive portal setup, refer to the following documentation: Captive portals.
- The auth-cert setting can also be optionally set here to specify the certificate that should be presented with the captive portal for this interface.
- User groups may be specified here and/or may be specified in the Firewall Policies created here. If user groups are not set in either place then the captive portal will only ask users to accept a disclaimer. This configuration does not specify any user groups but notes where this can be done.
config system interface
edit 'port2'
set vdom 'root'
set ip 192.168.100.1 255.255.255.0
set security-mode captive-portal
set auth-portal-addr 'fgt.captive1.test.lab'
set security-groups <Group1 Group2...>
next
edit 'port3'
set vdom 'root'
set ip 192.168.200.1 255.255.255.0
set security-mode captive-portal
set auth-portal-addr 'fgt.captive2.test.lab'
set security-groups <Group1 Group2...>
next
end
config system dhcp server
edit 2
set dns-service local <--- Instruct clients to use local FortiGate IP for DNS.
set default-gateway 192.168.100.1
set netmask 255.255.255.0
set interface 'port2'
config ip-range
edit 1
set start-ip 192.168.100.2
set end-ip 192.168.100.254
next
end
next
edit 3
set dns-service local <--- Instruct clients to use local FortiGate IP for DNS.
set default-gateway 192.168.200.1
set netmask 255.255.255.0
set interface 'port3'
config ip-range
edit 1
set start-ip 192.168.200.2
set end-ip 192.168.200.254
next
end
next
end
- Navigate to Policy & Objects -> Firewall Policy (or config firewall policy in the CLI) and create policies that allow authenticated captive portal users to access resources/destinations through the FortiGate.
- Note: DNS traffic is automatically exempted from captive portal authentication as long as a Firewall Policy exists that allows that traffic (see: Technical Tip: DNS traffic is allowed through captive portal without authentication). Ensure that an additional Firewall Policy is created to allow access to an external DNS server if the FortiGate is not being used for DNS.
- User groups can be set here to enable captive portal authentication (and also allow for Firewall Policy access based on user group permissions).
config firewall policy
edit 1
set name 'Captive_port2_to_Internet'
set srcintf 'port2'
set dstintf 'port1'
set action accept
set srcaddr 'all'
set dstaddr 'all'
set schedule 'always'
set service 'ALL'
set nat enable
set groups <Group1 Group2...>
next
edit 2
set name 'Captive_port3_to_Internet'
set srcintf 'port3'
set dstintf 'port1'
set action accept
set srcaddr 'all'
set dstaddr 'all'
set schedule 'always'
set service 'ALL'
set nat enable
set groups <Group1 Group2...>
next
end
- Navigate to Network -> DNS Servers and add the following:
- A new DNS Service on Interface entry for each captive portal interface (config system dns-server in the CLI) with the Mode set to Recursive (default mode).
- A new DNS Database entry (config system dns-database) that contains the captive portal FQDNs.
config system dns-server
edit 'port2'
next
edit 'port3'
next
end
config system dns-database
edit 'test.lab'
set domain 'test.lab'
config dns-entry
edit 1
set hostname 'fgt.captive1'
set ip 192.168.100.1
next
edit 2
set hostname 'fgt.captive2'
set ip 192.168.200.1
next
end
next
end
Verification:
The following screenshots show the expected results when clients connect to the FortiGate's captive portal network. Note the captive portal URL in the client web browser and the DNS results when the client queries the FortiGate for the captive portal FQDN:
Related Documents:
Technical Tip: Multiple addresses for the authentication portal
Technical Tip: DNS traffic is allowed through captive portal without authentication
