Skip to content
Avanet

Harden Sophos AP6 against AirSnitch: plan client isolation correctly

Central Wireless

The AirSnitch vulnerability tracked as sophos-sa-20260421-airsnitch applies to every AP6 version currently classified as affected. Actual exposure depends on the SSID design, configuration, attack variant, and upstream network. Three injection-oriented paths matter for AP6: GTK Abuse, Broadcast Reflection, and Gateway Bouncing. AirSnitch alone cannot produce a full man-in-the-middle outcome on AP6.

⚠️ No complete fix: There is currently no complete mitigation, remediation, or fixed version for this class of attacks. The measures below reduce risk but don’t eliminate it. Immediately before each rollout wave, check the current AP6 version and remediation status. If the status has changed, stop the rollout and reassess the safeguards, pilot, and rollback plan.

Quick path: First record the exact baseline. On one pilot SSID, check or enable Client isolation and Proxy ARP under My Products > Wireless > SSIDs > SSID name > Advanced Settings. Put trusted and untrusted devices on separate SSIDs and VLANs, block client-to-client traffic at the gateway including possible hairpin paths, and pilot supported anti-spoofing controls only after validating the topology. WPA2/WPA3 Enterprise and 802.11w add hardening but aren’t complete AirSnitch solutions.

Why Client isolation isn’t enough

The Central option Client isolation blocks communication between wireless devices connected to the same access point. Devices on the same subnet can still communicate when connected to different access points. This ordinary local Layer 2 boundary must be distinguished from a routed or reflected path.

With Gateway Bouncing, the gap between Layer 2 and Layer 3 is central: a crafted frame is sent towards the upstream gateway and routed back to the victim. Blocking direct forwarding at the AP alone doesn’t automatically cover this Layer 3 or hairpin path. A green Central status also proves neither gateway policy nor isolation across APs.

Proxy ARP allows the AP to answer ARP requests intended for connected wireless devices. It reduces broadcast exposure and is therefore an important AirSnitch workaround. It doesn’t replace client isolation, VLAN separation, firewall policy, or return-path validation.

Capture the exact baseline before the pilot

Before the first Save, record at least the following for each affected SSID, preferably with an export or dated screenshots:

  • SSID name, Enable SSID, assigned AP6 units, and enabled frequency bands;
  • encryption mode, RADIUS selection, and relevant authentication values without recording secrets;
  • current state of Client isolation, Proxy ARP, and 802.11w;
  • Client connection mode and static or RADIUS-delivered VLAN IDs;
  • AP uplink, allowed VLANs, client subnet, gateway, DHCP, DNS, and existing gateway/firewall rules;
  • DHCP Snooping, IP Source Guard, or uRPF settings, including ports, trust roles, and exceptions;
  • two known test clients, the pilot AP, a second AP, and currently working allowed and blocked flows.

These values are the rollback baseline. “Restore the previous settings” is safe only when the previous checkboxes, assignments, VLANs, and rules are known. Because Save updates all APs assigned to an SSID and can briefly disconnect clients, limit the first change to a test SSID or one pilot AP.

Harden the AP6 SSID in layers

1. Enable Client isolation and Proxy ARP

Go to My Products > Wireless > SSIDs, select the pilot SSID, and open Advanced Settings. Under Security, turn on Client isolation. Then turn on Proxy ARP under Quality of service, initially saving only for the planned pilot scope.

Client isolation protects the direct path between clients on the same AP. Proxy ARP reduces ARP broadcasts by answering for connected wireless devices. They complement each other, but don’t fully close the cross-AP path, every broadcast or multicast variant, or the path through an upstream gateway.

Before wider rollout, test applications that need local discovery, such as printers, casting, or other discovery services. If a required function breaks, don’t remove all hardening by default or create a direct peer exception. Move controlled discovery or inter-client access into a separately designed policy or discovery gateway with tightly scoped rules.

2. Separate trust zones with SSIDs and VLANs

Untrusted, BYOD, IoT, and managed internal devices shouldn’t share one flat client network. Use separate SSIDs and VLANs with distinct security policies, and avoid mixing trusted and untrusted clients on the same SSID and, where feasible, on the same AP.

Central only tags client traffic with the selected VLAN ID; the switch, gateway, DHCP, DNS, and policies must exist outside Central. Configure an AP6 SSID with a VLAN covers the full setup. A VLAN ID by itself isn’t a security boundary: the gateway or firewall policy determines which zones and destinations are reachable.

3. Block Layer 3 and hairpin paths at the gateway

At the gateway or firewall, block client-to-client traffic at Layer 3 as tightly as possible, including traffic the gateway would route back into the same client subnet. Allow only specifically required destinations and services. Logging on the pilot rule helps prove whether test traffic actually takes that path.

