Set up a Sophos Firewall hotspot with vouchers or a daily password

A Sophos Firewall hotspot only grants guests internet access after they sign in. Use vouchers for individually restricted access. A daily password is simpler, but all guests share it.

A separate guest Wi-Fi network with Client traffic: Separate zone is required. The hotspot does not replace network separation or tightly restricted firewall rules.

Publicly offered hotspots may be subject to registration, filtering, privacy, or retention obligations depending on the country. Review these legal requirements for the specific location before rollout; the SFOS configuration alone doesn’t answer them.

The menu paths and field names in this guide follow SFOS 22.0. On older releases, compare the screen with the matching Sophos help before making changes.

⚠️ Important: This procedure only applies to wireless hardware managed directly by SFOS. AP6 access points aren’t managed through Sophos Firewall. In practice, the hotspot is therefore mainly relevant to existing APX installations, the integrated LocalWiFi of desktop W models, and supported Wi-Fi modules in Sophos Firewall or SD-RED. Set up Wi-Fi directly on Sophos Firewall explains the hardware distinction and the guest network.

The complete process is as follows:

Check the separate guest Wi-Fi network and wireless interface.
Choose a voucher definition or a daily password.
Assign the hotspot to the guest interface.
Review the automatically created firewall rule.
Create vouchers and test access with a new client.

Voucher, daily password, or terms of use only?

The three hotspot types serve different purposes:

Voucher: Each guest receives an individual code. You can restrict validity, online time, data volume, and the permitted number of devices. This suits visitors, external technicians, hotels, or events.
Password of the day: All guests use the same password. It is easy to distribute at small sites but doesn’t provide individual attribution.
Terms of use acceptance: Guests only have to accept the terms of use. Session expires determines when they must accept them again. This type has the lowest access barrier but doesn’t control who uses the connection.

For the following example, Voucher is the most appropriate choice. It combines simple distribution at reception with clear technical limits.

A guest user on Sophos Firewall, by contrast, is a temporary local user account with Username, password, group, and Captive Portal sign-in. This model fits when each person needs an identity with Access Time or quotas; it is not another hotspot type.

The daily password has an important side effect: As soon as a new password is generated, SFOS terminates existing hotspot sessions. Guests must sign in again. The Override wireless networks’ passphrase option also changes the Wi-Fi PSK and reconfigures or restarts the associated access points. This option should therefore only be used deliberately and with the interruption planned.

Check the prerequisites

This article starts with a guest Wi-Fi network that is already being broadcast. Before configuring the hotspot, the following points must work:

The wireless network uses Separate zone and has its own interface.
A test client receives an address, gateway, and DNS settings through DHCP.
The firewall’s system time, time zone, and NTP settings are correct. Among other things, they affect voucher validity and daily password changes.
The guest network doesn’t overlap with LAN, VPN, RED, or other VLANs.
Guests are blocked from internal networks and firewall management.
Suitable Web, Application, IPS, and Traffic Shaping policies have been selected for the hotspot.
A user or group has been designated to issue vouchers.
A suitable portal name, DNS, and a trusted certificate are available for Redirect to HTTPS.

For a Wi-Fi module in an SD-RED, the RED connection, DHCP, DNS, NTP, and required RED ports must also work. Set up and test Sophos SD-RED explains the complete traffic path and how the operating modes differ.

The example uses:

SSID: Company Guest
Guest network: 10.30.40.0/24
Gateway: 10.30.40.1
Hotspot: Guest WiFi Reception
Voucher definition: Guest-8h-2GB
one device per voucher
eight hours of online time
2 GB of data volume
one day of validity from the first sign-in

These values aren’t a general recommendation. A hotel lobby, a one-day event, and access for external technicians require different limits.

Preserve the existing configuration

Before editing a production hotspot, record or capture its interfaces, policies, hotspot type, administrative users, redirects, customization, and the position of its automatically created firewall rule. Changing the type, interfaces, or daily password can affect active access immediately. Make the change in a maintenance window with a test client available.

To roll back, restore these values and the original rule position, save, and test with a fresh client. For Voucher, create a new test code for this check. For Password of the day, remember that another password change terminates active sessions again.

