Sharing a Windows Connection? The VPN Path Changes Under It

A laptop shares its Wi-Fi, the host browses through the tunnel without complaint, and the tablet on that share reaches nothing. The host stopped being only a client the moment sharing was enabled: it is a router now, and forwarded packets meet a different set of rules. Whatever works on the host says nothing about the device behind it. Run the checks from the downstream client and the distinction stops being theoretical.

The Host's Success Proves Nothing

Connection sharing hands four jobs to one machine: address assignment, forwarding, translation and filtering. A VPN client that protects locally generated traffic may treat forwarded traffic as out of scope, or block it on purpose as a leak. Neither behaviour is a bug, and neither is written down on the screen where sharing was switched on. Only the downstream test tells you which one you have.

Many clients forward host traffic and nothing else, so check the sharing section of the client's documentation instead of trusting the tunnel to route for the tablet. The visible symptom is a device that associates, receives an address, and then fails at the first request. A client that refuses to forward still looks perfectly healthy on the host.

Which Adapter Is Shared, Which Serves the Clients

Record both adapters, because they carry different addresses and different filters, and a change made on the wrong one explains a lot of confusing results. The sharing host normally claims a fixed address on the downstream side and runs a small DHCP and DNS service there. Windows keeps forwarding per adapter rather than globally, so the state has to be read interface by interface.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

If forwarding reads as Disabled on the shared adapter, nothing downstream will work whatever the tunnel does. Enable it only on a machine whose policy allows it to route for other devices.

Forwarding, Translation and Filtering

A forwarded packet has to reach the tunnel, be translated into something the far side accepts, and come back through the same translation. Any of those three stages can break, and every break produces the same browser timeout. A packet capture, a route lookup and a log from the far side are worth more than another review of the sharing dialog. Which stage fails is what tells you whose change is needed.

The far side may also need a return route for the shared subnet, a range the VPN server has never seen. Where the client translates, the server sees only the tunnel address and no return route is required. Where it does not translate, someone who owns the gateway has to add that route deliberately, and that is a change request rather than a client setting.

Run the Checks on the Client, Not the Host

Run every check on the client that fails, not on the host that works. Keep the egress address, the resolver answer and the application test in the same session, because results collected an hour apart say nothing about how the three combine.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Compare the egress address with the host's own and note whether the two match. A different answer means the forwarded path bypasses the tunnel, which is a policy question with an owner rather than a quick fix. A matching answer next to a failing application moves the work to name resolution or to policy on the far side. Do not stop at the IPv4 result either: a share can pass every IPv4 check while IPv6 leaves through a different exit, so repeat the name and egress checks with the AAAA record and the detailed connection test.

On a managed machine, confirm that sharing is permitted at all, because exposing access to another device is an administrative decision and not a convenience toggle. After any supported change, repeat the checks on reconnect and again during an outage. The host reconnecting cleanly does not restore a forwarded route that the client never supported.