Set up and test Wi-Fi directly on Sophos Firewall

A wireless network managed directly on Sophos Firewall is created under Wireless > Wireless networks. However, the SSID alone is not enough: the selected traffic mode determines whether clients receive their own network, join the AP LAN or are bridged to a VLAN. DHCP, firewall rules, NAT and the assignment to an access point must then all fit together.

⚠️ Important: This guide applies only to wireless hardware managed directly by Sophos Firewall. AP6 access points cannot be managed through SFOS. Sophos Central is the intended and recommended management option for multiple AP6 devices; alternatively, a single AP6 can be configured through its local interface. Firewall-managed Wireless is therefore now mainly relevant to existing APX installations, integrated LocalWiFi on desktop W models and supported Wi-Fi modules in Sophos Firewall or SD-RED.

This guide uses a guest wireless network with Separate zone. It is an easy-to-follow example because the client network, rules and permitted destinations can be clearly separated from the internal LAN.

Quick workflow:

Prepare Wireless Protection and the AP zone under Wireless > Wireless settings.
Accept the access point under Wireless > Access points.
Create the SSID, security settings and client network under Wireless > Wireless networks.
Add DHCP, a firewall rule and NAT under Network > DHCP and Rules and policies.
Assign the Wireless Network to the AP and use a test client to verify the IP address, DNS, Rule ID and unwanted access to internal resources.

Does this guide apply to the access point?

SFOS 22 can manage indoor access points from the APX series, the integrated wireless hardware of a compatible XGS firewall and compatible Wi-Fi expansion modules in Sophos Firewall or SD-RED. For external APX devices, this includes APX 120, APX 320, APX 530 and APX 740. The outdoor APX 320X model and the legacy AP series are not managed directly by a current Sophos Firewall.

AP6 is not part of this workflow. AP6 is configured through Sophos Central or, for an individual device, through its local interface. For the Central option, see Sophos Central Wireless requirements.

The local wireless feature is included in the Sophos Firewall Base License. A compatible access point is required separately. However, APX is already end-of-sale and reaches end-of-life on 31 December 2027. This guide is therefore mainly intended to help operate existing APX installations securely. For a new wireless platform, consider APX end-of-life and AP6 as its successor or other current wireless systems.

Choose the correct Client traffic mode

The choice under Client traffic is more important than the name of the SSID. It determines whether clients are in the same local Layer 2 network segment, who assigns IP addresses and which traffic passes through the firewall at all.

Separate zone

Separate zone creates a dedicated wireless interface with its own IP address and a VXLAN tunnel between the access point and the firewall. Clients receive their own subnet. This allows access for each wireless network to be controlled with targeted WiFi-to-WAN or WiFi-to-LAN rules. Sophos Firewall zones and interfaces explains how the zone, interface and network object work together.

This mode is well suited to guests, IoT or other networks that must be separated from the internal LAN. A hotspot with a captive portal, password of the day or voucher also requires Separate zone.

VXLAN reduces the usable MTU. Large packets can therefore cause fragmentation or reduced performance. The MTU should not be changed pre-emptively to an arbitrary value. First check whether only large transfers fail or TCP packets are retransmitted repeatedly; Check MTU and MSS on Sophos Firewall explains the controlled process.

Bridge to AP LAN

Bridge to AP LAN places the wireless clients in the same network as the access point. An existing DHCP server on this LAN assigns the client addresses. This is convenient but provides no separate network boundary for guests or untrusted devices.

The data path is crucial: communication within the same subnet can pass directly between the client, AP and switch and bypass Sophos Firewall completely. A firewall rule on SFOS can control only traffic that is actually routed through the firewall.

With integrated LocalWiFi, an additional bridge interface or Bridge to Ethernet is required depending on the XGS generation. This option should therefore be selected only when the wireless and wired LAN deliberately form the same security zone.

Bridge to VLAN

