Create and securely manage Guest users on Sophos Firewall

Guest users on Sophos Firewall are time-limited accounts for people who don’t have a regular user account. They are suitable for visitors, external technicians, or training participants who sign in through the Captive Portal and should receive only clearly limited internet access.

The secure quick path is:

1. Prepare a restrictive guest group with the required policies.
2. Under Authentication > Guest user settings, specify the prefix, group, password, and cleanup behavior.
3. Decide whether an administrator creates single or multiple accounts or whether self-registration with SMS is genuinely required.
4. Set validity to Immediately or After first login and hand over the credentials securely.
5. Test the Captive Portal, user rule, network separation, and one allowed as well as one blocked destination.
6. Disable or purge the account after expiry and check existing sessions and logs separately.

⚠️ A guest account is only an identity. It doesn’t separate a network or open a traffic path. Guests belong in a dedicated zone or VLAN and receive a narrow, logged firewall rule. Credentials, printouts, and SMS messages must be handled like passwords.

Distinguish Guest users, vouchers, and regular users

A Guest user is a temporary local user record. The firewall generates the username and password from the global guest user settings. After sign-in, it can associate traffic with this identity and apply the policies of the selected group.

Other access models solve different tasks:

• Regular local or external user: Suitable for recurring users with a permanent account, central user source, or MFA. Create and manage normal local users explains the model maintained directly on the firewall.
• Guest user: Suitable for a time-limited person with an individual account, its own validity, and optional usage controls.
• Hotspot voucher: A code for a wireless hotspot. Voucher validity, online time, data volume, and device count are managed in the hotspot model. The setup is covered in Sophos Firewall hotspot with vouchers or a password of the day.
• Clientless User: Associates a fixed IP address with a device without requiring a person to sign in. This workflow is covered in Set up Clientless Users on Sophos Firewall.

Guest users aren’t intended for remote access SSL VPN or IPsec remote access. The current SSL VPN policy doesn’t allow Guest users or Guest groups as Policy members. Use a regular user from an appropriate local or external user source for remote access. Set up SSL VPN remote access describes how to configure regular VPN access.

The current SFOS 23 help page Edit guest user still lists SSL VPN and IPsec remote access fields. However, the SFOS 23 help pages for SSL VPN policies and IPsec settings explicitly exclude Guest users and Guest groups from these two remote access methods. This is an unresolved documentation contradiction within the same version, not a verified version change. The fields aren’t evidence of supported guest VPN access; use a regular user for SSL VPN and IPsec. These exclusions don’t establish guest eligibility for Clientless SSL VPN, L2TP, or PPTP; those parts of the Edit page remain unresolved.

Example configuration and prerequisites

The following example uses a dedicated guest network and an account for a one-day visit:

• Zone: Guest
• Network: 10.30.40.0/24
• Portal name: login.example.com
• Guest group: Guest_Internet
• Username prefix: guest-
• Password length: 16
• Simultaneous sign-ins: 1
• Validity period: 1 day
• Validity start: After first login

10.30.40.0/24 is a private example network and must be replaced with the real guest network. login.example.com is a documentation name. Replace it with an FQDN that resolves from the guest network to the reachable firewall address and is covered by the portal certificate. The group receives only the policies that are genuinely intended for this guest access.

The following prerequisites must be met before accounts are created:

1. Guest network, DHCP, DNS, routing, and NAT have been tested with a narrowly scoped temporary test rule. Remove this rule before testing authentication; a separate DNS rule may allow only the required resolver traffic.
2. Internal networks and management services are blocked from the guest zone.
3. The Captive Portal is reachable only from the intended zone.
4. A dedicated group combines Access Time, quotas, Traffic Shaping, and Sign-in Restriction.
5. An administrator account and an independent management path remain available during testing.
6. Credential issuance, expiry, revocation, and retention are defined operationally.

Specify global guest user settings

Before creating the first account, open:

Authentication > Guest user settings

These values act as a template for newly generated guest accounts. A template change should therefore be tested with a pilot account first.