Set up the voucher hotspot

1. Create a voucher definition

Under Wireless > Hotspot voucher definition > Add, set the limits for a voucher:

Name: Guest-8h-2GB
Validity period: 1 day
Time quota: 8 hours
Data volume: 2 GB

The three values don’t work in the same way:

Validity period starts with the first sign-in. In this example, the voucher becomes invalid no later than one day afterwards, even if its time or data allowance hasn’t been exhausted.
Time quota counts the actual connection time from sign-in and stops at sign-out. It also stops counting after five minutes of inactivity.
Data volume limits the total amount of data transferred using this voucher.

This allows a guest to go online several times during the one-day validity period that starts at first sign-in, but for no more than eight hours and up to a maximum of 2 GB. When any of the three limits is reached, the voucher can no longer be used.

After saving, the definition is available for new or existing voucher hotspots.

2. Add the hotspot

Under Wireless > Hotspots > Add, create the actual access:

Enter Name: Guest WiFi Reception.
Under Interfaces, select the interface for Company Guest.
Select the appropriate Application filter policy, Web policy, IPS policy, and Traffic shaping policy.
Set Hotspot type: Voucher.
Under Voucher definitions, select Guest-8h-2GB.
Set Devices per voucher: 1.
Under Administrative users, enter the users or group responsible for issuing vouchers.
Enable Users have to accept terms of use and enter the terms if additional acceptance is required.
Enable Redirect to HTTPS. A custom Hostname can contain only letters, numbers, and hyphens and isn’t case-sensitive.
Optionally enable Redirect to URL after login and enter a complete destination URL.
Optionally set Enable customization to Basic or Full.
Click Save.

Devices per voucher: 1 means the same code can’t also be used for additional devices. If a visitor needs to connect a notebook and a smartphone, deliberately increase the number of devices or issue a second voucher.

The protection policies apply to traffic allowed through the automatically created hotspot rule. Don’t simply reuse the same access permissions for guests as for internal users. Restricted web access, Application Control, IPS, and a suitable bandwidth limit are usually a better starting point.

With Basic, choose the logo, Title, and Custom text directly on the screen. SFOS supports .jpg, .jpeg, .png, and .gif for the logo. Sophos recommends a maximum of 300 × 100 pixels and provides Scale logo to recommended size for larger images. Use Full only if the complete sign-in page and its stylesheet and asset files can be maintained under control and retested after updates.

The optional destination URL is used only after successful sign-in. It doesn’t replace DNS or the captive-portal redirect. For acceptance testing, choose an HTTPS page that the guest can actually reach through the hotspot rule.

3. Configure HTTPS, the certificate, and the walled garden

Three global settings are located under Wireless > Hotspot settings. They don’t apply only to the hotspot that was just created and must therefore be reviewed against all existing hotspots:

Login page certificate: Select the certificate for the HTTPS sign-in page. The name or IP address used must be covered by the certificate, resolve completely to the firewall, and be served with a certificate chain trusted by guest devices. Otherwise, the browser shows a warning despite HTTPS. Let’s Encrypt on Sophos Firewall explains issuance and renewal.
Walled garden: Only add destinations that must be reachable before sign-in, such as a single page containing the terms of use. Every additional network and domain expands access without a voucher.
Delete expired vouchers: Automatically delete expired vouchers after a selected interval between 1 and 365 days. This keeps management clear but doesn’t replace an operational rule for issuing and revoking vouchers.

The sign-in page can also be customized. A simple customization with a logo, title, and short note is easier to maintain than a completely custom HTML template. Real voucher codes, internal hostnames, or support credentials don’t belong in either the template or screenshots.

For full customization, download the source files under Wireless > Hotspot settings > Download templates. The sign-in page can use variables such as <?login_form?>, <?error?>, <?terms?>, and <?asset_path?>; conditional blocks display content only for the matching hotspot type or sign-in state. If you build a custom form instead of using <?login_form?>, retain the action and method expected by SFOS:

<form action="?action=login" method="POST">
  ...
