Set up and test Sophos Firewall Wireless Mesh in an existing APX deployment

A Wireless Mesh on Sophos Firewall connects one or more APX Access Points wirelessly to a wired root AP. It can bridge a coverage gap where no Ethernet cabling is available at the remote location. The mesh backhaul isn’t the visible wireless SSID: SFOS creates a hidden WPA2-Personal network for it with a random passphrase. Clients continue to use a separately configured Wireless Network.

⚠️ Important: This guide applies to existing APX installations managed directly by SFOS. APX can only form a mesh with APX. AP6, integrated LocalWiFi, SD-RED Wi-Fi modules, and mixed Sophos AP series aren’t part of this workflow. A mesh also isn’t a substitute for wired redundancy: At least one AP remains connected by LAN, and SFOS doesn’t perform an automatic root change if the root AP fails.

Scope: existing deployments, not a new wireless platform

The following steps describe legacy Firewall-managed mesh for an existing APX deployment, not the setup of a new APX or UTM platform. Before making any changes, confirm support for the specific AP model, its hardware revision, and the SFOS build actually in use. The Wireless help for SFOS 22 and SFOS 23 includes older mesh workflows; the existence of a help page is not proof of hardware support. In particular, it must not be taken to mean that APX can be upgraded to SFOS 23. If support has not been confirmed, retain the existing configuration and first clarify model/build compatibility and migration options.

AP6 mesh uses a different management approach: For a centrally managed AP6 deployment, configuration takes place in Sophos Fusion, formerly Sophos Central, not under Wireless > Mesh networks on the firewall. A Sophos Firewall can still serve as the router and security boundary in the data path, but it does not become the AP6 controller. APX and AP6 must not form part of the same mesh. Registration and network prerequisites for this separate approach are explained in Sophos Central Wireless requirements; detailed planning, mesh configuration, and validation are covered in Plan and set up AP6 mesh. The APX roles, SSID assignments, and rollback steps shown here do not apply to AP6.

The outdoor APX 320X model is outside the scope of this Firewall-managed workflow. References to the older Sophos AP series and manual roles in older guides explain historical installations, not a currently supported new installation. Integrated LocalWiFi and SD-RED Wi-Fi modules are not substitutes for the two external APX devices in the example either; their wireless and model requirements must be checked separately. This article neither updates UTM guides nor recommends them as a path for new deployments.

Quick workflow:

1. First connect both APX devices by LAN, accept them under Wireless > Access points, and check firmware, Country, and the radio plan.
2. Set the same fixed channel on all participating APs for the mesh band and turn off Dyn chan.
3. Configure the mesh ID, Frequency band, and APX devices under Wireless > Mesh networks > Add.
4. Assign the visible client SSID separately to both APX devices.
5. Save the configuration, disconnect the LAN cable from the mesh AP, restart the APX devices, and wait up to five minutes.
6. Check AP status, client connectivity, DHCP, Rule ID, internet access, and the failure of the root path in a controlled test.

When an APX mesh is suitable

A mesh is suitable for an existing APX installation when one remote access point has no Ethernet connection and the radio link to the root AP is stable enough. Typical examples include a small warehouse area, a meeting room, or a temporary area where cabling is planned later.

An Ethernet uplink remains the better technical foundation for sustained high capacity, stable latency, and predictable failover. The mesh backhaul shares radio airtime with other transmissions. Real performance should therefore be measured with the intended clients and applications rather than inferred from link status.

The product boundary also matters for new installations: APX is End-of-Sale and reaches End-of-Life on December 31, 2027. The APX lifecycle and AP6 as its successor should therefore be included in medium-term planning. AP6 isn’t managed through SFOS.

Understand the mesh backhaul, client SSID, and roles

These components serve different purposes:

• Mesh network: Hidden radio backhaul between the APX devices. The mesh ID identifies the group; SFOS manages the random WPA2 passphrase.
• Root AP: APX with an existing Ethernet connection to the firewall. For APX, this role follows automatically from the cabling.
• Mesh AP: APX without an Ethernet uplink that reaches the root AP by radio.
• Wireless Network: Visible client SSID with Security mode, Client traffic, DHCP, and rules. The complete foundation is covered in Set up wireless directly on Sophos Firewall.

With older Sophos AP series, root and mesh roles must be assigned explicitly. This article uses APX only and therefore doesn’t transfer that legacy role screen to the example steps.

Repeater or wireless bridge