Choose secure general settings

Under Guest user general settings, specify the following fields:

1. Username prefix: guest- in the example. A neutral prefix is preferable to company, site, or customer names that disclose unnecessary information.
2. Group: Select Guest_Internet. Guest users inherit the policies of this group.
3. Password length: 16 in the example. Sophos allows a maximum of 50 characters each for the username and password on the Captive Portal. Choose a length that is sufficiently strong and can be entered reliably through the intended issuance process.
4. Password complexity: Select the strongest option compatible with the issuance and sign-in process.
5. Disclaimer: This text is printed below the generated credentials. State brief terms of use, responsibility, and a contact. Real credentials or internal technical details don’t belong in it. Configure the login disclaimer and messages on Sophos Firewall explains the global management of admin, authentication, SMTP, and SMS texts.
6. Auto purge on expiry: Turn this on only if expired user records should be removed automatically and the required operational evidence is retained elsewhere.
7. Click Apply.

Auto purge on expiry removes guest user details after expiry, but it doesn’t affect logs. This distinction matters for privacy and troubleshooting: account cleanup and log retention are separate processes.

Manage user groups securely on Sophos Firewall explains how group policies, the Main Group, and user overrides interact. The Default Group shouldn’t be used casually for guests. A dedicated restrictive group makes effects and rollback easier to understand.

Enable self-registration only when it is genuinely needed

Self-registration can be enabled under Guest user registration settings. It is more complex than controlled issuance by an administrator or reception desk and requires a reliable SMS process:

• Enable guest users registration: Turn this on only if guests should register themselves.
• SMS gateway: Select the provider that was tested beforehand.
• Guest username: Either use the mobile number or generate the name from the Username prefix.
• User validity: Set the maximum validity for self-registered accounts in days.
• Default country code: Choose a value that matches the actual user population. This default is displayed with the mobile number field on the guest registration page.
• CAPTCHA verification: Keep this enabled to make automated registrations more difficult.
• Click Apply.

The firewall supports HTTP- and HTTPS-based SMS gateways. HTTPS is preferable so credentials and provider parameters aren’t transmitted in clear text. The URL, HTTP method, mobile number format, request parameters, and response format must exactly match the documentation from the selected SMS provider. Example URLs from a guide must not be copied into production.

Test connection sends a test message to a mobile number. According to Sophos, this test can fail for a private SMS gateway with an internal IP address even when the actual workflow works. Don’t simply assume success in that case. Test the complete registration with a mobile device, provider log, and the actual SMS message.

Map the SMS gateway parameters correctly

Under Authentication > Guest user settings > SMS gateway > Add, enter Name, URL, HTTP method with Get or Post, Cell number format, and, where applicable, Use country code with mobile phone number and Number prefix. Number prefix permits alphanumeric characters and ASCII special characters.

Each request parameter has a Name and Value; SFOS replaces {mobileno} and {msg} with the mobile number and message. For the response, map Parameter index and Name to the Response format. Parameter names aren’t defined by SFOS and must exactly match the provider. This pattern uses reserved example values only:

URL: https://sms.example.net/send
HTTP method: Post
mobile = {mobileno}
message = {msg}
Response format: status={0}&message={1}
0 = status; 1 = message

Replace sms.example.net, mobile, message, and status with the real SMS provider’s values. Special characters in provider-required URL values must be percent-encoded, for example @ as %40. Credentials in the URL or request are secrets and don’t belong in screenshots, tickets, or logs. If the provider requires them, use HTTPS only and document their expiry. Under Administration > Messages > SMS customization, click Edit, enter a message that matches the template accepted by the provider, and save it with Apply. The placeholders {username}, {password}, and {expirydate} are available there for the message text. This saves the message separately. Then save the gateway with Save.

