Captive Portal

*For the Fortigate

• FQDN & SSL Certificate: Ensure the FortiGate has a Fully Qualified Domain Name (FQDN) with a valid SSL certificate for the interface hosting the captive portal. This is simpler if the FortiGate is on the WAN side, though managing DNS records for LAN interfaces may depend on the system used for DNS hosting on the ship.
• SSL Certificate for Private Domains: Obtaining an SSL certificate for a non-public domain could be challenging, depending on the institution.
• Block DNS Over HTTPS/TLS: Ensure the default Internet access policy blocks browser-based DNS over HTTPS (DoH) and DNS over TLS (DoT). These protocols can cause issues by preventing the browser from resolving onboard DNS entries.
• Application Control: Block DoH and DoT in the Application Control profiles, then apply this profile to all firewall rules that provide Internet access.

Configuration for the captive portal is split between several different locations.

Note: The layout between the GUI/CLI are different, but since the CLI statements are the definitive device config, this is written based upon the layout in the CLI.

• config system interface:
  1. set security-mode captive-portal : Activates the captive portal on the interface.
  2. set auth-portal-addr “captive-portal-fqdn.example.com” : Unauthenticated users are redirected to the URL for login.
  3. set security-exempt-list “captive-security-exempt-list” : Specifies IPs or subnets that bypass the captive portal (e.g., trusted systems or internal services).
  4. set security-groups “user-groups” “allowed-for” “authentication” : Defines which user groups are allowed to authenticate via the captive portal.
• config user setting:
  1. set auth-type http https : Specifies the protocols (HTTP and HTTPS) used for the authentication process.
  2. set auth-cert “cert-loaded-in-fortigate” : Defines the SSL certificate to be used for HTTPS authentication.
  3. set auth-secure-http : Forces secure HTTPS for the authentication page to protect credentials during login.
  4. set auth-ssl-allow-renegotiation enable : Enables SSL renegotiation to ensure compatibility with certain clients or browsers during the authentication process.
  5. set auth-timeout 1440 : Specifies the duration (in minutes) a user stays logged in
• config user security-exempt-list
  1. edit “captive-security-exempt-list” : To edit the list of address groups that are allowed to bypass the captive portal.

• Non-Standard HTTP Ports: HTTP uses TCP/1000 and HTTPS uses TCP/1003.
• Auth Portal Address Configuration:
  • Use config system interface / set auth-portal-addr to set the FQDN of the captive portal.
  • Without this, users are redirected to the portal's IP address, causing SSL certificate issues since SSL certs cannot be issued for IPs.
  • Only the domain name segment is required in the command; the FortiGate auto-handles the scheme, port, and path.
• Captive Portal URL Access: The portal URL requires a query string with a key generated during the redirect process. Direct manual access does not work.
• Security Groups Configuration:
  • Use config system interface / set security-groups to specify user groups for the portal.
  • Without defined groups, the portal defaults to a simple Acceptable Use Policy (AUP) prompt.
  • Behavior based on group settings:
    • No groups + Allow All: AUP prompt.
    • Groups included in downstream firewall policies: Custom username/password page.
    • Explicit group configuration: Consistently provides the username/password page.
  • Recommendation: Always explicitly specify groups for consistent performance.
• Secure HTTP Authentication Settings:
  • Use config user setting / auth-secure-http and auth-ssl-allow-renegotiation for reliable workflows on browsers and mobile devices.
  • Captive portal workflow:
    1. Starts as HTTP for redirection.
    2. Switches to HTTPS before the user enters credentials to prevent insecure site warnings.
    3. Results in the login page loading with HTTPS and a valid certificate.

Firewall Rules can include address objects (or groups) and user accounts (or groups). Authentication is usually tied to the source IP address.

• Within Address Objects/Groups: Conditions are OR'd (any listed address can match).
• Within User Accounts/Groups: Conditions are OR'd (any listed user/group can match).
• Between Address and User Conditions: Conditions are AND'd (both address and user requirements must be met).

If the source is not authenticated at all, then it won't be able to match any rules which require authentication. As such, it is possible to trigger captive portal authentication just off of a firewall rule. However, there are fewer options available when triggering authentication this way, so best practice would be to enable it on the source interfaces.

Generally, the ship is expected to have two sets of firewall rules:

1. Underway Mode:
   • Internet access requires captive portal authentication.
   • Ensures that only authenticated users can access the network while at sea.
2. Shore Mode:
   • Captive portal authentication is not required.
   • Simplifies access for crew and systems when docked and connected to a trusted network.

Note: Firewall rules in FortiGate are evaluated top-to-bottom.

Rule Definitions:

1. CaptivePortalBypass Rule:
   • source = CaptivePortalBypass address group (trusted IPs/subnets exempt from the portal).
   • destination = any (allow unrestricted access to any destination).
   • Trusted devices (e.g., ship systems or critical infrastructure) that do not require captive portal authentication.
2. CaptivePortalRequirement Rule:
   • source = SourceIPGroup AND SourceUserGroup (both a specific source IP and authenticated user group must match).
   • destination = any (allow access to any destination for authenticated users).
   • Enforces captive portal authentication for users connecting to the Internet.

The assumption here is that normally CaptivePortalBypass is empty. When the portal needs to be bypassed in port, then the group is populated with address objects for the wifi network.

1. Underway:
   • CaptivePortalBypass group is empty. The bypass rule is skipped because there are no addresses in the group to match.
   • So all traffic falls through to the CaptivePortalRequirement rule. Denies traffic from unauthenticated sources. Ensures all Internet access requires captive portal authentication.
2. Shore:
   • CaptivePortalBypass group is populated. The bypass rule matches traffic from the specified source addresses (e.g., Wi-Fi network).
   • Since the traffic matches the first rule, it is allowed without needing captive portal authentication. No further rules (e.g., CaptivePortalRequirement) are processed for this traffic.