In repeater operation, the mesh AP broadcasts the assigned client SSID at the remote location. Endpoints connect over Wi-Fi; the AP transports their traffic over the mesh backhaul to the root AP.

With a wireless bridge, an Ethernet segment is additionally connected to the network port of the mesh AP. This design extends Layer 2 and can create loops if a second cable path exists at the same time. It therefore belongs in a maintenance window with a documented recovery path. STP must match the overall switch and bridge design; it isn’t disabled merely because a path is blocked.

Repeater operation is clearer for most small extensions. A bridge should only be used when the remote Ethernet segment is genuinely required and its broadcast, VLAN, and loop behavior is understood.

Check the limits before configuration

An APX mesh has clear product limits:

• All participating access points must belong to the APX series.
• Only one mesh network can be used per AP.
• At least one APX must remain connected to the firewall by LAN.
• All mesh APs use the same channel on the mesh band.
• Dynamic Channel Selection, or Dyn chan, must not be active on this band because APs may otherwise use different channels after a restart.
• On APX, both radios must not be configured for 5 GHz at the same time when mesh is used.
• APs with an assigned VLAN can only form a mesh if the VLANs don’t use the Bridge to VLAN Client traffic mode.
• A second mesh network on the same AP doesn’t work.
• Failure of the root AP isn’t taken over automatically and without interruption by another mesh AP.

The current Sophos help describes 2.4 GHz for the mesh backhaul and 5 GHz for client SSIDs as a possible starting point. This isn’t a universal best practice. Distance, walls, interference, available channels, the regulatory Country, and required capacity determine the actual design.

Understand the documentation conflict: The older deployment guide specifies 5 GHz on the root AP and 2.4 GHz on the mesh AP; the guide for adding a mesh instead distinguishes 5 GHz for client SSIDs from 2.4 GHz for the mesh backhaul. These descriptions must not lead to different backhaul bands being configured on the root and mesh APs. For the existing-deployment workflow documented here, both APs must use the same selected mesh band and the same fixed channel. The example 2.4 GHz is not mandatory; before using another band, check model/build support and the radio path. The APX restriction against configuring both radios for 5 GHz at the same time still applies.

Plan the example topology

The example uses these names:

• Firewall: fw01
• wired APX: ap-office-root
• wireless APX: ap-warehouse-mesh
• Mesh ID: OfficeMesh
• visible Wireless Network: Company WiFi
• Mesh band: 2.4 GHz
• Mesh channel: a fixed channel tested at the site

OfficeMesh is a documentation example and is replaced with a short, unique name for the local installation. The mesh ID must not be confused with the visible SSID. In the example, Company WiFi already exists with suitable Client traffic, DHCP, firewall rules, and NAT.

Before the change, prepare a current configuration backup, wired management access, and a rollback plan. Both APX devices receive PoE and are tested within range of their final positions for initial configuration. The root AP must remain reachable there by Ethernet.

Prepare the access points and radio channel

Provision both APX devices by LAN first

1. Connect ap-office-root and ap-warehouse-mesh by Ethernet to the intended management network.
2. Under Wireless > Wireless settings, check that Wireless Protection is active and that the management zone is allowed under Allowed zone.
3. Under Wireless > Access points, accept both pending APX devices with Accept.
4. Set the correct Country for both APX devices. After a Country change, save and restart the APX devices in a controlled manner so the channel list is updated.
5. Check that both APX devices are active and have received their current configuration.

The initial wired connection isn’t an optional convenience. An APX that hasn’t received the mesh configuration can’t later be added to the group over radio alone.

Before rollout, the APX firmware level should also be planned through the Sophos Firewall pattern updates. A firmware update and the mesh cutover shouldn’t take place at the same time without control.

Set one common fixed channel

1. Under Wireless > Access points, open the first APX.
2. Under Advanced settings, set a fixed, locally tested channel in the applicable Channel 2.4 GHz or Channel 5 GHz field.
3. Turn off Dyn chan for this band.
4. Apply the same setting to the second APX.
5. Where possible, place nearby APs that aren’t part of the mesh on a different low-interference channel.

A channel isn’t selected merely because it works well in the example. A local scan, Country requirements, and neighboring channel use determine the choice. After every channel change, both mesh APs must show the same value again.

Create the Wireless Mesh in SFOS

Create the mesh network