The provider test is only a partial check: In the pilot, a guest opens Register for internet access, saves the form with Save, completes the CAPTCHA, and actually receives an SMS message. The record must then be visible under Authentication > Guest users and the sign-in under Current activities > Live users. Traffic must be logged with the expected user and Firewall Rule ID. The user rule uses Match known users and Use web authentication for unknown users. The older SMS help page still calls the second option Show captive portal to unknown users; for SFOS 22, the current label takes precedence. A broad Any rule isn’t a substitute for this evidence.

If there is no SMS gateway, responsible owner, or adequate protection for the registration page, self-registration remains disabled. A responsible person then creates the accounts in a controlled manner.

Create single or multiple guest accounts

Create a single account with a name and email address

For a specific visitor, open Authentication > Guest users > Add single:

1. For Name, enter a value such as Visitor Zurich 2026-08-11. This is the record name, not the later username.
2. Enter the responsible email address. This field doesn’t send the credentials; Sophos documents Add and print or SMS for that purpose.
3. Set Validity period to the required period, 1 day in the example.
4. Choose Validity start deliberately.
5. Click Add to save or Add and print to save and print the credentials.

Immediately starts validity when the account is created. This fits when the credentials are handed over and used immediately. After first login starts the period at the first successful sign-in. This option is usually better for visitor accounts prepared in advance because validity doesn’t expire before arrival.

After creation, the list shows the generated username. Use this value, not the record name, when handing over the credentials.

Generate multiple accounts for an event

Under Authentication > Guest users > Add multiple, specify Number of users, Validity period, and Validity start. Add creates the accounts without printing. Add and print creates the accounts and the associated printouts.

Multiple accounts should only be created for a specific event. Count the printouts, store them securely, and hand them to a responsible person. Disable or purge unused and expired accounts. A large stock of unassigned credentials weakens the technical controls.

Check the group, policies, and sign-in limits

A newly created guest account initially inherits the group selected under Guest user settings. Under Authentication > Guest users > Edit, check the name, password, mobile number, email address, group, and individual policies, then save with Save.

User-specific policies take precedence over group policies. An override therefore only makes sense for a documented exception. For a consistent guest model, Access Time, Surfing Quota, Network Traffic, Traffic Shaping, and Sign-in Restriction normally remain grouped in Guest_Internet. Traffic shaping associates the user with a QoS policy. This can define policy association, priority, and separate upload and download limits.

The example uses the following limits:

• Sign-in restriction: User group nodes inherits the guest group’s restriction. For an individual exception, limit Selected nodes or Node range to the sources actually required. Any node only fits when sign-ins from every network are intentional and protected separately.
• Simultaneous sign-ins: 1, unless one guest account is explicitly permitted for multiple devices. This limits the number of concurrent sessions; you can inherit the global value or specify an individual value.
• MAC binding: Usually disabled for temporary guests. The firewall doesn’t bind remote-access VPN users by MAC address in any case. When enabled, sign-ins are allowed only from the specified devices; enter their MAC addresses in MAC address list.
• Quarantine digest: Enable only if the account actually uses Mail Protection and has a defined quarantine process. The digest sends the list of held emails to the user’s inbox.
• Remote access policies: Don’t plan these as VPN access for Guest users.

Account validity solves a different problem than time and usage policies:

• Validity period determines how long the guest account can be used.
• Access Time allows or blocks internet access during recurring time windows.
• Surfing Quota and Network Traffic Quota limit online time or data volume.
• A firewall rule determines which zones, destinations, and services are reachable at all.

Account validity, time limits, and usage limits don’t replace a restrictive firewall rule. A valid account must not reach an internal server unless the rule explicitly allows it.

Connect the Captive Portal and traffic path

Guest users normally sign in through the Captive Portal. Device Access, DNS, HTTPS, the user rule, and the selected authentication method must all match. The portal itself doesn’t permit internet access.

Run a complete positive and negative test from the guest network:

1. The client receives an address, gateway, and DNS from the guest network.
2. https://login.example.com:8090 is reachable and shows the correct certificate.
3. A normal web request leads to the portal.
4. A valid guest account can sign in.
5. Current activities > Live users shows the username and source IP.
6. The allowed internet test matches the expected user rule and Firewall Rule ID.
7. An internal destination and a disallowed service remain blocked.
8. An expired, disabled, or deliberately mistyped account is rejected.

