Skip to content

Client Isolation & Gateway Allowlisting

Client isolation stops wireless clients talking to each other. It has to be done on the access point, because client-to-client traffic within a VLAN is bridged locally and never reaches the firewall — no rule on the gateway can affect it, as noted in Firewall Rules & Aliases.

Turning it on without an allowlist breaks the network completely, in a way that looks like a DHCP or routing fault. This page covers why, and what to put in the list.

Two Scopes

Ruckus exposes isolation as two separate options per WLAN, and they are not alternatives — the second is a superset of the first:

Option Blocks
Isolate from other clients on the same AP Client-to-client traffic bridged locally within one AP
Isolate from all hosts on the same VLAN/subnet The above, plus traffic to any other host in the subnet — including wired hosts and clients on other APs

The first alone is close to useless in a multi-AP deployment: two clients on different APs are still free to reach each other, because that traffic goes out of the AP to the switch and back. For a public network, use the full option.

Why It Breaks Everything

The full option blocks traffic to every host on the subnet. The default gateway is a host on the subnet. So the client:

  1. Gets a DHCP address (DHCP is handled by the AP's own relay path, so this still works)
  2. ARPs for the gateway
  3. Gets no reply, because the ARP is blocked as client-to-host traffic
  4. Has an address, a gateway it cannot resolve, and no route off the network

The symptom is a client with a valid IP and no connectivity — which reads as a routing or firewall problem, not an AP setting. The fix is to allowlist the gateway so that one destination stays reachable.

The Allowlist

Entries are MAC address plus IP address pairs. In Unleashed the list is defined once under the access-control services and then referenced from the WLAN's isolation setting; the exact menu path moves between releases, so find it by the name rather than the path.

What belongs in it:

Entry Needed when
Default gateway Always — this is the one that breaks everything if missed
DHCP server Only if it is a separate box on the same subnet, not the gateway
DNS resolver Only if it sits on the client subnet rather than being reached through the gateway

Nothing else. Every entry is a hole in the isolation, so an allowlist that has grown to a dozen entries is worth re-reading — see Management Plane Isolation for the same principle applied to admin interfaces.

Some releases offer an automatic allowlist mode where the controller learns the gateway itself. It works, but it hides the dependency: if it learns the wrong host, or fails to relearn after a change, the failure is silent. On a network that matters, set the entry manually so it is written down.

Finding the Gateway MAC

On pfSense — Diagnostics → ARP Table, or the interface's own MAC under Interfaces → Status.

On a Cisco SVI:

Switch# show interface vlan 50
! Look for: Hardware is ..., address is aabb.ccdd.eeff

From a client on the subnet, before isolation is enabled:

arp -a 192.168.50.1

If the gateway is a CARP/VRRP high-availability pair, allowlist the virtual MAC (00:00:5e:00:01:xx), not either physical interface. Clients ARP for the VIP and get the virtual MAC back, so the physical addresses never appear in their traffic — and allowlisting only the current master means a failover silently blackholes every client.

The Change That Breaks It Later

The allowlist is pinned to a MAC address. Anything that changes the gateway's MAC takes the whole WLAN offline with no config change of its own:

  • Replacing the firewall, or swapping a failed unit for a spare
  • Moving the gateway function from one device to another
  • Re-homing the SSID to a different VLAN with a different gateway

None of these produce an error on the AP. Note the dependency wherever the firewall is documented, so the allowlist is checked as part of the swap.

Verifying It Works

From an isolated client, in this order — the first two prove isolation, the second two prove it did not go too far:

Test Expected
Ping another wireless client Fails
Ping a wired host on the same subnet Fails (full isolation only)
Ping the default gateway Succeeds
Browse the internet Succeeds

If tests 1 and 2 succeed, isolation is not in effect — check the scope option rather than the allowlist. If 3 and 4 fail, the gateway is missing from the allowlist or its MAC is wrong.

What It Does Not Do

  • It is not a firewall. Clients still reach the internet and anything the gateway routes them to. Inter-VLAN restriction is still a rule on the firewall.
  • It does not cross the gateway. Traffic that leaves the subnet is out of its scope entirely.
  • It does not stop clients seeing each other's traffic over the air — that is what encryption is for. Isolation stops the AP forwarding frames between clients; it does not stop a client capturing them.