Set up and test Sophos Firewall Captive Portal

The Captive Portal signs in users who are already connected to a LAN or wireless network. Sophos Firewall can then associate their traffic with a user identity and apply rules to specific users or groups.

The interaction of the components is important: the portal creates the user mapping, but does not itself allow internet access. A matching firewall rule is also required. DNS, routing, NAT, and network segmentation must work independently.

The complete process can be reduced to six steps:

1. Check the authentication source and allowed group.
2. Allow Captive Portal for the client zone under Administration > Device access.
3. If an external DNS server is used, create a narrow DNS rule without a user condition.
4. Create a user rule with Match known users and Use web authentication for unknown users.
5. Configure HTTPS, destination page, and sign-out under Authentication > Web authentication.
6. Check the login on port 8090, the user under Live users, and the Rule ID in Log Viewer.

What Captive Portal does – and what it does not do

Captive Portal is suitable for BYOD devices, unmanaged clients, or networks where transparent user detection is unavailable. The user opens a web page, is redirected to sign in, and is then associated with their source IP on the firewall. The firewall can use this identity as a match criterion.

Other portal and authentication methods solve different tasks:

• A Wireless Hotspot is intended for guest access with vouchers, a password of the day, or terms of use. The complete process is described in Set up Sophos Firewall Hotspot.
• A Guest user is a temporary local account for Captive Portal. Create and securely manage guest users explains group, validity, credential delivery, self-registration, and cleanup.
• The VPN Portal is part of Remote Access. Captive Portal does not establish a VPN tunnel and should not be used as a public login portal.
• STAS, AD SSO, or SATC identify users without a browser login wherever possible. In such environments, Captive Portal can serve as a fallback for devices that transparent detection does not identify.
• For Microsoft login, follow the separate procedure Captive Portal with Microsoft Entra ID SSO.

The overview of Sophos portals helps distinguish the User Portal, VPN Portal, WebAdmin, and Captive Portal.

⚠️ Captive Portal does not replace segmentation. A BYOD or guest network remains in a separate zone or VLAN and receives access only to the destinations and services it needs. Signing in improves user attribution, but does not automatically make an overly broad network secure.

Requirements and example

The following points should be clear before configuration:

• A local or external authentication source works. For Active Directory, the server connection and group have already been tested; Connect Active Directory to Sophos Firewall explains the setup.
• The client zone, source network, and allowed user group are known.
• The client receives a correct IP address, gateway, and working DNS servers.
• A DNS record and a certificate trusted by the clients exist for the production portal name.
• An existing MASQ/SNAT rule and routing cover the internet traffic that will later be allowed.
• One allowed and one disallowed test user are available for acceptance testing.

The example uses:

• Client zone: LAN
• Client network: 10.30.40.0/24
• Network object: BYOD_10.30.40.0_24
• Firewall IP in the client zone: 10.30.40.1
• User group: BYOD_Internet
• Rule name: LAN-BYOD-to-WAN-Captive
• Internal DNS server: 10.20.0.53
• Portal name: login.example.com

Do not copy these values without checking them. The zone and network must match the actual client interface, 10.30.40.1 must be replaced by its firewall IP, and the group must come from the authentication source in use. From the client network, the portal name must resolve precisely to this reachable firewall address.

Set up Captive Portal step by step

1. Select the authentication method

Under Authentication > Services, Firewall authentication methods specifies which sources the firewall queries during sign-in. This can be the local user database or an already configured AD, LDAP, or RADIUS server. Create and test normal local users covers the group, password, Local, sign-in restriction, and lifecycle of this model. The order matters: if several servers are configured, SFOS checks them from top to bottom.

For this example, the BYOD_Internet group must exist on the firewall. With Active Directory, import it first. Only then can it be selected in the user rule and unambiguously assigned during testing.

A successful server connection alone is not enough. Therefore, a real portal login is used later to verify that password, group, and user rule work together.

2. Allow Captive Portal for the source zone

Under Administration > Device access, enable only the zones from which users actually need to sign in in the Captive portal row. In this example, this is LAN. Then click Apply.

