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.

⚠️ 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. 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.

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 within one calendar day, 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.
Add terms of use if guests must accept them before access is granted.
Enable Redirect to HTTPS with the prepared portal name and certificate.
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.

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.

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 User Portal uses port 4443 by default and shouldn’t be opened broadly from the WAN for this purpose. Targeted access from a trusted internal management network is the safer option. 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.

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.

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.

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.

At this point, the hotspot and voucher are already further along than the 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.