Sharing a Host VPN Session With a VMware Guest

Your virtual machine cannot reach an internal system that works perfectly on the host, and the host is connected through a client that owns the routing table. Bridging the virtual adapter to the tunnel looks obvious and fails for two separate reasons. Translation on a segment both machines own is what works. The cost is real: every guest stops having its own identity on the corporate network.

Two Reasons the Bridge Cannot Work

The client's adapter usually carries one address, often a /32, and the client rewrites the host's routes so that ordinary outbound traffic prefers the tunnel. Applications on the host obey that table and reach the private system. A bridged guest never reads the table at all, because its frames leave through a switch below the IP layer.

Putting the tunnel adapter into a bridge would solve the path in theory, and the driver will not accept it. Windows 10 also permits a single bridge device and withholds the routing role that would let a workstation forward between two subnets. What remains is source translation. Make the guest's traffic appear to come from the host, and the host's own decisions carry it into the tunnel without the guest needing a route it cannot have.

Create a Segment the Host Owns

In the virtual network editor, add a host-only network such as VMnet3 on a prefix you do not route anywhere else, for example 172.28.90.0/24. The host takes 172.28.90.1 on that adapter and the guest attaches to the same switch. Disable the hypervisor's DHCP on that segment so one address service owns it.

Confirm Windows can see the interface before you build anything on top of it, because the whole design depends on that adapter being ordinary:

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status
Get-NetIPAddress -AddressFamily IPv4 | Where-Object PrefixLength -eq 24

A host-only adapter appears there like any physical one. That is precisely the difference from the tunnel adapter, which cannot be attached to anything.

Translate the Guest Prefix

Open an elevated session and translate the prefix. Check what already exists first, because container runtimes and hypervisors install their own translations and deleting the wrong one breaks a different product.

Get-NetNat | Format-Table Name, InternalIPInterfaceAddressPrefix, Active
New-NetNat -Name "LabGuestEgress" -InternalIPInterfaceAddressPrefix 172.28.90.0/24

Then configure the guest with a static address in that prefix, 172.28.90.1 as its gateway, and the resolver addresses the tunnel hands the host. Translation forwards packets and teaches the guest nothing about DNS, so a guest left on the local router resolves public names and fails every internal one.

Check the First Hop, Then the Cost

Test the nearest boundary before testing an application. A trace that stops at the host gateway means translation is not happening, while one that stops beyond the host means the tunnel is down or the far side refused the translated address.

tracert -d 172.20.31.10
nslookup intranet.corp.example
Get-NetNatSession -NatName "LabGuestEgress"

Compare with the host's own access to the same destination while the tunnel is up. If the host succeeds and the guest does not, the fault sits in translation or in the guest's gateway setting rather than in the connection.

Then accept the trade. Corporate systems now see one address for every guest, so device certificates and per-device posture checks cannot tell them apart, and some policies forbid this outright. Decide the drop behaviour as well, since translated traffic can fall through to the ordinary internet path when the tunnel fails unless you block that prefix at the host firewall.