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:

Check the authentication source and allowed group.
Allow Captive Portal for the client zone under Administration > Device access.
If an external DNS server is used, create a narrow DNS rule without a user condition.
Create a user rule with Match known users and Use web authentication for unknown users.
Configure HTTPS, destination page, and sign-out under Authentication > Web authentication.
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.

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.

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

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.

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.

These decisions matter for a production configuration:

Leave Use insecure HTTP instead of HTTPS disabled. HTTP transmits credentials unencrypted and does not work with Entra ID SSO.
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 is more suitable when a session should end after a defined period of inactivity.
Never requires manual sign-out and can leave stale user-to-IP mappings in place for longer.

There is no universal timeout. Shorter sessions matter more on shared devices and with changing users; on personally assigned devices, authentication 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 Entra ID SSO.

After making the selection, click Apply.

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. Use the FQDN URL to validate the certificate name and trust chain.

The settings are under Administration > Admin and user settings > Admin console and end-user interaction. Under Redirect users, select Firewall’s configured hostname or A different hostname; for this example, enter login.example.com. Under Certificate, select the certificate that covers this name. This certificate selection affects not only Captive Portal, but also other local firewall portals. Therefore, also check WebAdmin, User Portal, and VPN Portal before changing it.

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.

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

Check that the client has an address from 10.30.40.0/24, the intended gateway, and the correct DNS server.
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.
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.
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.
Under Current activities > Live users, check the username, client IP, and authentication type.
Test an allowed website and deliberately test a destination or service that is not allowed.
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.
With a user outside BYOD_Internet, confirm that authentication does not grant access through this rule.
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, 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.

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.

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, the open portal window, sleep, network changes, and inactivity. 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.

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.

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

Does Sophos Firewall Captive Portal work without Active Directory?

Yes. Captive Portal can also authenticate users against the local database, LDAP, or RADIUS. The authentication source must be selected under Firewall authentication methods, and the users or groups must match the subsequent firewall rule.

Should Captive Portal be reachable from the internet?

No. Captive Portal is intended for users who are already on an internal, BYOD, or wireless network. The VPN Portal and a suitable Remote Access configuration are intended for external access. Under Device Access, allow Captive Portal only for the client zones that actually need it.