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 Fusion (formerly 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. Firmware for APX devices managed by SFOS is provided through the firewall’s pattern updates and installed deliberately.

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.

If an 802.1X wireless network uses RADIUS and the firewall should identify users without an additional captive portal, RADIUS SSO with accounting explains the separate accounting path, the required Framed-IP-Address, and the test under Live users.

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 Appliance 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 Fusion or, for an individual device, through its local interface. For the Fusion 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.

Version boundary: The wireless help contains corresponding procedures for both SFOS 22 and SFOS 23. However, the existence of an SFOS 23 help page does not prove that a particular APX model is supported on SFOS 23. Hardware support must be confirmed independently against the Retirement Calendar and the support matrix. Before an upgrade, therefore, check the model, hardware revision and target build against the support matrix; do not migrate existing APX to SFOS 23 solely on the basis of these instructions. Integrated WLAN and SD-RED modules must also match the specific model and build. For new external access points, the AP6 management procedure linked above applies, not this SFOS-APX procedure.

To connect an existing APX without Ethernet through a wired APX, set up and test Sophos Firewall Wireless Mesh covers the root AP, radio channel, hidden backhaul, and controlled validation.

SD-RED with Wi-Fi module: The Wireless help documents DHCP option 234 for communication between an SD-RED module used as an access point and the Sophos Firewall. This is neither the client DHCP for the guest Wi-Fi nor a general requirement for APX or AP6. The help also mentions Sophos UTM in this context; this does not constitute new UTM installation instructions here. Before making changes, clarify module compatibility, management DHCP and the controller actually in use; do not copy an option value from another device type. The SD-RED setup is the separate procedure for connecting the site.

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. Set up a Sophos Firewall hotspot provides the complete process with the voucher definition, portal and automatically generated rule.

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.

To allow only a known list of devices on integrated wireless, create a MAC list under Hosts and services > MAC host. Then select Allow list under Advanced settings > MAC filtering in the wireless network and assign this list. The passphrase must be between 8 and 63 characters long. During validation, connect one listed and one unlisted test device.

A MAC address can be spoofed. The allow list is therefore only an additional admission filter and doesn’t replace WPA2 Personal with AES, a supported WPA3 method, a strong passphrase, or proper network separation.

When Bridge to AP LAN is used with integrated LocalWiFi, the wireless network must also be connected to the wired LAN. The correct method depends on the XGS Appliance model:

Gen.1 – XGS 87w, 107w, 116w, 126w and 136w: Create a bridge under Network > Interfaces > Add interface > Add bridge. Name is the display name, which can be changed later and supports up to 58 characters; Hardware name supports up to 10 characters from A-Za-z0-9_ and cannot be changed after saving. Under Member interfaces, assign the zone WiFi to the wireless interface and the zone LAN to the required Ethernet port. Additional Ethernet ports can be members of this bridge if needed.
Then select IPv4 configuration, enter the intended bridge IPv4 address in the existing LAN and select the matching subnet mask. Take the address and mask from the organisation’s LAN addressing plan, not from the Separate zone guest network used later. Before clicking Save, check that the address is not assigned to another device or simultaneously to a member interface, and is not an unreserved address in the dynamic DHCP pool. Do not change the existing client gateway or DHCP addressing plan incidentally. Before the change, check the backup, port dependencies and an independent administrative access path; the bridge interface workflow explains these shared checks and reserved hardware names. Its transparent inline example without an IP address serves a different purpose: this documented Gen.1 LocalWiFi workflow uses a bridge IPv4 address, but not every bridge needs an IP address. Click Save only after these checks.
Gen.2 – XGS 88w, 108w, 118w and 128w: The wireless interface must not be a member of a physical bridge. Instead, turn on Bridge to Ethernet under Wireless > Access points > LocalWiFi > Advanced settings, select exactly one Ethernet port and set the zone to LAN.
For Bridge to Ethernet, the selected physical port must have an IP address and must be neither a WAN port nor a member of another bridge. A VLAN interface cannot be bridged to LocalWiFi this way; the bridge zone must not be WAN either. The feature applies only to IPv4 and SSIDs of type Bridge to AP LAN. SFOS uses the bridge port’s existing DHCP server; if none exists, the help documents automatic creation of a new one. Before saving, therefore, check for a DHCP server already present on the LAN, and afterwards check the server, pool and lease to prevent competing DHCP responses. When disabled, the bridge is deleted and the configuration is returned to the physical interface. Therefore, back up the initial state beforehand and check the rollback, including admin access, LAN DHCP and client connectivity, during a maintenance window.

An external APX does not require this additional LocalWiFi bridge. During a hardware replacement, a physical wireless bridge from Gen.1 also cannot be transferred unchanged to Gen.2. Sophos Firewall Backup and Restore explains the required preparation.

Bridge to AP LAN should only be selected when the wireless and wired LAN deliberately form the same security zone.

For this LAN workflow, save the Wireless Network with Save after selecting Bridge to AP LAN, security settings and the MAC list. Under Wireless > Access points > LocalWiFi, check the correct Country, then assign this specific network under Wireless networks > Add new item and save; Guest WiFi later in the guide is a separate example. After configuring the bridge, the listed test device must be able to connect and the unlisted device must be rejected. On the admitted client, check for a lease from the intended LAN range, the matching subnet mask, the existing gateway and the intended DNS servers; verify the lease on the DHCP server actually responsible for the LAN. Test name resolution and an intended service on a wired LAN device. If no lease arrives, first check MAC admission, network assignment, bridge members and LAN DHCP. Local LAN communication is intentional here and does not prove guest isolation or a data path controlled by SFOS.

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.

After activation, the AP tries for 60 seconds to obtain an address by DHCP in the configured management VLAN. If no reply arrives, it falls back to DHCP on the untagged LAN. This is a useful recovery path, but not a success criterion: correct the VLAN, trunk, and DHCP until the AP is actually online through the planned management VLAN. With Bridge to VLAN, SFOS automatically creates the VLAN interface and corresponding firewall rules. Review these objects because each AP creates a separate backend interface for every zone, so a design with many APs and zones can grow significantly.

The zone of the firewall interface for the AP management VLAN must be allowed under Wireless > Wireless settings > Allowed zone. The client traffic mode and AP-side VLAN tagging must match: Bridge to VLAN requires AP tagging; for Separate zone, it can be enabled or disabled. The older VLAN help describes another case as bridge to an access point VLAN and requires AP tagging to be disabled there. This wording should not be taken to imply an additional current UI option. For the untagged Bridge to AP LAN procedure described here, leave AP tagging disabled; for a different design, confirm compatibility on the actual model and build before switching.

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.

The security list also contains No Encryption, WEP Open, older WPA and WPA/WPA2 mixed modes. These entries are not recommendations for a new or renewed Wi-Fi network: do not use an unencrypted guest profile or WEP/TKIP fallback; instead, replace incompatible clients or migrate them separately. On XGS 88w, 108w, 118w and 128w, profiles with TKIP or AES/TKIP can be saved but cannot be assigned to LocalWiFi0. On these models, select the strongest WPA3 mode supported by all intended clients, or WPA2 Personal with AES, and actually test the connection.

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. SFOS offers DMZ, LAN and WiFi for this. Accept the selection and save the Wireless settings with Apply before accepting the AP.
Make sure the AP receives an address, gateway and DNS through DHCP. You can’t configure a static management address on the AP.
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.

On a firewall with two Wi-Fi cards, changing Country affects both cards and sets both channels to Auto. Document both radio configurations beforehand and check both afterwards. According to the help, both radios on the APX 320 must be set to 5 GHz to list all available 5 GHz channels; in Israel, however, Radio 0 supports only 2.4 GHz. Local country approval takes precedence: do not use a different Country selection to force channels.

Under Wireless > Wireless settings > Advanced settings, Timeout specifies the number of minutes between an access point going offline and the timeout notification; after this period, SFOS considers the AP inactive. For a controlled check, first record the existing value and disconnect only a test AP without production clients during a maintenance window. After a temporarily shortened but operationally safe period, the notification and inactive status must appear. Then reconnect the AP, confirm that its status returns to active, and restore the previous timeout value.

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 Fusion, it must first be deleted there. If this is not possible, reset it to its factory settings. For planned decommissioning, first remove the uniquely identified AP from the network, then select that AP under Wireless > Access points and use Delete. Verify its identity beforehand; afterwards, check that its entry has been removed and that the remaining APs and SSIDs still work. Delete is not the removal of a wireless assignment or the deactivation of a group; do not delete a production AP experimentally for troubleshooting.

The control connection on port 2712 is AES-encrypted between the firewall and access point. Allowing the port still doesn’t replace restricting the AP management network to the zone that actually needs it.

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 supports up to 58 characters and the SSID supports 1 to 32 printable ASCII characters. Both can be adapted to the organisation’s naming convention. The wireless Name can be changed later and is displayed in other settings instead of the Hardware name. All characters except '"<>#%\/, are allowed in this field; do not apply this restriction to SSID, Hardware name or Passphrase.

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: uses IEEE 802.11r and requires WPA2 as the Security mode. APX does not support this feature. Use only on compatible non-APX hardware after checking the model, SFOS build and clients; this implies neither AP6 support nor approval for all W models or for WPA3.
Time-based access: controls the permitted access hours for this SSID. Use Add new item to select a suitable schedule or create your own. Perform activation and configuration changes during a planned interruption window, because activation restarts hostapd and disconnects all clients of the affected AP, as described below. Use a test client to check both the intended permitted and blocked periods; this access schedule is not the schedule for radio or rogue AP scans.

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.

If a known device is also to be blocked, under Hosts and services > MAC host > Add, create, for example, Bad hosts with Type: MAC list, enter the MAC addresses actually to be blocked and save. In the guest profile, under Advanced settings > MAC filtering, select the blocklist option, assign this MAC list and save the Wireless Network with Save. The Separate zone help calls this option Blacklist; check the blocklist label in the build in use. Use one blocked and one allowed test device to check that only the blocked device is rejected. A spoofed or randomised MAC address can bypass this block: it proves neither malware detection nor a clean device and does not replace protection policies or network separation. Allowed zone permits the AP management path; enabling Wireless Protection alone is not evidence that all Wi-Fi or LAN packets are scanned for malware.

Validate Enterprise Wi-Fi and RADIUS separately

For a wireless network using 802.1X, select the RADIUS server under Wireless > Wireless settings. The access point does not communicate directly with the RADIUS server: it uses port 414 to communicate with the firewall for authentication and port 417 for accounting. The firewall then forwards accounting to the configured RADIUS port, normally 1813.

For Enterprise authentication, use the Wireless network Name as the NAS ID, not automatically the visible SSID or the Hardware name. These values can differ. Match the RADIUS policy to this name and check a test client’s authentication log to confirm that the expected NAS ID and policy are used; check authentication and accounting separately.

Accounting must be enabled on the RADIUS server; Interim Accounting Updates are not supported in this wireless path. Do not treat the Secondary RADIUS server as a general failover solution: APX and Wi-Fi-enabled devices can only use the primary RADIUS server, and XGS Appliances do not support a secondary RADIUS server for this workflow.

For this SFOS-managed wireless path, the SFOS 22 and 23 wireless settings require a NAT mapping for the access point networks when the RADIUS server is connected to the firewall through an IPsec tunnel. The source IP must be translated to the exact firewall IP address used to reach the RADIUS server. This concerns the AP networks, not the wireless client network in general. The help refers to shell configuration using sys-traffic-nat, but does not provide a complete executable command here. This does not establish a general NAT requirement for other RADIUS paths.

Before making a change, document the exact SFOS version and build, AP networks, source address actually used, intended firewall IP for translation, tunnel and traffic selectors, return path, and RADIUS logs. Without syntax confirmed for this build and data path, do not make a shell change: ask Sophos Support to confirm the supported shell, parameters and addresses to use, together with prechecks, success checks and exact rollback. Only make the change in a maintenance window using that confirmed procedure; then use a test client to verify 802.1X authentication and accounting, and compare the source IP observed at the RADIUS server and the reply path with the intended values. If they differ, do not broaden access rules; review the evidence with Support and use the confirmed rollback if needed.

Firewall-generated authentication traffic must be distinguished from forwarded client traffic. The article on IPsec routes for forwarded traffic explains system ipsec_route and NAT for that forwarding path; it does not contain a sys-traffic-nat procedure. Neither its DNAT/reflexive SNAT nor a LAN-to-VPN rule replaces the system traffic NAT configuration required here.

After configuring the general and advanced settings and, where applicable, the Enterprise and MAC filter settings, save the Wireless Network with Save – even if no MAC blocklist is used. Under Wireless > Wireless networks, check that Guest WiFi appears with the intended settings. Only then create the DHCP server on this interface and assign the network to an AP as described below. Unplugged before assignment to an AP is not a reason to recreate the profile or create it with a different traffic mode.

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. Under Administration > Device access, check the WiFi permissions actually configured for HTTPS and SSH rather than assuming a particular default setting. 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.

Create a group under Wireless > Access point groups > Add with a name, Wireless networks, optional VLAN tagging, and the included Access points. Before saving, verify that the VLAN assignment really fits every selected AP.

⚠️ Operational impact: Turning off an access point group makes every included AP stop broadcasting the assigned wireless networks. Schedule a group change in a maintenance window with a documented AP and SSID list.

Change radio settings and AP groups deliberately

Under Wireless > Access points > AP > Advanced settings, channel, Dyn chan, TX power, and Channel width affect more than one test client. A dynamic channel change can force connected clients to reconnect. Wider channels can increase throughput in a low-density environment, but additional overlap can reduce it in a high-density environment. SFOS defaults to 20 MHz on 2.4 GHz and 40 MHz on 5 GHz. Measure transmit power and channel width per site instead of simply maximizing them.

Turn on Spanning Tree Protocol (STP) protects bridged networks from layer 2 loops and the resulting broadcast storms. Do not treat STP as a performance switch. After a change, test at least two real clients, roaming, DHCP, DNS, and a longer transfer; with automatic channel selection, also record the change time and successful client reconnection.

If dynamic channel selection is to run only at specified times, first enable Dyn chan, then Time-based scan for each band, and assign the intended Schedule under Select scan time > Add new item or create it via Add. After Save, monitor the scan time and any possible client reconnection. Before making group changes, uniquely identify the AP using ID (serial number), Label and Group. An individual WLAN can be deselected again in its AP details using remove; then save and check the remaining SSIDs. This is not the same as disabling the entire AP group. For a planned AP restart, the selected AP can be restarted under Wireless > Access points using Restart; first save the client list and logs, then repeat the connection tests described below.

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.

Scan for rogue access points in a controlled manner

Rogue AP scan is available only on Sophos Firewall appliances with integrated Wi-Fi; external APX access points cannot perform this scan. Under Wireless > Rogue AP scan, Scan now searches for access points within radio range. Connected wireless clients are briefly disconnected during the scan. A manual or scheduled scan therefore belongs in a known time window and should not run without notice during production use.

Detected devices appear under Unrecognized access points and are deliberately marked as authorised or as a rogue AP. This classification does not replace incident investigation: correlate the SSID, BSSID, channel, signal, location and possible switch port before treating an unfamiliar wireless network as a device in the organisation’s own LAN.

For recurring scans, select a schedule under General settings > Schedule system-triggered scan at. With LocalWiFi0, Bridge to Ethernet enabled and a wireless network using Bridge to AP LAN, the scan only shows nearby networks in the same frequency band as the assigned wireless network. Record this product limitation when evaluating the result.

Apply the scan schedule with Apply. In the results, use the actions Mark as “authorized access point” or Mark as “rogue access point” and check the resulting assignment. An entry marked as rogue is a classification, not a documented mechanism for shutting down or blocking a third-party access point.

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 Fusion 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.

The log of a reachable APX can be read using awetool if required. Log in to the firewall CLI as admin, select 5 – Device Management, then 3 – Advanced Shell, and start awetool. Select Connect to an AP, select the target AP by its identity, confirm with OK and complete the connection with y. Only on this AP are logread and logread -f the documented read-only checks. The command reboot, which is also offered, disconnects clients and changes the state; it is to be used only after backing up the logs, during a maintenance window, and followed by checks of AP status, SSID, client list and actual traffic. Do not apply these APX shell steps to AP6, integrated LocalWiFi or UTM.

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.

Safely interpreting wireless objects in the XML API

When automating the settings described above, treat the network profile, local radio component, AP group, and global wireless settings separately. The XML references for SFOS 22 and 23 document the following objects, but do not authorize sending a write request copied without changes. Securing Sophos Firewall XML API access explains access, explicit operations, response evaluation, and safe retries. Before making changes, preserve the existing object state, dependencies, and a confirmed rollback path. For the source conflicts noted below, first clarify the affected write fields in API help for the installed build or with Support; do not send them until then. All codes below are object-specific XML status values, not HTTP status codes; all Message.* symbols are unresolved reference keys, not confirmed runtime text. Record the operation, code, and sanitized actual response together.

WirelessLocalAP: W-model identity and radio parameters

WirelessLocalAP belongs to the integrated local access point of a suitable wireless appliance, not to an AP6’s local web interface or its Central/Fusion management. This contract provides neither a new APX API workflow nor instructions for older AP/UTM devices. The required field Id identifies the existing local AP; Label is an optional label, not a substitute identity. The reference example uses LocalWifi0/LocalWifi1, while the UI help uses LocalWiFi0. Do not silently correct capitalization or send the slash-separated value as a shared ID: confirm the actual individual identity in the read/export result appropriate to the build. Country must match the actual location, not the example In.

The example places network assignments under WirelessNetworks/Network. The table describes Network as an array and warns that duplicate values are not ignored. Therefore, reconcile all existing assignments and do not send an SSID list or guessed network names. The limit of eight assigned Wireless Networks and the hardware limits of the radio bands remain relevant when automating.

For band assignment, the table describes Band with 2.4GHz or 5GHz; for 2.4 GHz, it lists Channel, ChannelWidth, TXPower, DynChan, and TimeBasedScan, while for 5 GHz it lists Channel5GHz, ChannelWidth11a, TXPower5GHz, DynChan5GHz, and TimeBasedScan5GHz. The example shows scan times under ScanTime/Time; the table lists Time twice as a band-dependent array without clearly showing the parent structure for both bands. Confirm the correct parent structure for each band before sending a write request, rather than combining all Time entries or inventing a 5-GHz parent. Radio scan times are not the SSID access schedule.

Several details conflict: the example uses Channel2.4GHz, while the table uses Channel; for DynChan and TimeBasedScan, the example uses Enable, while the value lists contain only t. For TXPower, the example shows 100, while the table lists 10%, 25%, 50%, 75%, 100%. The text describing the band assignment of DynChan is also ambiguous. These forms are not confirmed to be interchangeable values. In addition, the export description for DynChan5GHz distinguishes between Disabled (static channel, dynamic scanning off), 1 (automatic channel without dynamic scanning), and Enabled (automatic channel with dynamic scanning); do not automatically treat export values as valid write inputs.

BridgeToEthernet, BridgeToPort, and Zone concern the local Ethernet bridge, not the client VLAN ID of a network profile. The Gen.1/Gen.2 limits, IPv4/Bridge-to-AP-LAN prerequisites, and DHCP/admin access checks described above still apply. After a confirmed change, check both affected radios, Country, network assignments, the bridge, and an actual client before changing any further APs.

The Status Message Information for the operation Update Local AP assigns these XML status values in both reference versions:

200, 216: Message.WPAPkUpdateSuccessfully; 500, 541, 543, 544, 545: Message.WPAPUpdateFail.
523: Message.WPNetworkGroupMax; 524: Message.WPAccessPointMax; 542: Message.WPAccessPointMesh.
547: Message.WPAPUpdateFailVLANGroup; 548: Message.WPA3IsNotSupported.
561: Message.LegacyModeNotSupported; 564: Message.TKIPModeNotSupported; 565: Message.TopazToNonTopazImportFail.

These are literal, unresolved reference keys, not verified runtime messages. In particular, do not infer a model mapping or permitted import migration from Message.TopazToNonTopazImportFail. If a response is unclear, read back the saved AP identity, radio parameters, and assignments; do not automatically repeat the same update or weaken encryption.

WiFi6Interface: an existing interface, not an SSID or bridge

In the XML references for SFOS 22 and 23, WiFi6Interface manages the port-specific network and zone settings of LocalWiFi6, not an SSID profile or a physical bridge. The required fields are Name, Hardware and Zone: Name is the descriptive label with a maximum of 58 characters; Hardware identifies the hardware name of the existing interface. Before making a change, confirm this identity in the read/export result appropriate to the build; do not infer it from the display name, SSID or WirelessNetworks.HardwareName. The ten-character/A-Za-z0-9_ requirement for the hardware name of a physical bridge is not applied here; the WiFi6Interface table specifies only a string for Hardware. Nor does the API object name establish a mapping to a hardware generation. The model-specific GUI bridge, DHCP and admin access checks described above continue to apply unchanged.

IPv4Address and Netmask are optional in this contract. This establishes neither a requirement to set a new address nor a confirmed effect when existing values are omitted. Before making changes, document the actual port, zone and any existing IP address with its mask; afterwards, read back the state of the same interface and compare it with the intended addressing plan. This interface comparison replaces neither checks of AP assignment and SSID nor an actual client test.

For the operation WiFi6Interface, both source bodies show 200/Message.InterfaceUpdateSuccess, 500/Message.InterfaceUpdateFail and 502/Message.InterfaceIPAlreadyInUsed. These are object-specific XML status values with unresolved reference keys, not HTTP codes or confirmed runtime text. Record the operation, code and sanitised actual response together. If the result is unclear, first read back the hardware identity, port, zone and, where applicable, IP/Netmask rather than automatically repeating the same update or creating another Wireless object. A success code alone proves neither correct network assignment nor working Wi-Fi traffic; no new write request is derived here.

WirelessNetworks: distinguishing hardware identity, profile, and status

For WirelessNetworks, the immutable Hardware name, the editable display name Name, and the broadcast SSID are different values. In the guest example, these are GuestWiFi, Guest WiFi, and Company Guest. The Add/Update parameter table requires HardwareName with a maximum of ten characters; the delete operation also identifies its target using HardwareName, not the SSID or display name. Before deleting, check AP assignments, the interface, DHCP, and rules, and remove only the unambiguously identified, approved target. An error is not a reason to create the profile again under a new name.

However, the Add/Update example uses Hardware instead of HardwareName, and ClientIsolation with Enable instead of the table value Enabled. The same discrepancy exists for HideSSID; the table specifies Enabled/Disabled for each of TimeBasedAccess, ClientIsolation, HideSSID, and FastTransition. Likewise, MACFiltering with Allowlist/Blocklist appears alongside an older MACList description using whitelist/blacklist. Do not resolve any of these discrepancies by guessing. The XML contract also lists older security modes, while the current UI help describes WPA3 only for the W models mentioned above: this does not establish a complete WPA3 write syntax.

The documented traffic tokens SeparateZone, BridgetoAPLAN, and BridgetoVLAN belong to ClientTraffic. IPAddress and Netmask refer to Separate zone; BridgetoVLANid refers to the client VLAN, and ClientVlanId to Static or RadiusAndStatic. Do not confuse these values with the AP management VLAN. Do not reuse the example key, the public example IP, or TKIP(only abg): AES or a demonstrably supported stronger security mode, your own secure passphrase, and controlled network isolation remain the goal. ClientIsolation still does not replace a firewall or VLAN boundary across multiple radios/APs.

For Add Wireless Network, both references list the following mappings:

200: Message.WPNetworkSuccess; 500, 541, 545: Message.WPNetworkFail.
502: Message.WPNetworkExists; 503: Message.WPNetworkInterfaceExists; 542: Message.WPNetworkInterfaceIPExists.
544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.

For Update Wireless Network, several keys differ despite having the same codes:

200: Message.WPNetworkUpdateSuccessfully; 500, 541, 543, 545, 549: Message.WPNetworkUpdateFail.
503: Message.WPNetworkInterfaceExistsForUpdate; 542: Message.WPNetworkInterfaceIPExistsForUpdate.
544: Message.InterfaceIPAssignedToPeerAdminIP; 548: Message.InterfaceReservedName; 560: Message.DHCPIPRangeConfig.
546: Message.WPBindWithLA; 547: Message.APNotSupport5GHzWP.
561: Message.SecModeChangedToLegacyFail; 562: Message.SecModeChangedToWAP3Fail; 563: Message.EncModeChangedToTKIPFail.

For Delete Wireless Network, the documented mappings are 200/Message.WPNetworkDeleteSuccess, 500/Message.WPNetworkDeleteFail, 541/Message.BridgeWirelessNetworkExists, and 542/Message.WPEnableDeteleFail. Even apparent spelling errors such as Message.SecModeChangedToWAP3Fail and Message.WPEnableDeteleFail remain unchanged; they are not renamed to supposedly correct runtime messages. For these responses, first reconcile the actual saved hardware identity, IP, DHCP dependencies, bridge, and AP assignments. Do not claim a cause, a successful rollback, or a safe retry based on a key alone.

WirelessNetworkStatus is a separate object: its table explicitly describes Name as an interface name with a maximum of ten characters, not as an automatic alias for an SSID or display name. Here, Status uses Enable/Disable, not the Enabled/Disabled values used by other fields. Confirm the actual interface name beforehand. For Enable-Disable Wireless Network, the listed mappings are 200/Message.WPNetworkUpdateSuccessfully and 500/Message.WPNetworkUpdateFail. A status change does not assign the network to an AP and does not yet prove that it is being broadcast; check the saved status, AP assignment, and client connection separately.

WirelessGrouping: group membership is not radio configuration

WirelessGrouping describes an AP group with Name and the repeatable entries WirelessNetworks/Network and AccessPoints/AccessPoint. Use the AP identities from the existing inventory, not the reference’s old AP30 example. The group structure configures network assignments and optional AP management tagging, but not band-dependent local radio parameters. Optional arrays do not establish confirmed semantics for empty lists or a safe partial update.

VLANTagging lists Enable/Disable; APVLANID lists 1 through 4094 and applies when tagging is enabled. This is the APs’ management VLAN, not BridgetoVLANid for clients. Before making changes, check the entire member list, trunk, management DHCP, Allowed zone, and rollback path. Disabling a group still stops its APs from broadcasting; after a confirmed change, check every affected AP and the intended SSIDs.

For Add an Access Point Group, the listed mappings are 200, 216/Message.WPGroupSuccess, 500, 541, 543, 545/Message.WPGroupCreated, 502/Message.WPGroupExists, 523/Message.WPGroupMax, 524/Message.WPGroupMaxAP, and 546/Message.WPA3IsNotSupported. For Update an Access Point Group, the mappings are instead 200, 216/Message.WPGroupUpdateSuccessfully, 500, 541, 543, 545/Message.WPGroupUpdateFail, 523/Message.WPGroupMaxForUpdate, 524/Message.WPGroupMaxAPForUpdate, and 546/Message.WPA3IsNotSupported. The confusing key Message.WPGroupCreated associated with error codes is not a guarantee of success. Before retrying, read back the saved group and members rather than creating a second group or adding further APs.

Global settings: management access and downstream effects

WirelessProtectionGlobalSettings is neither an SSID profile nor a client zone. In the example, AllowedZone/Zone contains the repeatable management zones; NotificationTimeout corresponds to the offline notification timeout in minutes explained above. RADIUSServer identifies the globally selected server for the Enterprise path described. For the toggle, the example uses WirelessProtection, while the table uses EnableWirelessProtection: clarify these differing field names for the specific build before sending a write request as well.

For Global Settings, both references list 200/Message.WLANAPEditSuccessful, 500/Message.WLANAPEditFailed, 501/Message.WLANAPIPAlreadyInUsed, and 504/Message.WLANAPIntBaseVHExist. Further distinctions are:

511: Message.WLANAPFailedWhileUnbinding; 512: Message.WLANAPFailedWhileDeleteDHCPServer; 513: Message.WLANAPFailedWhileDeleteDHCPRelay.
516: Message.WLANAPFailedToUnbindInterface; 520: Message.WLANAPFailedToUnbindIfaceRCg; 521: Message.WLANAPEditRunConfigFailed.
523: Message.WLANAPWLAN1UnboundEditFaild; 524: Message.WLANAPOtherUnboundEditFaild.

The keys are not interpreted as proven error causes, but they show why a global change must not be treated as a harmless test: interface bindings and DHCP configuration may be affected. Do not turn Wireless Protection off and back on as a quick diagnostic measure. Before a planned change, capture a backup, independent admin access, interfaces, DHCP servers/relays, and AP assignments. Afterwards, read back the actual saved global state and the affected services, check AP reachability and clients, and only then use this evidence to decide whether to retry or use the confirmed rollback path. An XML success code alone proves neither the effect on wireless operation nor complete configuration success.