Bridge to VLAN separates the access point’s management network from the client VLAN. The switch port connected to the AP must carry both networks as a trunk. In the wireless profile, Bridge to VLAN ID specifies the client VLAN. With enterprise authentication, this client VLAN ID can be defined statically or through RADIUS with a static fallback.

The AP should initially be connected to the firewall through the untagged standard LAN for at least one minute so that it receives its configuration. Then enable VLAN tagging under Wireless > Access points > AP > Advanced settings and enter the AP VLAN ID for the management network. Only then should the switch port be changed to a trunk. The AP management VLAN and client VLAN can use different IDs. Sophos recommends that Separate zone and VLAN wireless networks are not mixed on the same AP. AP-side VLAN tagging is not available for integrated LocalWiFi0.

Bridge to VLAN avoids the VXLAN path and is often more suitable for larger, already well-segmented wireless environments. The same principle applies here: traffic within the client VLAN is not automatically inspected by SFOS.

Prepare the example network

The example uses these values:

Name in SFOS: Guest WiFi
immutable Hardware name: GuestWiFi
visible SSID: Company Guest
Security mode: WPA2 Personal
Client traffic: Separate zone
Zone: WiFi
Client network: 10.30.40.0/24
Interface and gateway: 10.30.40.1
DHCP range: 10.30.40.100 to 10.30.40.220
Firewall rule: WiFi_Guest_to_WAN

10.30.40.0/24 is an example from the private address space. Before using it, choose an available subnet that does not overlap with the LAN, VPN, RED, VLAN or a remote site. In the example, the first usable address, 10.30.40.1, belongs to the firewall’s wireless interface and is assigned as the gateway.

For existing APX devices, WPA2 Personal with AES is the secure, compatible baseline. A long, unique passphrase belongs in the password manager, not in tickets or screenshots. In SFOS 22, Sophos documents WPA3 modes only for the integrated wireless hardware in XGS 88w, 108w, 118w and 128w models. WPA3 should therefore not be planned for APX.

Configure SFOS-managed Wi-Fi

1. Allow the access point to connect

For an external APX, the management network and wireless client network are two different things. The AP obtains its own management address through DHCP from the connected network. The subsequent wireless clients, on the other hand, receive addresses from the network planned above, 10.30.40.0/24.

Open Wireless > Wireless settings.
Turn on Enable wireless protection.
Under Allowed zone, select the zone through which the AP reaches the firewall, for example LAN.
Make sure the AP receives an address, gateway and DNS through DHCP.
Check that port 2712 between the AP and firewall is not blocked by a switch, an ACL or an intermediate device.
Open Wireless > Access points and accept a pending AP with Accept.
Set the correct Country on the active AP. This determines which channels are legally permitted. If the Country of an APX is changed, save the setting and then restart the access point in a controlled manner so that the new channel list is applied.

The selection under Allowed zone applies to the management path of the access point, not to the subsequent zone of the wireless clients. If the AP is still registered with another Sophos Firewall or Sophos Central, it must first be deleted there. If this is not possible, reset it to its factory settings.

2. Create the Wireless Network

Enter the example values under Wireless > Wireless networks > Add:

Name: Guest WiFi
Hardware name: GuestWiFi
SSID: Company Guest
Security mode: WPA2 Personal
Passphrase: a long, unique passphrase
Client traffic: Separate zone
Zone: WiFi
IP address: 10.30.40.1
Netmask: /24

The Hardware name can contain no more than ten characters consisting of letters, numbers and underscores, and cannot be changed later. Name and SSID, however, can be adapted to the organisation’s naming convention.

Under Advanced settings, these choices are appropriate for the guest example:

Encryption: AES
Frequency band: only bands supported by the model and its radio modules
Client isolation: turn on if direct connections between guests are not wanted
Hide SSID: leave turned off
Fast transition: not supported by APX
Time-based access: use only with a deliberate maintenance window

Client isolation blocks only direct communication between clients on the same SSID and the same radio. It does not replace separation through zones, VLANs and firewall rules across multiple APs or radio modules. A hidden SSID is not a security control either; it only suppresses the visible display of the network name.