Device Access controls access to a local firewall service. A normal LAN-to-WAN rule cannot replace this permission. Conversely, Captive Portal should not be enabled preemptively for WAN or unrelated internal zones. Device Access and Local Service ACL also explains the web proxy exception that can make local portals reachable despite a more restrictive zone table.

If clients use the firewall itself as their DNS resolver, DNS must also be allowed for their zone in the same matrix. If they use a separate DNS server, the following transit rule is required instead.

3. Allow DNS before sign-in

A browser can open login.example.com or the originally requested website only if DNS works before the user signs in. If the DNS server is not on the firewall, create a separate rule under Rules and policies > Firewall rules > Add firewall rule > New firewall rule:

• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: zone of the DNS server
• Destination networks: host object for 10.20.0.53
• Services: DNS
• Log firewall traffic: enable for acceptance testing

This rule has no user condition because the client is not yet authenticated. It allows only DNS to the intended resolver, not arbitrary traffic before login. If the environment uses several DNS servers, add their host objects explicitly.

Place the DNS rule so that the resolver can be reached before sign-in. In this example, it is directly before the user rule and above any broader rule that would drop or otherwise process DNS from this network. Then click Save.

Above the rule table, select the applicable protocol, IPv4 or IPv6. If clients reach the resolver only over IPv4, the IPv4 DNS rule is sufficient. If DNS is also used over IPv6, create an equally narrow IPv6 rule with the appropriate IPv6 network and host objects.

4. Create the user rule

Now create the actual access rule. The example uses these values:

• Rule name: LAN-BYOD-to-WAN-Captive
• Action: Accept
• Source zones: LAN
• Source networks and devices: BYOD_10.30.40.0_24
• Destination zones: WAN
• Destination networks: the required internet destinations or Any
• Services: only the required services
• Match known users: enabled
• Use web authentication for unknown users: enabled
• Users or groups: BYOD_Internet
• Log firewall traffic: enabled

Here too, select IPv4 or IPv6 above the rule table. In a dual-stack network, create a separate user rule with suitable network objects for each protocol family that you actually allow; an IPv4 rule does not cover IPv6.

Match known users makes identity a match criterion. Use web authentication for unknown users sends a matching, as-yet unauthenticated web request to the login. The group determines who can use the rule after successful authentication.

In SFOS 22 and 23, Use web authentication for unknown users is not the only trigger for sign-in. When the option is enabled, a matching, as-yet unauthenticated web request triggers authentication. When it is disabled, this setting initially allows the request without sign-in; however, an assigned Web Policy can still block it and thereby trigger web authentication. The deciding factor is whether a Web Policy for unknown users or groups is set to Block. What happens next depends on AD SSO:

• With AD SSO, both when triggered by the rule and when blocked by the Web Policy for unknown users: SFOS first attempts transparent sign-in. If this fails, the user is redirected to Captive Portal. After successful sign-in, the page is reloaded and the user’s Web Policy is evaluated again.
• Without AD SSO, when triggered by the rule: The matching, as-yet unauthenticated web request is redirected directly to Captive Portal.
• Without AD SSO, when triggered only by a Web Policy block: A block page appears. This may display a link to Captive Portal; an automatic redirect as with the rule trigger is not to be expected here.

If an unexpected login or block page appears, first check the rule that actually matched in Log Viewer, the setting in that rule, the Web Policy for unknown users or groups, and the AD SSO status under Authentication > Web authentication together. Record the existing values before making a change. Test with a pilot client that has no existing session, and only for its intended access: do not remove Block indiscriminately, relax user rules, or change AD SSO globally just to force a redirect. After sign-in, check Current activities > Live users, the user and Rule ID in Log Viewer, and both an allowed destination and a destination that must remain blocked. If unexpected behaviour occurs, restore the changed values and repeat the same checks.

For Services, Any is appropriate only if the group genuinely needs full client internet access after sign-in. For narrower access, deliberately select HTTP, HTTPS, and any other required protocols. Non-web traffic cannot display a login page itself; the user must first authenticate with a browser or the direct portal URL.

The rule must be above a broad IP-based allow rule. Otherwise, that earlier rule processes the traffic and it never reaches the user rule. After checking its position, click Save. Plan firewall rules correctly explains the basic evaluation process.

5. Configure HTTPS, redirect, and sign-out