</form>

Depending on the hotspot type, the form also needs name="accept" with value="true", a text field with name="token", and a submit button. After every change, test sign-in, error messages, terms of use, redirect, and sign-out with a fresh client. Uploadable assets for full customization are .jpg, .jpeg, .png, .ico, .css, and .js; third-party scripts and unnecessary active content don’t belong on a sign-in page.

Create a custom voucher template as PDF version 1.5 or later. Put variables such as <?ssid#?>, <?psk#?>, <?code?>, <?validity?>, <?datalimit?>, <?timelimit?>, <?comment?>, and <?qr0?> on separate lines. For #, follow the mapping in the downloaded Sophos example template. If the template contains <?psk#?>, the Wi-Fi key also becomes part of the access document and must be treated as a password. Use only standard fonts without bold, italic, or similar formatting, and put the character set declaration specified by the Sophos example on the last line of the PDF. Before rollout, generate a real voucher, print or open the PDF, and test both the code and QR sign-in.

4. Review the automatically created firewall rule

When the hotspot is saved, SFOS creates an associated firewall rule and places it at the top of the rule list. This is convenient but security-critical: A rule near the top is evaluated before the rules below it and can unexpectedly take over traffic if its scope is too broad.

Under Rules and policies > Firewall rules, check the following:

The source interface and source zone only belong to the guest Wi-Fi network.
The destination zone and destination networks don’t allow access to LAN, server, management, or VPN networks.
Services aren’t broader than necessary.
Web, Application, IPS, and Traffic Shaping policies match the guest profile.
Log firewall traffic is enabled for acceptance testing.
The position doesn’t conflict with automatically created MTA, IPsec, or other hotspot rules.
A suitable MASQ/SNAT rule covers the guest network.

Access to the firewall itself is controlled separately under Administration > Device access. For the WiFi zone, HTTPS, SSH, and other unneeded local services should be closed. Leave DNS open only if guests actually use the firewall as their resolver. Plan firewall rules correctly and Configure Device Access securely explain how these controls interact.

Create vouchers in the User Portal

People assigned under Administrative users can manage vouchers in the User Portal without receiving access to WebAdmin. The Hotspots tab is only visible to these users. The User Portal uses port 4443 by default. Allow access from the management zone under Administration > Device access and test https://<firewall-IP-or-FQDN>:4443. Don’t open it broadly from the WAN for this purpose. Targeted access from a trusted internal management network is the safer option. Sophos portals at a glance distinguishes it from WebAdmin, the VPN Portal, and the Captive Portal. Under Hotspots, select the following values:

Hotspot: Guest WiFi Reception
Hotspot Voucher Definition: Guest-8h-2GB
Amount: the required number, with a maximum of 50 per operation
Description: for example, Visitors 2026-08-07
Optionally select Print, the page size, vouchers per page, and Add QR Code.
Click Create Vouchers.

The QR code opens the hotspot sign-in page and fills in the required details. It therefore contains access credentials and must be protected in the same way as the printed voucher code.

A simple process is required for distribution: Who may create vouchers, how is a code assigned to a guest, and when is a code that is still valid deleted? A large stock of printed vouchers at a publicly accessible reception desk weakens the technical limits.

Selected vouchers can be deleted manually in the User Portal or exported as PDF or CSV. For CSV exports, the separator must match the target system, otherwise codes and limits are split into the wrong columns when opened. Automatic deletion of expired vouchers only follows the global cleanup interval configured under Wireless > Hotspot settings and doesn’t revoke a code that is still valid.

Test guest access completely

Acceptance testing is performed with a device that doesn’t have an active hotspot session. A private browser window also prevents old cookies from distorting the result.

Connect to Company Guest.
Check that the client receives an address from 10.30.40.0/24, gateway 10.30.40.1, and the planned DNS servers.
Before signing in, verify that no internal or external destinations are reachable apart from the deliberately configured walled-garden destinations.
Open a normal HTTP page and verify the redirect to the hotspot sign-in page.
Check the certificate name, certificate chain, and browser status.
Enter an incorrect voucher code first and then the correct one.
Test DNS and an allowed HTTPS page.
Deliberately open an internal destination and the WebAdmin address; both must remain blocked.
In Log Viewer, filter by the client IP and verify the expected firewall Rule ID and NAT Rule ID.
With a test voucher, deliberately reach at least one configured limit and verify that access then ends.

