Wi-Fi Access Point Behind a VPN Gateway: Keep One LAN

Wireless clients can sit behind a VPN without the access point knowing anything about the tunnel. Bridge the radio onto the gateway's LAN, let the gateway own addressing and the tunnel, and every device on the Wi-Fi inherits the same policy. The alternative, a second routed segment with its own gateway, is a different design with a different failure mode.

The two get confused because both put a box between the internet and your devices. Comparing what each one owns is the fastest way to choose.

Two Ways to Put the VPN in Front of Wi-Fi

In a bridged layout the access point carries frames between the radio and the wired segment and nothing else: one subnet, one address authority, one router performing the policy. In a routed layout the second box has its own addresses, its own DHCP scope and its own default route, so traffic crosses another boundary before it reaches the tunnel. The bridged design makes every wireless device look local to the gateway, which is why one set of rules covers them all. The routed design gives you a segment to reason about and a second place for policy to go wrong.

internet
  -> vpn-capable gateway: routing, tunnel, dns, failure policy
  -> bridged access point: radio onto the same lan
  -> wifi clients

Choose bridged when the requirement is that wireless devices use the same tunnel as wired ones. Choose routed when you want a segment that can be isolated, or when the second box already exists as a router.

What the Bridged Layout Actually Changes

Bridging removes a translation layer and a competing default gateway, and it adds a management problem. The access point still needs an address you can reach, which the vendor workflow usually arranges through the main LAN. Its DHCP service must be off, or two authorities will hand out conflicting leases. The gateway keeps the tunnel, the resolver settings and the decision about what happens when the tunnel drops, so the policy lives in exactly one place.

The radio inherits none of that automatically from the tunnel. It only stops adding layers that would obscure it.

Where a Second Routed Segment Fits

A routed segment earns its complexity when devices behind it need different treatment from the rest of the LAN. A guest network, a lab, or a set of clients that must always exit through a particular country are all reasons to put a router in the path. The cost is a second address authority, a second firewall to keep consistent, and a return route from the main LAN if anyone there needs to reach the segment. Those are obligations rather than configuration details.

The common mistake is building the routed version by accident, reusing a router that still runs its own DHCP and translation. That produces double translation and a policy nobody can trace.

Test From a Wi-Fi Client, Not the Gateway

A successful request on the gateway proves the tunnel works for the gateway. The real question is whether a wireless client's forwarded traffic uses it, and that has to be observed from the client. The commands below check the client's address, its route, and the address a remote service sees.

ip -4 addr show wlan0
ip route get 1.1.1.1
curl -sS https://api.ipify.org; echo
traceroute -n -m 4 1.1.1.1

An address inside the gateway's LAN confirms the bridge is passing frames rather than translating them. A route whose first hop is the gateway confirms the client has not acquired a second default route from somewhere else. The exit address check answers the actual question, and the short trace shows whether the first hops are the expected ones. If the client's address comes from a different scope, a stray DHCP server is the first suspect.

Write down the role of each box, its address and the DHCP authority. A diagram with three lines is enough, and it settles most arguments about where a rule belongs.