Authentication > Web authentication does not enable portal reachability; it configures portal behavior.

The Captive Portal accepts a maximum of 50 characters each for the username and password. Test this limit with a real account before rollout, especially with external directories and automatically generated usernames.

These decisions matter for a production configuration:

• Show user portal link displays a link to the User Portal on the Captive Portal page. Enable it only if users actually need that portal and it should be reachable from their zone.
• Leave Use insecure HTTP instead of HTTPS disabled. HTTP would transmit credentials unencrypted. SFOS 22 does not support Microsoft Entra ID SSO over HTTP; in SFOS 23, this restriction applies to OpenID Connect SSO as a whole.
• Show web page after sign-in can redirect the user to the originally requested page or to a specified internal page.
• Open web page: In new browser window leaves the Captive Portal page open for logout and keepalives. If the same tab is replaced, sign-out is less visible to users.
• When captive portal page is closed or redirected signs the user out when the firewall stops receiving keepalives. This can also occur after sleep or a network change.
• When user is inactive evaluates a time period and the amount of data transferred within it. SFOS signs out a user whose traffic is below the configured threshold. Choose the period and data amount so ordinary background traffic does not keep every stale session active indefinitely.
• Never requires manual sign-out and can leave stale user-to-IP mappings in place for longer.

There is no universally correct timeout. Shorter sessions matter more on shared devices and with changing users; on personally assigned devices, sign-in can be less intrusive. Test each choice with sleep, a wireless network change, and manual sign-out. These local sign-out options do not apply to Microsoft Entra ID SSO in SFOS 22 or to OpenID Connect SSO as a whole in SFOS 23.

Before acceptance testing, record the SFOS version in use and the sign-in method. The local sign-out options mentioned are not a suitable way to address unexpected sign-outs with these SSO methods; this exception does not imply either an unlimited session or a specific IdP timeout. Keep the SSO test on HTTPS with a valid, trusted certificate. Do not enable HTTP, even for troubleshooting. Use a pilot account to check sign-in, the visible user mapping, and sign-out in the SSO process actually in use, rather than assuming that the local sign-out settings take effect.

In addition, Authentication > Services > Global settings > Maximum session timeout limits the total duration of successfully signed-in users. SFOS checks authorization every three minutes; access policies, surfing quota, and the data transfer limit can end a session as well as this maximum. This global value affects more than Captive Portal, so check other authentication methods before changing it.

After making the selection, click Apply.

The Device Console also contains global values for the Captive Portal minimum TLS versions, X-Frame-Options, and a cipher string shared with Web Proxy. Check HTTP proxy settings safely explains why these values are not a general tuning list and how to validate and roll back a change with portal and proxy tests.

Under Captive portal appearance, you can customize the logo, text, and colors. If you use Custom HTML instead of the default layout, keep the <div id="__loginbox"></div> placeholder and the Sophos-specified request-url block with its redirect script functional. Therefore, test custom HTML, CSS, or JavaScript first with Preview and then with a pilot account. A visually correct portal isn’t a success if its template breaks sign-in, redirection, or sign-out; use Reset to default to undo the customization.

<div id="__loginbox"></div>
<div id="request-url" style="display:none;">{url}</div>
<script>
var redirect_url = document.getElementById("request-url").innerHTML;
</script>

Place the script section immediately before </body>.

6. Check the portal name and certificate

The direct diagnostic URL is:

https://<Firewall-IP>:8090

In the example, first open https://10.30.40.1:8090. For production, https://login.example.com:8090 is easier to understand, provided the name resolves to the firewall and is included in the certificate.

Opening the IP URL proves that the portal is reachable. However, if the selected certificate covers only login.example.com, the browser will normally display a name mismatch warning for https://10.30.40.1:8090. Don’t enter credentials after bypassing this warning. Use the FQDN URL to validate the certificate name and trust chain.

Go to Administration > Admin and user settings. Before making a change, record the current Redirect users value and selected Certificate. In Admin console and end-user interaction, then select Firewall’s configured hostname or A different hostname under Redirect users; for this example, enter login.example.com. Under Certificate, select the certificate that covers this name. Use Check settings to test the redirect configuration before rollout. This certificate selection affects not only Captive Portal, but also other local firewall portals. Therefore, also check WebAdmin, User Portal, and VPN Portal after changing it.