On a dual-stack guest network, test this workflow separately for IPv4 and IPv6 because SFOS handles web authentication for IPv4 and IPv6 destinations separately. Also configure and test when the session ends under Authentication > Web authentication > Sign out user. Never isn’t appropriate for time-limited guest access.

The complete rule, Device Access, and HTTPS workflow is covered in Set up and test the Sophos Firewall Captive Portal. The Sophos portals guide distinguishes the User Portal, VPN Portal, and Captive Portal.

Issue credentials and operate accounts

The following operational actions are available under Authentication > Guest users:

• Print: Issue credentials in a controlled manner.
• Resend credentials: Resend credentials through the configured SMS gateway.
• Change status: Set an account to active or inactive.
• Change password: Assign a new password after loss or suspected exposure.
• View usage: Check internet usage and quota status.
• Reset user accounting: Reset usage counters and restart the Network Traffic Quota.

Reset user accounting changes state. Document the account, current usage, time, and reason beforehand. Don’t use reset as the first troubleshooting step because it changes the evidence and can grant the guest more quota.

For offboarding, disable the account first. Under Current activities > Live users, select its active session and terminate it with Disconnect; then verify that the user can’t sign in again and that the data path remains blocked. Next, check unused printouts, SMS access, and possible user-specific overrides. Delete the record or let Auto purge on expiry remove it only when no dependency remains.

Document global settings, the SMS gateway, group, and rule before the pilot. For rollback, reset the individual changed values; alternatively, disable self-registration and the pilot rule. A full backup restore isn’t a quick undo step: It replaces the current configuration and restarts the firewall; in HA, restoring the Primary also causes an interruption. Reserve it for the documented emergency procedure.

Troubleshoot systematically

The record name doesn’t work as a username

With Add single, Name is only the label for the user record. The actual username is generated from the Guest user settings and appears in the list or on the credential printout. Use exactly that value with the generated or changed password.

The account is valid immediately or not yet valid

Check Validity start and Validity period. With Immediately, time starts when the account is created; with After first login, it starts at the first successful sign-in. Also check the firewall time and time zone. A broader firewall rule doesn’t repair an expired account.

Self-registration doesn’t send an SMS message

Check whether Enable guest users registration is on, the correct SMS gateway is selected, and the mobile number, country code, URL, HTTP method, request parameters, and response format match the provider. Then check the provider log and actual SMS delivery.

A successful Test connection doesn’t prove the complete registration and Captive Portal workflow. Conversely, according to Sophos, a failed test against a private internal gateway doesn’t automatically prove that the SMS path is broken. Test with a real pilot account in both cases.

Sign-in works, but internet access doesn’t

Under Current activities > Live users, check whether the guest appears with the expected source IP. Then check the group, user-specific overrides, validity, Access Time, and quotas. In Log Viewer, the test traffic must match the expected user rule and Firewall Rule ID.

If the user is missing from Live users, inspect the sign-in path using access_server.log and the documented test time first. If the user is visible, the next check is the rule, routing, NAT, DNS, or protection policy. Troubleshoot authentication errors systematically separates these phases.

The guest account can’t be selected for SSL VPN

This is expected product behavior. Guest users and Guest groups aren’t valid Policy members for remote access SSL VPN or IPsec remote access. For an external technician who requires VPN, use a regular, narrowly authorized user with the appropriate MFA and remote access policy.

Final check

• The guest can reach only the intended destinations; internal networks and management services remain blocked.
• Validity, Access Time, quotas, and overrides match the credential issuance process.
• Self-registration remains disabled until the SMS and CAPTCHA pilot has passed.
• Live users, the rule ID, and positive and negative tests confirm the expected assignment.
• Offboarding disconnects active sessions and removes credentials and printouts that are no longer needed.
• Reset user accounting is performed only for a documented reason.

Frequently asked questions