Sophos AP6 offline: troubleshoot provisioning, performance, and roaming

Two independent layers can fail on an AP6: The management plane connects the access point to Sophos Fusion (formerly Sophos Central) and carries status and configuration. The client data path runs from the wireless client through the AP6, switch, and VLAN to DHCP, DNS, the gateway, and permitted destinations. A green Central status does not prove the data path, and a client issue does not prove that the cloud connection has failed.

Quick path: For Offline, check power, link, DHCP, DNS, time, and internet/Central reachability first. For Pending, do not stack more changes: record AP status and time, stabilize connectivity, and then watch whether the task progresses. If the AP is online and the SSID is visible, check client IP settings, VLAN, DHCP, DNS, and rules separately. For performance or roaming issues, use a reproducible test and make exactly one change at a time.

Before starting, review the AP6 network requirements and onboarding workflow. Manage AP6 locally or with Central explains the two management modes.

Preserve evidence and limit risk first

Record the AP name, serial number, model, site, switch port, PoE source, management IP, Config status, last activity, firmware, assigned profile, and SSIDs. Also record when the symptom began, affected clients, and the last change. Passwords, full log archives, and customer data do not belong in unprotected tickets.

Do not change VLANs, profiles, and radio parameters together, and do not begin with a factory reset. Use one pilot AP and a known test client. A reset destroys diagnostic context and is not a useful first test.

Symptom 1: AP6 is Offline in Central

For AP6, Offline means the access point can’t communicate with Sophos Fusion. Check in this order:

Power and link: Verify the PoE class, switch port, and link. Insufficient power can turn off the radios; Central and the local UI show a warning. The required PoE class depends on the AP6 model.
Local addressing: Check the lease, management VLAN, gateway, and DNS. If the local UI is also unreachable, Sophos lists missing DHCP, insufficient power, and STP enabled on the uplink as possible causes.
Central path: The network and domain requirements must be met; Sophos specifies outbound ports 443 (HTTPS), 80 (HTTP), and 123 (NTP).
Time: Open Management > Date and time locally and correct an inaccurate AP clock.
Observe again: Once the AP is online, wait for its configuration status before testing the client path.

When the AP remains offline, Central packet capture, syslog, and new system-log collection can’t be started: these features require an online or green AP. Collect switch, DHCP, DNS, and gateway evidence outside the AP and escalate with the timestamp and serial number.

Symptom 2: Registration times out or provisioning remains Pending

If AP did not connect to cloud within the timeout appears, the AP didn’t reach Central during the displayed registration window. Check the same Central path, required ports, and AP clock before registering again.

For Pending, separate state from effect:

If the AP is also offline, restore the management connection first. Client testing can’t explain a task that has no reachable AP.
If the AP is online, record the task, timestamp, and last configuration change. Do not submit a second profile, SSID, or radio change.
Then check whether status and the intended configuration progress. Only after that should you connect a test client and validate the data path.
If the state remains reproducibly stuck, collect system logs while the AP is green and open a support case rather than repeating resets and registration attempts.

For SSID and VLAN changes, use the AP6 SSID and VLAN pilot workflow. This keeps provisioning failures separate from downstream client-network failures.

Symptom 3: AP is online, but clients have no connectivity

Check the data path from the inside out:

Is the expected SSID visible, and does wireless authentication succeed?
Which IP address, mask, gateway, and DNS values does the test client receive?
Is the intended VLAN allowed on the AP port and every uplink?
Can the client reach DHCP, then the gateway and DNS, and finally exactly the permitted destinations?
Does the same test work on an unchanged reference SSID or a second AP?

Change only the first stage proven to be faulty. An online Central status confirms management reachability, not DHCP, DNS, VLAN, or firewall rules in the client path.

Choose the diagnostic tool for the question

Under My Products > Wireless > Diagnostics, Central provides Events, Audit logs, Packet capture, Syslog, System logs, and Support settings.

System logs: Central can collect complete AP6 device logging and provide a .GZ download. Collect logs is available only when status is green.
Packet capture: Central capture for AP6 records received packets on the wired LAN ports and is available only with green status. Use the local AP UI for a WLAN capture. Start shortly before the reproducible test, note the client and time, and stop afterward.
Syslog: Central configures syslog only for APs shown online. The server must be reachable and answer ICMP, or the AP sends no UDP packets. UDP 514 is the default; Sophos recommends no more than two APs per syslog server to keep debugging separate.
Support settings: Enable Remote Login only for an appropriate window. Available periods are 5 hours, 1, 7, 14, or 30 days; turning it off immediately revokes Sophos Support access.

Document the beginning and end of every capture. For detailed configuration, interpretation, and safe shutdown, follow the AP6 diagnostics runbook for logs and packet captures. Captures and logs can contain sensitive network data and should be removed after the support case according to your retention policy.

Symptom 4: Poor performance, VoIP, or roaming

First define a reproducible test: record client type, SSID, start and destination AP, route, time, application, and result. Measure at the same points and change only one parameter at a time. In parallel, check whether the issue also occurs on the wired path or only on one AP, band, or client.

For poor or dropped VoIP calls, Sophos specifies three AP6 checks in Central:

Set Guard interval in the assigned access point profile to Normal GI (0.8 µs) or longer.
Set Sip station idle timeout to 300 or more.
Turn off Airtime fairness for APs carrying VoIP traffic because it can cause delay, jitter, and disconnections.

Guard interval and Sip station idle timeout are profile-scoped. Before changing either value, verify that the assigned profile contains only the pilot AP; otherwise create and assign a dedicated pilot-only profile. These three changes are VoIP-specific and should not be deployed together. Record each previous value, repeat the same call and walking route after one change, and restore the previous value if results worsen.

For a roaming issue, mark the exact location and time of the interruption and compare at least two runs. Check whether connectivity fails only during the transition between APs or also while stationary. Handle a pure Central Offline or Pending issue on the management plane; investigate a reproducible client interruption with client data, AP logs, and a time-limited capture. This avoids changing a radio setting when DHCP, DNS, or the wired uplink is actually failing.

Validation and safe return path

A fix is confirmed only when the AP remains online, no relevant task remains stuck, and a test client repeatedly completes wireless authentication, receives the intended IP settings, and reaches the gateway, DNS, and permitted destinations. For performance and roaming, document the same test route before and after exactly one change.

If the pilot fails, restore only the last changed profile, SSID, or radio value to the recorded baseline. Wait for Central status and repeat the same check. Stop packet capture and syslog collection, and turn off Remote Login immediately when Sophos Support no longer needs it. Reset, re-registration, and simultaneous network changes remain escalation steps, not the first return path.