Create a new, dedicated mesh network or mesh SSID for the mesh backhaul; do not convert the existing visible client SSID Company WiFi into a mesh network. The help uses both mesh ID and mesh-enabled SSID for this purpose. If the existing interface offers Enable mesh mode only when creating a new SSID, use this documented legacy workflow only on a confirmed supported model and build, and keep the client SSID separate. Only one mesh network is supported per AP. All participating APs must receive the same mesh ID; they share the WPA2-Personal passphrase randomly generated by SFOS. This is not the client wireless network’s passphrase.

1. Open Wireless > Mesh networks.
2. Select Add.
3. Enter OfficeMesh as the Mesh-ID.
4. Under Frequency band, select the planned common band, 2.4 GHz in the example.
5. Add ap-office-root and ap-warehouse-mesh.
6. Save.

With APX, no role needs to be assigned manually in this workflow. While both APX devices are still wired, they first receive the configuration. After ap-warehouse-mesh is disconnected later, ap-office-root remains the root AP because of its Ethernet connection.

Assign the visible client SSID

The mesh network isn’t visible to endpoints. Under Wireless > Access points, or through a suitable access point group, assign Company WiFi to both APX devices as well.

The client SSID retains its own Security mode and Client traffic. For Separate zone, the Wireless interface, DHCP, firewall rule, NAT, and Device Access must be correct in particular. A working mesh doesn’t correct a missing wireless rule or an incorrect DHCP path.

Move the mesh AP to its destination

1. Check that the configuration and visible client SSID have reached both APX devices.
2. Remove the Ethernet cable only from ap-warehouse-mesh.
3. Leave ap-office-root wired.
4. Place the mesh AP at the intended location and turn it on; it now starts without Ethernet.
5. Restart the root AP in a controlled manner. If moving the mesh AP didn’t power-cycle it, restart it now as well.
6. Wait up to five minutes before treating the connection as failed.

Only one APX remains connected by LAN during normal mesh operation. If the second APX is accidentally connected to the same Layer 2 network as well, check the design for loops and the effect of STP.

Validate the Wireless Mesh in a controlled manner

Validation combines controller status, the radio path, and real user traffic:

1. Under Wireless > Access points, both APX devices must be active. ap-office-root remains wired; ap-warehouse-mesh is reachable without Ethernet.
2. Check the mesh assignment and identical channel on both APX devices.
3. Connect a test client near ap-warehouse-mesh to Company WiFi.
4. Under Wireless > Wireless client list, display the test client by AP or SSID and verify that it is associated with the expected mesh AP and Company WiFi. Record the signal strength and frequency, and check them again under similar conditions when comparing with the root AP; a displayed client frequency alone does not prove which band the backhaul uses.
5. Compare the client’s IP address, gateway, and DNS with the planned Wireless Network.
6. Test one allowed destination and one deliberately blocked destination.
7. In Log Viewer, filter by the client IP and check the expected Firewall Rule ID and NAT Rule ID.
8. Run a realistic throughput and latency test and compare it with a client at the root AP.

A green AP status doesn’t yet confirm the complete data path. Success means the client uses the correct AP, address, and intended rules, and that performance is sufficient for the application. The general procedure is described in Test firewall rules reliably.

Test the failure boundary deliberately

The root AP is a known dependency. During a maintenance window, briefly disconnect the root uplink and document how long client access is interrupted. SFOS doesn’t promise an automatic root change. A mesh AP may need to be restarted and wired for a new role to be established.

This test isn’t a reason to turn off a production root AP without planning. For critical areas, use a wired AP uplink or plan another wireless architecture.

Safely contextualise the mesh object in the XML API

The XML references for SFOS 22 and 23 describe Add Mesh Networks and Update Mesh Networks for the WirelessMeshNetworks object. This is a documented object structure, not approval for additional hardware: the scope of existing APX devices, the model/build check and the separate AP6 management path above remain unchanged. Access protection, explicit operations, XML responses and safe retries are explained in Securing Sophos Firewall XML API access.

Distinguish MeshID, band and AP role

When preparing automation, distinguish between these fields:

• MeshID is a mandatory scalar string with a maximum of ten characters. OfficeMesh is suitable as a short example name; it remains the backhaul ID, not the visible client SSID. Do not interpret the additional reference marker APINTERFACENAME as a self-explanatory character rule or as an AP identity; confirm the permitted format in the installed build.
• FrequencyBand is mandatory and permits exactly 5GHz or 2.4GHz. The table lists 5 GHz as the documented default, not as a recommendation for every radio path. The combined notation 5GHz/2.4GHz in the reference example is not in the list of permitted values and is not adopted as a single field value. All participating APs still require the same confirmed backhaul band and the same fixed channel; Dyn chan remains disabled on this band.
• Description is an optional scalar string. An empty element in the example does not establish how an update handles an existing description.
• In the XML example, AccessPoints contains MeshNetwork, within which AccessPoint and Role appear together. The parameter table describes both fields as optional arrays with multiple values and notes that duplicates are not ignored. Do not infer either two lists that can be sorted independently at will or automatic deduplication from this. Check the AP identity and its associated role together against the existing configuration and the build’s API help.
• Exactly MeshAccessPoint and RootAccessPoint are documented for Role; the table lists Root Access Point as the default. These XML values come from the API reference, not from the GUI terms Root, Mesh or Repeater. In particular, automatic Ethernet-based APX role assignment is not evidence of whether Role must be set, omitted or handled differently in the specific APX payload. Do not send a write request while the model/build mapping remains unresolved.

The following limited XML structure excerpt is not an executable request and does not assign an APX role. It shows only the documented nesting with a reference value for Role; AP_IDENTITAET_AUS_API_HELP is a placeholder that must not be sent. The AP30 identity in the manufacturer’s example is not adopted as an APX example:

<WirelessMeshNetworks>
  <MeshID>OfficeMesh</MeshID>
  <FrequencyBand>2.4GHz</FrequencyBand>
  <Description />
  <AccessPoints>
    <MeshNetwork>
      <AccessPoint>AP_IDENTITAET_AUS_API_HELP</AccessPoint>
      <Role>RootAccessPoint</Role>
    </MeshNetwork>
  </AccessPoints>
</WirelessMeshNetworks>

Before making a change, read back and back up the mesh configuration actually stored, including its mesh ID, AP identities, assignments and radio parameters, and compare it with the planned target state. The excerpt contains neither a login nor an operation and is no substitute for a confirmed complete payload. Neither a safe retry nor a functioning radio connection follows from the XML structure; separate acceptance checks for AP status, client SSID, DHCP and the data traffic path remain necessary.

Distinguish responses by operation, code and symbol

The references assign the following XML status codes and literal Message.* keys to the two operations. The keys are unresolved: they are not confirmed runtime messages and are not translated into supposed error message text. The object-specific mapping must be checked against the installed build’s API help; in particular, do not interpret 521 and 522 here solely on the basis of the general status table in the central API article.

Add Mesh Networks:

• 200: Message.WLANAPAddSuccessful.
• 500: Message.WLANAPAddFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 521: Message.WLANAPAddRunConfigFailed.
• 522: Message.WLANAccessPointUnbound.

Update Mesh Networks:

• 200: Message.WLANAPEditSuccessful.
• 500: Message.WLANAPEditFailed.
• 501: Message.WLANAPIPAlreadyInUsed.
• 504: Message.WLANAPIntBaseVHExist.
• 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 spelling Faild is also preserved exactly. Do not infer a proven cause, a complete rollback of a change or an already deleted DHCP/interface dependency from symbol names. After an unclear or failed response, first compare the mesh and AP state actually stored, along with dependent wireless, interface and DHCP configurations, against the backed-up initial state; retain the sanitised response and logs for investigation. Only decide on a further change after build-specific clarification, rather than automatically repeating the same Add or Update. Even 200 is no substitute for reading back the target object or for the radio and client acceptance checks above.

Troubleshoot by symptom

Mesh AP doesn’t appear or remains offline

After configuration, wait up to five minutes. If the AP remains offline, first check whether it was active during initial provisioning by LAN and received the mesh configuration. Then check the APX series, mesh assignment, band, common channel, Dyn chan, Country, and power supply.

The root AP must remain wired. If both APs are wireless or the wrong AP was disconnected from Ethernet, the path to the firewall is missing. After a correction, restart the APX devices in a controlled manner and wait again.

If an existing SSID in a legacy workflow doesn’t show Enable mesh mode, create a new SSID instead of repurposing the visible client SSID. If the cause remains unclear, use a maintenance window to isolate the path by broadcasting only the mesh network on the root AP and only the visible client SSID on the repeater. If the client SSID appears on the repeater, this initially indicates that the client configuration is being broadcast, but does not yet fully prove that the backhaul or internet access works. Also verify that the repeater is actually reachable without a LAN uplink, that the test client appears under this AP in the client list, and that the expected DHCP path and permitted data path work. Restore the normal assignments afterwards. If the mesh remains unusable, check whether STP blocks the mesh configuration. Don’t disable STP indiscriminately: It prevents loops in bridge topologies.