This distinction matters: depending on the switching and wireless path, devices in the same VLAN may communicate directly without traversing the gateway. A firewall rule can only block traffic that reaches the firewall. If cross-AP traffic is bridged locally, the design must use suitable wireless, switch, or VLAN segmentation to force it through the controlled policy boundary. A nominal “client-to-client deny” rule without a proven data path isn’t a success criterion.

4. Apply upstream anti-spoofing only where it fits

Additional safeguards include DHCP Snooping, IP Source Guard, and gateway source validation such as uRPF where supported by the switch or gateway. These controls depend on the environment: trusted uplinks, DHCP servers, static clients, relays, asymmetric routing, and redundancy all affect safe configuration.

Don’t enable them blindly on every port. First document bindings and legitimate paths, then test one control on the pilot segment. DHCP renewal, static devices, gateway failover, and return paths must continue to work. If there is no verified vendor configuration for the deployed switch or router, leave this item open and resolve it through that vendor’s documentation or support.

5. Put Enterprise and 802.11w in context

With WPA2-Personal, WPA3-Personal, or mixed personal modes, the Group Temporal Key shared by clients of the same SSID can be abused for GTK Abuse. Avanet therefore recommends WPA2/WPA3 Enterprise (802.1X) with external RADIUS instead of shared-key authentication. This improves access control and reduces unauthorized access, but doesn’t eliminate GTK-based attack vectors. Pilot migration and client compatibility separately with RADIUS and WPA3 Enterprise for AP6.

802.11w is available only for AP6 SSIDs and protects management frames after a secure connection is established by encrypting and authenticating them. Enable it as additional hardening after client compatibility testing. It isn’t data-plane isolation or AirSnitch remediation and must not count as a passed AirSnitch gate.

Validate in two phases before wider rollout

The pilot validates the real data path, not just checkboxes. Keep the acceptance criteria tied to the current phase:

Phase 1: one pilot AP and same-AP validation

  1. Configuration: Central shows the expected Client isolation, Proxy ARP, VLAN, and optional 802.11w values. Only the intended pilot AP is assigned.
  2. Approved infrastructure: Both test clients receive the intended IP settings, resolve DNS, and reach only approved infrastructure and external services. Test these destinations separately from peer-to-peer tests.
  3. Same AP: Connect both clients to the pilot AP. With Client isolation enabled, all direct client-to-client communication must fail, regardless of protocol or service; a direct peer service isn’t an allowed exception.
  4. Operations and discovery: Test DHCP renewal and required printing, casting, or discovery workflows. Any required controlled discovery or inter-client access must traverse a separately designed policy or discovery gateway, not direct peer forwarding. Attribute unexpected failures to the changed layer before making another change.

Phase 2: one controlled second AP and cross-AP validation

  1. Controlled expansion: Only after Phase 1 passes, assign exactly one controlled second AP. Central must now show exactly those two APs with the expected configuration; don’t add the broader AP population yet.
  2. Different APs: Connect one client to each AP in the same client subnet and repeat the client-to-client deny tests. Don’t substitute expectations from Client isolation for this cross-AP test.
  3. Layer 3 and hairpin: Use gateway logs or a packet capture to prove whether each test path crosses the policy boundary and hits the intended deny rule, including a path routed back into the client network. Don’t deliberately reproduce an exploit on a production WLAN.
  4. Repeat and release: Reconnect, test at least one other client type, repeat approved-infrastructure checks, and verify both APs’ configuration status. Only after both phases pass should you roll out in small waves.

These two phases only show that the defined controls and normal data paths work as intended in this environment. They do not prove complete remediation of AirSnitch.

Roll back exactly to the baseline

If a test fails, stop the rollout and don’t change the SSID, VLAN, gateway, and switch simultaneously. First remove additional AP assignments or restrict the SSID back to the pilot scope. Then restore the documented baseline for each changed layer:

  1. Central: Restore the original Client isolation, Proxy ARP, and 802.11w states, client connection mode, VLAN, bands, and AP assignments.
  2. Gateway/firewall: Remove only new pilot rules, or restore the captured rule positions, sources, destinations, services, actions, and logging values.
  3. Switch/gateway protection: Revert only the pilot changes to DHCP Snooping, IP Source Guard, or uRPF, including the former trust and exception assignments.
  4. Verification: Wait for Central configuration status, then retest DHCP, DNS, allowed services, blocked destinations, and existing SSIDs with the known clients.

Don’t delete a production SSID, VLAN, or existing rule as the first recovery step. If the baseline is unclear, stop and resolve it with the network owners or Sophos Support instead of creating an unknown state through further changes. The AirSnitch risk remains after rollback: rollback restores service, but it doesn’t fix the vulnerability.