Internet access alone isn’t sufficient evidence of success. The client must be on the correct network, pass through the expected rule, and remain isolated from internal systems and firewall management.

Daily password as a simpler alternative

For a shared daily password, select Password of the day instead of Voucher for the hotspot. Then specify the generation time, recipient addresses, and responsible administrative users.

An internal mailing group is more practical than many individual recipients. Sophos Firewall email notifications must work for this purpose. The password shouldn’t be displayed publicly on a permanent basis and should be tested with a new client after every automatic or manual change.

An assigned administrative user can view and change the current password in the User Portal under Hotspots:

Select the hotspot from the list.
Enter a password or use the automatically generated password shown, then click Generate.
Optionally select Send Mail. The option only appears if recipient addresses are configured on the hotspot.
Click Save.

After Save, the new password becomes valid immediately. The previous password becomes invalid and active sessions are terminated. A manual change therefore isn’t a side-effect-free functional check.

Override wireless networks’ passphrase is only required if the hotspot password and Wi-Fi PSK must be identical. Without this option, the Wi-Fi PSK remains unchanged and only hotspot sign-in uses the daily password. With the option enabled, the associated access points are reconfigured and restarted, interrupting connected clients.

Roll back the change

If acceptance testing fails, restore the previously recorded interfaces, policies, authentication type, redirects, and customization, then return the automatically created firewall rule to its original position. Test both permitted internet access and blocked internal destinations with a new client. An old browser cookie or existing session isn’t a valid rollback test.

Troubleshoot common errors

First check whether the client is on the correct guest network and whether the interface is assigned to the hotspot. Then check DHCP, gateway, and DNS, and deliberately open a normal HTTP page. Existing hotspot sessions, encrypted DNS methods, or a browser that directly opens HTTPS only can hide the expected redirect.

The voucher is rejected

Check whether the voucher belongs to the selected hotspot and whether its validity, time quota, data volume, or permitted number of devices has already been reached. For a QR code, also make sure the current and fully legible code is being used.

HTTPS shows a certificate warning or the destination page doesn’t open

For a certificate warning, the redirect name actually used, DNS resolution, Login page certificate, and complete trust chain must match. If sign-in works but Redirect to URL after login doesn’t, test the destination URL directly and use Log Viewer to check whether DNS, the firewall rule, and protection policies allow the request.

This confirms hotspot sign-in and voucher handling; the fault is in the downstream traffic path. Check the automatically created firewall rule, rule position, DNS, routing, MASQ/SNAT, and the selected protection policies. Log Viewer shows whether the expected Rule ID matches or another rule takes over the traffic.

Internal systems are reachable

This isn’t a hotspot error but an access rule that is too broad. Restrict the destination zones and destination networks of the hotspot rule and any existing WiFi-to-LAN or Any rules. Then test internal destinations again.

Responsible staff can’t create vouchers

The user or their appropriate group must be entered under Administrative users for the hotspot and be able to sign in to the User Portal. The required voucher definition must also be assigned to the hotspot; otherwise, it won’t appear for selection there.

The error remains reproducible

Document the client IP, time, SSID, hotspot name, and voucher status. Then check Log Viewer and, if necessary, hotspotd.log. Depending on the hardware, awed.log, wc_remote.log, or hostapd.log can help with the wireless path; dhcpd.log, firewall_rule.log, cschelper.log, and, for SD-RED, red.log and red-<serial>.log narrow down the relevant part of the process. Sophos Firewall service logs explains how to read these files without uncontrolled service restarts.

Don’t put the hotspot into production until Separate zone, DHCP, DNS, system time, the certificate, the walled garden, and the automatically created rule have been properly checked. The same applies to a daily password with email delivery or a Wi-Fi PSK change if delivery and the planned AP restart haven’t yet been tested.