NAT vs Bridged VM Networking: Which One Carries VPN Traffic?

Bridged and NAT are not two ways of attaching the same guest to your VPN; they decide who owns the guest's packets before any tunnel is involved. In NAT mode the hypervisor rewrites the guest's traffic and emits it from host-side code, so the guest rides whatever route the host hands that code. In bridged mode the guest gets its own link-layer identity on the physical segment and picks its own default gateway, which makes the host's tunnel irrelevant to it unless the LAN router is the one doing the tunneling. I stopped treating the VM as being on the VPN and started treating it as a question about where that guest's default route points. The test below takes a few minutes per mode and settles it without guesswork.

NAT keeps the guest behind hypervisor code, where host routes apply

In VirtualBox a NAT guest sits on 10.0.2.0/24 with a virtual gateway at 10.0.2.2, a DNS proxy at 10.0.2.3, and no route of its own to the physical network. Outbound packets are taken by the NAT engine, rewritten so the source is the host, and passed to the host IP stack. From there the guest's traffic is a host flow, and route lookup is by destination: a full-tunnel client that installs 0.0.0.0/1 and 128.0.0.0/1 on the host captures it without ever knowing a VM exists. Oracle's VirtualBox networking chapter lists these defaults if you want to confirm the addresses on your build.

libvirt's default network reaches the same place from 192.168.122.0/24, where dnsmasq hands out leases and the host masquerades the subnet, so the guest's packets arrive at the host's routing decision again. The exception is a client that picks traffic by process instead of by route. If the split-tunnel list contains your browser and nothing else, the NAT engine is not on that list, and the guest leaves the machine untunneled while the host browser still looks covered. Same subnet, opposite result.

Bridged hands the guest its own place on the physical LAN

A bridged guest is given a virtual NIC attached to a real adapter, gets its own MAC address, and takes a DHCP lease from the physical network. Its default gateway is the LAN router, not the hypervisor, and its frames go onto the wire through that adapter. The host's tunnel routes live in the host's table and are never consulted, because the guest's frames never enter the host IP stack.

That cuts both ways. mDNS and SMB browsing start working because the guest sees LAN broadcast traffic, and the guest becomes reachable from other machines on the same segment with no host firewall in between. Bridging is also not a way to push a guest through an existing tunnel: attaching a VM to the host's WireGuard or OpenVPN interface is not something VirtualBox or libvirt does for you. If a bridged guest has to be tunneled, the tunnel must terminate somewhere on that LAN.

The test that ends the argument

Run the same checks in both modes and write the answers down:

• On the host, curl -s https://ifconfig.me gives the public v4 address.
• In the guest, the same command, plus ip route on Linux or Get-NetRoute -DestinationPrefix 0.0.0.0/0 on Windows for the default gateway.
• Resolver identity: resolvectl status or cat /etc/resolv.conf in the guest, to see whether it points at 10.0.2.3 or at a LAN server.
• Address family: ip -6 addr show scope global and one v6 request, because a v4 tunnel says nothing about a global v6 address the guest may hold.

Matching public addresses mean the guest is on the host's path. A guest address that matches the LAN's ordinary egress means it is not. The step people skip is the control: bring the host tunnel down and repeat the guest request. If the guest keeps browsing, it never depended on the host tunnel, whatever the mode name suggests. In NAT mode the guest should lose internet with the host tunnel down, unless the client is configured to allow untunneled traffic, which is worth knowing on its own.

Two signals lie. A successful ping proves reachability, not exit path. And DNS can be answered by the 10.0.2.3 proxy through the host resolver while TCP takes a different route, which is how you get a page that loads and a login that never completes.

Which mode fits the job

The mode is a routing decision, so pick it from the requirement instead of from habit:

Row one is where people get caught: NAT plus a full-tunnel host client does cover a guest, but only while the client tunnels by route and the host uplink is that tunnel. Move the client to a browser-only allowlist and the coverage disappears with no error anywhere. Row four is the reverse mistake, a guest bridged for convenience that quietly starts answering SMB or SSH on the office LAN.

Failures that get blamed on the VPN

On Windows the NAT translation runs inside the VirtualBox VM process, so a per-app client needs that exact image on its list rather than a blanket rule for virtual machines. When a client update rebuilds its process allowlist, NAT guests lose coverage first, and the report reads like a VM that can reach the LAN but not the internet while the host is fine.

Bridging to Wi-Fi is the other classic. Access points rarely forward frames carrying a foreign source MAC, so a bridge onto wlan0 either fails outright or works until client isolation on the AP starts dropping it. VirtualBox will still offer the wireless adapter in its list. If the host is on Wi-Fi and the guest must be bridged, plan to test it rather than assume it.

MTU is the third. A bridged guest keeps the LAN's 1500-byte MTU, and if it runs its own WireGuard client at 1420, large TLS handshakes stall while small requests succeed. Under NAT the host tunnel's MTU is the host's problem, but the guest still believes in 1500, and UDP with the don't-fragment bit set blackholes the same way.

Write the mode down, then recheck after any adapter change

Record the mode, the host interface the bridge uses, the guest's default gateway, its resolver, and its v4 and v6 exit addresses. That record is what makes the next failure cheap: when a laptop moves from dock to Wi-Fi, a bridged guest follows the bridge to a different physical adapter and may re-lease into another subnet, while a NAT guest keeps its 10.0.2.x address and silently inherits a different uplink.

Before closing the ticket, confirm each of these:

• The guest exit address differs from the host exit address, so it is not on the host tunnel.
• The resolver is the 10.0.2.3 proxy or a LAN server, and you know which one answered.
• No global v6 address exists in the guest if the tunnel design is v4-only.
• With the host tunnel down, the guest stops browsing, or you now know it never depended on it.
• The guest does not see LAN broadcast traffic it has no business seeing.