Windows Sandbox traffic does not follow the host VPN by default

You start Windows Sandbox, open a browser inside it, and the page loads from your normal connection even though the host was on the VPN a minute earlier. Nothing is broken. The sandbox gets a virtual network adapter attached to the host's default switch, and whether the host's tunnel covers that path is a property of the VPN client, not of Windows.

What the sandbox actually gets

The sandbox is a lightweight virtual machine with its own network adapter. That adapter connects through the host's Hyper-V default switch, which translates the sandbox's traffic to the host's virtual Ethernet interface before it leaves the machine. The detail explains almost every symptom people report about this.

So the sandbox is not a process on your desktop. It is a separate network endpoint whose packets are forwarded by the host, and the host firewall and the VPN client each see that forwarding in their own way. A rule written for a browser process does not automatically match a translated frame from a virtual switch.

Two requirements that look like one

Reaching a private resource and forcing every sandbox request through the tunnel are different goals. The first needs a route and name resolution that work for the sandbox's endpoint. The second needs enforcement that survives a reconnect and a failure. Neither one follows from the other, and a check that satisfies one says nothing about the second.

A public address check answers neither question fully. Seeing the VPN exit from inside the sandbox shows that some traffic used the tunnel. It says nothing about whether private names resolve, or what happens to a request that starts while the tunnel is down.

Write down which one you need before you test anything, because the two requirements lead to different designs and only one of them can be verified with a browser.

Check from inside the sandbox

The only meaningful observation comes from the sandbox's own session, not from the host. Open PowerShell there and look at the adapter, the name resolution and the path to a documentation address:

ipconfig /all
Resolve-DnsName files.corp.example
Test-NetConnection 198.51.100.7 -Port 443
Get-NetRoute -DestinationPrefix 0.0.0.0/0

The adapter list tells you the address and gateway the sandbox was given. A different gateway than the host uses is normal for the default switch, so compare the exit rather than the gateway. The resolution test tells you whether a private name is answered at all, which is where split-horizon setups usually diverge from the host. The route line tells you which gateway the sandbox believes owns the default.

Repeat the same three checks with the tunnel connected and disconnected. A result that does not change between those states is evidence that the tunnel is not in the sandbox's path at all, whichever address the public check showed.

Turn networking off when the sandbox does not need it

For offline inspection, a custom configuration file can remove the network entirely. The setting is a single element in the configuration document:

<Configuration>
  <Networking>Disable</Networking>
</Configuration>

The sandbox configuration reference documents this element and warns that enabled networking can expose internal networks to applications you do not trust. That warning is the whole reason to set it explicitly rather than accepting the default.

The switch does not select a VPN interface, though. It is a binary decision about having a network, not a way to bind the sandbox to a particular tunnel. A requirement that names an exit cannot be satisfied by a switch that only decides whether there is one.

Design the boundary before granting anything

If the requirement is strict isolation, choose a virtual machine network design that can enforce it, and use the VPN product's supported policy for forwarded or virtual-machine traffic. Guessing at the host client's behaviour is not a design, and a single successful check is not an implementation.

Do not hand an untrusted sandbox a corporate VPN profile or private credentials to make a test pass. That trades the boundary you were trying to establish for a green result, and the credential outlives the test.

Record the network mode, the observed exit and the reconnection behaviour in the deployment notes. When a client update changes how forwarded traffic is handled, those notes are what tell you the requirement was never really met.