Wi-Fi Client Isolation vs VPN Local Access: Which Blocks You

Put two phones on the same guest SSID and neither can see the other, yet both reach the internet. Add a VPN client on one of them and the printer three metres away stays invisible while a server on another continent answers pings. Nothing is broken in the tunnel; two separate access decisions are involved, and only one of them is about routing. The access point decides whether wireless clients may talk to each other, and the VPN client decides which destinations leave through the tunnel. Confusing those two produces hours of pointless configuration changes.

The two gates are independent

Client isolation is a switching decision. The access point accepts a frame from one associated station, looks at the destination, notices that the destination is another station on the same bridge, and drops it. The station's IP address is irrelevant to that decision, and so is the VPN.

Routing is a different decision made on the client. The VPN's route table decides whether a packet for 192.168.1.50 enters the tunnel or leaves through the Wi-Fi interface. If the packet leaves through Wi-Fi and the access point isolates clients, it dies at the AP. If the packet enters the tunnel, the AP never sees the original destination and cannot isolate anything.

What isolation blocks on a typical access point

Vendors ship this under several names: client isolation, AP isolation, station isolation, or a guest network that implies it. In OpenWrt the per-interface option is isolate inside the wireless configuration, as described in the wireless documentation, and a guest SSID usually gets its own bridge and firewall zone. The effect is that unicast frames between clients are not bridged, so a ping, an SMB connection or a print job to a neighbour fails even though both devices show full signal.

Discovery protocols suffer first and most visibly. mDNS for printers and media devices rides multicast to 224.0.0.251, SSDP uses 239.255.255.250, and whether those frames cross the bridge depends on the vendor and on whether multicast-to-unicast conversion is enabled. A device missing from a list is weaker evidence than a failed direct connection to a known address.

What the VPN changes, and what it cannot change

A full tunnel takes the default route, so local subnets are reached only if the client keeps a more specific route for them. Split tunnels do the opposite and preserve local access by design. Neither setting can make an isolating AP forward a frame between two of its clients, which is why allowing local traffic in the VPN client is necessary but not sufficient.

The reverse case is just as common. The AP allows peer traffic, the VPN client excludes the local subnet from the tunnel, and the printer still does not answer because the host firewall treats the Wi-Fi network as public. Three layers, three different defaults, and only the route is visible in most VPN logs.

Work out which gate is closed

Start with a test that removes the VPN from the picture: connect two ordinary devices to the same SSID and try to reach one from the other by address. If that fails, the AP is isolating and no VPN setting will fix it. If it succeeds, move to the client and run ip route get 192.168.1.50 on Linux or Find-NetRoute -RemoteIPAddress 192.168.1.50 on Windows; the output names the interface the packet will use.

When the route points at the Wi-Fi interface, the packet leaves unencrypted and the question becomes whether the AP and the host firewall permit it. When the route points at the tunnel, the destination is being sent to the VPN server, which is wrong for a device on the same LAN and usually means the tunnel's allowed list is too broad.

A direct connection to the printer's port is a better test than a discovery list. nc -vz 192.168.1.50 9100 on Linux or Test-NetConnection 192.168.1.50 -Port 9100 in PowerShell tells you whether the address is reachable at all, before any application-level pairing enters the discussion.

Choose the fix for the network you are on

On a hotel or guest network, isolation is deliberate and you should not try to defeat it. Treat the local device as unreachable, use the VPN to reach a host that can print or share, and stop treating the SSID as a LAN.

At home, disabling isolation on the main SSID is reasonable when the devices are yours, while the guest SSID stays isolated. The setting lives in the AP's wireless configuration, and it belongs there rather than in firewall exceptions on every client.

In an office, assume the AP, the VLAN and the host firewall are all intentional. Escalate with the test results rather than asking for isolation to be turned off, because a network that separates clients is usually protecting something.

Verify the application, not just the ping

A successful ping proves the path, not the service. Printers often accept raw 9100 or IPP on 631 but refuse discovery, and a file share needs 445 plus working name resolution. Confirm the port the application uses, then retry the actual task on the device.

Keep the two layers separate in your notes: what the Wi-Fi network permits, and what the VPN routes. The next time a device disappears from a list, that split tells you where to look first.