With integrated wireless hardware, simultaneous dual-band operation depends on the hardware. XGS 87w and 107w broadcast on either 2.4 GHz or 5 GHz. XGS 116w, 126w and 136w require a second radio module to use both bands. XGS 88w, 108w, 118w and 128w can use both bands simultaneously without an additional module.

When a wireless schedule is activated, SFOS restarts hostapd. This briefly disconnects all wireless clients on the affected access point, not only the clients on that SSID. The devices should reconnect automatically.

3. Add DHCP for the client network

For Separate zone, a complete DHCP server for the clients is not provided automatically. Under Network > DHCP > Server > Add, create a configuration such as:

Name: dhcp-wifi-guest
Interface: Guest WiFi
Dynamic IP lease: 10.30.40.100 to 10.30.40.220
Subnet mask: /24
Gateway: Use interface IP as gateway
DNS server: appropriate for the organisation’s DNS architecture
Conflict detection: turned on

The range deliberately begins above the interface IP address and leaves room for reserved addresses. A shorter lease than in a stable office network can be useful in a busy guest wireless network. Extremely short leases, on the other hand, cause unnecessary renewals.

The DNS servers assigned to clients are a security and operational decision. Internal AD DNS servers should not be made accessible to guests merely for convenience. Configure Sophos Firewall as a DHCP server explains the complete planning and lease verification process.

4. Check the firewall rule, NAT and local services

Create a rule for the required internet access under Rules and policies > Firewall rules > Add firewall rule > New firewall rule. The complete form, rule order and security features are explained in Sophos Firewall rules.

Rule name: WiFi_Guest_to_WAN
Action: Accept
Log firewall traffic: turned on
Source zones: WiFi
Source networks and devices: network object for 10.30.40.0/24
Destination zones: WAN
Destination networks: Any
Services: only the services required for the guest wireless network
Security features: appropriate Web, Application and IPS policies depending on the licence and use case

A descriptive network object such as net_WiFi_Guest makes the rule narrower and easier to understand than Source networks: Any. The service selection depends on whether DNS and NTP are used locally on the firewall or directly on external servers. A blanket Any rule is convenient but makes subsequent checks more difficult.

A NAT rule must also translate outgoing traffic to the WAN address. The existing default SNAT rule with MASQ often already covers new internal networks, but this should be checked in the actual ruleset rather than creating a second NAT rule just in case. Understand NAT on Sophos Firewall explains the relationship.

A WiFi-to-WAN rule does not automatically prevent access through existing broad WiFi-to-LAN or Any rules. The entire rule order must therefore be checked for internal access. If clients on the same Separate zone network need to communicate across multiple APs, an additional WiFi-to-WiFi rule is required. For a guest wireless network, this communication should be permitted only intentionally.

Access to the firewall itself is not controlled by the normal firewall rule. SFOS allows HTTPS and SSH from the WiFi zone by default. Under Administration > Device access, remove the WiFi checkboxes for HTTPS, SSH and all other local services that are not required for a guest wireless network. Leave DNS permitted only if the clients actually use the firewall as their resolver. Device Access and Local Service ACL explains the background.

5. Assign the wireless network to an access point

A saved Wireless Network is not yet broadcast by any access point:

Open Wireless > Access points.
Open the active access point through its name or Edit.
Check the correct Country.
Under Wireless networks, click Add new item.
Select Guest WiFi, confirm with Apply and click Save.

For multiple access points, a group under Wireless > Access point groups is clearer. This keeps SSID assignments consistent instead of managing them differently on each AP. Up to eight Wireless Networks can be assigned to an AP.

Test the wireless network in a controlled manner

Acceptance testing should not stop at “the SSID is visible”. Use a test client to check whether the planned network and rules are actually being used:

The AP must be active under Wireless > Access points. Under Network > Interfaces, the wireless interface remains Unplugged as long as no AP is connected with this Wireless Network.
Connect to Company Guest and check the AP, SSID, frequency and signal under Wireless > Wireless client list.
Under Network > DHCP > IPv4 lease, check that the client has received an address between 10.30.40.100 and 10.30.40.220.
Check the IP address, gateway and DNS on the client. On Windows, these commands help:

ipconfig /all
nslookup example.com

Test a permitted internet connection and deliberately test an internal destination that must not be permitted.
In the Log Viewer, filter by the client IP address and check the expected Firewall Rule ID and NAT Rule ID.

Success is not defined by internet access alone. The client must use the correct gateway and intended DNS servers, remain separated from unauthorised internal destinations and pass through exactly the expected firewall and NAT rules. Test firewall rules properly shows the general verification process.

Troubleshoot common errors

SSID is not displayed

First check whether Wireless Protection is active, the AP management zone is listed under Allowed zone, and the access point is active rather than pending or inactive under Wireless > Access points. Then check the Country, assigned Wireless Network, Frequency band and any schedule.

A saved network without an AP assignment is not broadcast. With integrated wireless hardware, model-specific band limitations or an unsupported legacy encryption mode can also prevent the profile from being bound to LocalWiFi0.

Separate zone interface remains `Unplugged`

Unplugged is normal while no access point is connected or the Wireless Network isn’t assigned to an AP. If the status remains despite an active APX and correct assignment, check the access point’s management path.

On SFOS 21.5 MR1 Build 261, this can occur when the firewall IP used by the APX management network is configured as an alias rather than directly on the parent interface (NC-175920). SFOS then can’t create the VXLAN tunnel for Separate zone. The workaround is to move the APX to a management network whose firewall IP is configured directly on the parent interface. Don’t delete the alias IP on suspicion.

The change interrupts the wireless networks broadcast by the AP. Check DHCP, the gateway, Allowed zone, and port 2712 in the target network first, and carry out the change in a maintenance window. Then verify the AP status, wireless assignment, interface status, and a test client’s connection. Sophos doesn’t name a fix version, so Unplugged alone doesn’t prove this issue on other SFOS versions.

Client doesn’t receive an IP address

With Separate zone, the DHCP server must be on the generated wireless interface and its range must match the interface network. With Bridge to AP LAN, the DHCP server on the AP LAN responds instead. With Bridge to VLAN, check the switch trunk, VLAN ID and the DHCP server reachable in the client VLAN together.

AP management DHCP and client DHCP must not be confused: the AP can be online even if no working DHCP server exists for the wireless clients.

Client has an IP address but no internet access

In this case, DHCP and the wireless connection are working, so the next checks concern the actual policy. Check the gateway and DNS, the WiFi-to-WAN rule, rule order, logging and the appropriate MASQ/SNAT rule. The Log Viewer shows whether the intended Firewall Rule ID matched or the implicit rule #0 dropped the traffic.

If the client can access the internet but can also reach internal systems, that is not a success for a guest wireless network. Existing WiFi-to-LAN, Any or overly broad network rules are probably taking effect.

AP connection or client communication remains unclear

Firewall traffic appears reliably in the Log Viewer only when Log firewall traffic is turned on in the rule and the Firewall log type is active under System services > Log settings > Local reporting. Wireless events themselves are not available there as a normal local Wireless log type; under System services > Log settings, they can be sent to Sophos Central or a syslog server.

For deeper diagnostics, Sophos documents awed.log for communication between the firewall and APX, wc_remote.log for wireless clients and hostapd.log for LocalWiFi. Check Sophos Firewall services and logs using the CLI explains how to read such logs without an uncontrolled service restart.

Large transfers are slow or fail

If only larger packets or longer transfers are affected, the VXLAN encapsulation used by Separate zone may play a part. There is no universally valid MTU value. First document the Rule ID, data path, retransmissions and a reproducible application test. Make a controlled change only after an MTU/MSS issue has been proven, then repeat the same test.