Run the VPN on the Host or Inside the VM? Decision Runbook

Building the tunnel inside the guest and building it on the host both change the address a browser reports, and that is where the resemblance ends. A guest-owned tunnel keeps its keys, its default route and its resolver inside the guest kernel, while the host forwards encrypted packets to one remote address. A host-owned tunnel is the mirror image: the host client holds the session and applies routes and policy, and the guest borrows whatever comes out. Choose the wrong owner and every later symptom sends you to the wrong machine. Two commands settle the question in about a minute, and the rest of this runbook is what to do with the answer.

Decide the owner before you touch the client

The rule is about where the ciphertext is produced, not about which machine shows a VPN icon. If the guest produces it, the guest needs a working route to the VPN server and nothing else from the host. If the host produces it, the guest needs the host path to survive whatever policy the host client imposes on local traffic.

Three questions usually pick the placement for you. Does the guest's traffic have to survive a corporate client on the host? Then the tunnel belongs in the guest. Do several guests need one credential and one exit address? Then it belongs on the host, with forwarding configured on purpose. Is the guest's traffic supposed to stay off the host's VPN entirely? Then a guest tunnel is the only arrangement that gives you that by construction.

Write the answer down as one line next to the VM name: guest-owned or host-owned. In a lab of six machines that note saves more time than any step below, because it stops you from troubleshooting a tunnel that was never in the machine you are logged into.

WSL1 and WSL2 are opposite cases

WSL1 is not a virtual machine, so the placement question mostly evaporates. Its Linux binaries run against the Windows network stack through a translation layer, and a Linux VPN client has no independent interfaces to configure. The arrangement that works is a Windows-side tunnel, with the distribution using the result without owning anything.

WSL2 is the reverse. It runs a real kernel in a lightweight utility VM behind a Hyper-V virtual switch, and its address space is NAT'd through a host-side adapter. A Linux client inside the distribution therefore behaves like it would on a physical Linux box: it creates tun0 or wg0, installs its own routes, and works. The failure lives on the host side. When a Windows VPN client connects with a policy that blocks traffic on local networks, it treats the WSL2 subnet as an untrusted local network and cuts the NAT path. The distribution then loses DNS and outbound access while its own tunnel is still healthy: wg show reports a handshake, ip route looks correct, and curl hangs.

Which fix you can use depends on the Windows build. The older one is a host-client exception for the WSL subnet, added under the client's local-network or split-tunnel settings. The newer one, on Windows 11 builds that support it, is mirrored networking: put networkingMode=mirrored in the [wsl2] section of %UserProfile%\.wslconfig, run wsl --shutdown, and the distribution shares the host's interfaces instead of a private NAT subnet. Mirrored mode also changes how localhost and inbound ports behave, so treat it as a migration rather than a toggle.

NAT, bridged, and what the host can see

Under NAT, the guest's tunnel packets are addressed to the VPN server's public address and leave through the host adapter as encrypted UDP or TCP. The host sees one flow and its byte count, nothing about the destinations inside it. Under a bridged adapter the guest has its own layer-2 identity on the physical LAN, takes its own DHCP lease, and looks to any MAC-based policy like a second device. Neither mode lets the host read the tunnel payload; the bridged guest is simply far more visible to the network around it.

There is a floor on the isolation too. A guest cannot hide from the machine that owns its memory, and whoever controls the host can read keys out of guest RAM. What a guest tunnel gives you is a routing boundary and a malware boundary, not protection from the person holding the laptop. The documented adapter modes are worth having open while you choose, since the mode changes both what the host sees and what the LAN sees.

Runbook: place it, configure it, prove it

Run these four checks in order in a fresh guest shell, and stop at the first one that disagrees with the owner you wrote down.

1. ip route get 1.1.1.1 returning tun0 or wg0 means guest-owned; returning eth0 with a private next hop means host-owned.
2. resolvectl query example.com, or read /etc/resolv.conf where the guest runs no resolver service. A tunnel that carries traffic but not DNS is the most common half-configured state.
3. Compare exits: curl -4 -s https://ifconfig.me in the guest against curl.exe -4 -s https://ifconfig.me on the host. Different addresses mean the guest owns the tunnel, and a host on the VPN with a guest showing the home ISP is the inherited-nothing case.
4. Repeat both with -6. A v4-only tunnel leaks v6 unless the client blocks or routes it, and plenty of clients leave v6 on the physical interface by default.

For a host-gateway design, where several guests share one tunnel, the host has to forward and translate. On a Linux host that is three pieces, and the guest quietly falls back to its plain route when any of them is missing:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

On the WireGuard side, the host peer's AllowedIPs has to include the guest subnet, for example 192.168.122.0/24, or the return packets never arrive and the setup looks like a firewall problem. A Windows host reaches the same result with Internet Connection Sharing or a NAT rule on the Hyper-V switch, and needs the same return-path check.

When the layout is still open, this table covers the arrangements that come up most:

Two tunnels, two guests, and the conflicts between them

When you need two exits at once, the pattern that holds up is one tunnel per guest. Each VM keeps its own default route and resolver, the host stays on the ordinary network, and the two tunnels never argue over the same routing table. Bridging two guests together does not pool their routes either: the virtual network provides a path, and each client still has to be told that this local traffic may bypass the tunnel.

Running a host tunnel and a guest tunnel together is legitimate, and deliberate nesting is sometimes exactly what you want, with the guest leaving through its own tunnel and that tunnel leaving through the host's. What turns it into an outage is that nobody wrote down which endpoint should be reached through which layer. Keep a two-column list of destination and owner, and a route conflict becomes a lookup instead of an afternoon of discovery.

Verify, then keep recovery with the owner

Test from inside the guest with a fresh application process: traffic, name resolution, both address families, and what happens when the tunnel drops. The host's VPN icon says nothing about guest coverage, which is the most common false confirmation in this whole area.

Recovery belongs to the owner as well. A guest-owned tunnel is restored by the guest's own client and the routes it wrote. A host-owned design is restored by the host's boot sequence, and the forwarding rules do not survive a reboot unless a unit or a startup task reapplies them. A restored snapshot is a deployment, not an undo, because it brings back old credentials and old routes along with the disk. Before you call the job done, confirm that the owner still matches the line you wrote down, that DNS and both address families resolve inside the guest, that a dead tunnel leaves a usable network instead of a black hole, and that a reboot or snapshot restore reproduces the same state.