Client SSID isn’t visible

The mesh ID is deliberately not broadcast as a client SSID. Under Wireless > Access points, an additional visible Wireless Network must be assigned to the mesh AP. If only OfficeMesh is configured, endpoints have no visible network.

Also check the client SSID’s Frequency band, schedule, Security mode, and AP assignment. A second mesh network on the same AP isn’t a solution because only one mesh is supported per AP.

Client connects but doesn’t receive an IP address

The radio path is then already working at least partially. Next, check Client traffic, the Wireless interface, DHCP server or DHCP relay, and possible VLAN paths. With Bridge to VLAN, also consider the mesh product limit: APs with assigned VLANs can only form a mesh if the VLANs don’t use this Client traffic mode.

Restarting the wireless service isn’t a standard step. First establish which AP the client uses and whether DHCP requests reach the expected path.

Client has an IP address but no internet access

In Log Viewer, first look for the expected Firewall Rule ID and NAT Rule ID. If both are missing, the problem is more likely related to the zone, network object, rule order, or data path than to the mesh itself. If the rules match, check DNS, gateway, and the WAN path next.

A broad Any rule isn’t a mesh diagnostic. Run the same client test once at the root AP and once at the mesh AP. If it only works at the root, continue investigating the backhaul; if it fails at both APs, the fault probably belongs to the common wireless or firewall configuration.

Connection is unstable or slow

Check the same channel on all mesh APs, disabled Dyn chan, signal quality, interference, distance, and walls. APs that aren’t part of the mesh shouldn’t occupy the same channel unnecessarily. There must also be enough radio capacity left for the backhaul and clients.

Compare performance with the same application, the same client, and conditions as similar as possible at the root and mesh APs. This separates the mesh path from a general WAN, DNS, or client problem.

Controller or client status remains unclear

The Sophos Firewall service logs help with node-local diagnostics. These read-only checks are useful in the Advanced Shell:

tail -n 200 /log/awed.log
tail -n 200 /log/wc_remote.log

awed.log shows controller and APX communication; wc_remote.log helps with wireless clients. A single log entry doesn’t prove the user traffic path. Timestamps, AP status, client list, firewall logs, and a reproducible test belong together. The LED and blink codes of Sophos Access Points also help classify boot, update, and mesh states on the device.

Roll back the mesh safely

Distinguish the mesh SSID from the client SSID during rollback: The older help describes disabling mesh by deleting the mesh SSID. This refers to the associated mesh configuration object, not simply to the visible client SSID Company WiFi. Before deleting anything, cross-check the mesh ID, AP assignments, and dependencies, back up the current configuration, and make the APs reachable over the intended wired path. Removing the backhaul disconnects wirelessly connected APs; deleting a client SSID that is still needed would also disconnect its wireless users. Depending on the legacy interface, rollback is performed through the mesh network or its mesh SSID. If the mapping is unclear, do not delete anything on an assumption; first clarify the specific model/build configuration.

A rollback is performed in a controlled manner while wired management access works:

1. Document which APX is the root and which one is the mesh AP.
2. Reconnect the mesh AP by LAN to the management network and wait until it’s active.
3. If necessary, move the visible client SSID to a remaining wired AP.
4. Remove the mesh network from the APX devices or delete it under Wireless > Mesh networks.
5. Restore previous channel and Dyn chan settings only deliberately.
6. Restart both APX devices in a controlled manner.
7. Recheck the client IP, DNS, rules, and internet access.

A factory reset only makes sense if the APX no longer accepts a managed configuration despite correct cabling, power, and controller path. It isn’t a substitute for a documented rollback.

Operations checklist

• All participating devices are compatible APX models and were first provisioned by LAN.
• Exactly one mesh network is assigned per AP.
• One APX remains permanently wired as the root.
• The mesh band and fixed channel match on all participating APX devices.
• Dyn chan is turned off on the mesh band.
• The visible client SSID is assigned separately.
• DHCP, Firewall Rule ID, NAT Rule ID, and a blocked destination have been tested.
• Performance and stability have been compared at the root and mesh APs.
• Root failure, the lack of automatic takeover, and rollback are documented.
• APX End-of-Life and a later wireless platform change are planned.

FAQ