If any of these tests fail, reselect the recorded redirect value and previous certificate and save with Apply. Then test the redirect and portals again.

A publicly trusted certificate avoids warnings on unmanaged devices. With an internal or firewall-signed CA, the CA must be installed as trusted on every client. Manage certificates on Sophos Firewall explains certificate names, the complete chain, and secure assignment.

Fully test the login and user rule

Start acceptance testing with a client that has no existing session. If necessary, disconnect an old test session under Current activities > Live users.

1. Check that the client has an address from 10.30.40.0/24, the intended gateway, and the correct DNS server.
2. Open https://10.30.40.1:8090 or the prepared FQDN URL directly. The IP URL tests portal reachability independently of an automatic browser redirect, but can produce a name mismatch warning if the certificate covers only login.example.com. Use the FQDN URL to validate the certificate.
3. With no existing session, open a normal HTTP page and check the redirect to Captive Portal. An HTTPS page with stored HSTS behavior is not a reliable test for this purpose.
4. Sign in as an allowed user. If local Sophos MFA is enabled, the OTP token must first be registered in the User Portal. Enable MFA for Sophos Firewall explains the setup.
5. Under Current activities > Live users, check the username, client IP, and authentication type.
6. Test an allowed website and deliberately test a destination or service that is not allowed.
7. In Log Viewer, filter for the client IP. The entry must show the expected user and the Rule ID of LAN-BYOD-to-WAN-Captive.
8. With a user outside BYOD_Internet, confirm that authentication does not grant access through this rule.
9. Trigger sign-out, sleep, or a network change and check when the user disappears from Live users.

In a dual-stack network, perform the test separately for IPv4 and IPv6. SFOS maintains the two user mappings separately, and both protocol variants require suitable firewall rules, so a successful IPv4 test does not prove that IPv6 access works.

Narrow down common errors

The portal does not appear

First open the direct URL on port 8090. If it is unreachable, check the source zone and Captive portal under Device Access, the client IP, zone mapping, DNS, and the portal FQDN.

If the direct URL works but the automatic login does not, a broader rule often processes the traffic first, or Use web authentication for unknown users is missing. In addition, only a matching web request can trigger browser login. Non-web applications do not display a Captive Portal page.

The login is rejected

Under Authentication > Services, check the authentication source and order. Then check the server connection, password, user group, quota, and, for local MFA, completed OTP registration. Recurring allowed or blocked access times are checked separately with Access Time for users and groups. Surfing quota and network traffic quota shows whether consumed internet time or data volume has been exhausted instead.

If the fault is not clearly located in the portal, Systematically troubleshoot Sophos Firewall authentication errors separates reachability, service selection, Live Users, the main group, and the subsequent traffic path.

For classic login attempts, access_server.log is relevant. oauth_sso_captive.log is needed only for the Microsoft Entra ID SSO process. Sophos Firewall Service Logs explains how to read the files without prematurely restarting services.

Login succeeds, but there is no access

A successful login confirms only authentication. The client zone, source network, group, destinations, services, rule position, NAT, and routing must also match the user rule. Log Viewer shows which Rule ID actually processes the traffic. Why a Sophos Firewall rule does not match provides a systematic check.

The user is signed out unexpectedly

Check the selected sign-out option and its time and data thresholds, the open portal window, sleep, network changes, and inactivity. Also check Maximum session timeout under Authentication > Services > Global settings, along with Access Time, Surfing Quota, and Network Traffic Quota. With When captive portal page is closed or redirected, the mapping ends after keepalives stop; this may not be visible at the moment the window is closed.

The sign-in page appears only after about two minutes

If STAS is used in the same network, its learning phase can delay the redirect. First check STAS status and unauthenticated clients. The general Captive Portal process does not change a global CLI value for this; the STAS article explains the relationship.

Several users share the same source IP

Captive Portal generally maps the user identity to a client IP. IP addresses entered under Multi-user hosts for Per-Connection AD SSO through the Direct Web Proxy therefore can’t use Captive Portal. Per-Connection AD SSO for multi-user hosts explains the appropriate process and the separate rule without Match known users for the remaining traffic.

Frequently asked questions