Share a Windows VPN With a Wired Console: PC Gateway vs Router
A console behind a Windows PC needs a downstream segment, addressing, translation and a forwarding client. Compare that with a router owning the tunnel.
Consoles that cannot run the VPN client can sometimes borrow a Windows PC's tunnel, and the arrangement fails more often than it succeeds for reasons unrelated to the VPN. The PC has to become a gateway: a dedicated downstream interface, addressing for the console, translation, and a client willing to forward another device's packets. A tunnel that works for the PC's own applications proves none of that.
The comparison worth making is between that arrangement and a router that owns the tunnel for the whole network. They differ in maintenance, in failure behaviour, and in how much of the policy you can see at once.
What the PC Gateway Has to Do
A gateway needs an interface facing the console, an address range for that segment, and a translation rule rewriting console traffic onto the tunnel. It also needs the client to forward packets it did not originate, which is a different setting from accepting its own traffic. Name resolution must travel the same path, or the console resolves a game service through one route and then connects through another. Each of those is a separate configuration step with its own failure mode.
console -> dedicated ethernet -> windows sharing / nat
-> selected tunnel interface -> internetWindows Internet Connection Sharing provides exactly this shape, with one connection nominated as public and another as private. That nomination matters more than people expect, because the interface reaching the household router is not automatically the one carrying the tunnel.
Comparisons That Decide It
Three differences separate a PC gateway from a router gateway, and they are the ones that surface months later. The table puts them side by side.
| Aspect | Windows PC gateway | Router gateway |
|---|---|---|
| Tied to a user session | Yes; sleep or sign-out ends it | No |
| Policy visibility | Split across client and sharing layer | One ruleset |
| Address service | Private side of the sharing feature | Router scope |
| Recovery after reboot | Manual, per session | Automatic |
The session tie is the first difference and the one that catches people. A PC that sleeps, signs out or installs an update stops being a gateway, and the console loses its path without any configuration changing. Policy visibility is the second, since the client's rules and the sharing layer live in two places and neither describes the other. Address service is the third, and it explains a console that holds an address while still reaching nothing.
None of that makes the PC arrangement wrong. It makes it a temporary design, which is acceptable when the requirement is temporary.
Forwarded Traffic Is a Different Category
A desktop client may treat packets forwarded for another device differently from its own. A per-application inclusion list covers processes on the PC and says nothing about a console's traffic, while a kill switch guarding local applications may not guard the forwarded path at all. Confirm the client's documented behaviour for forwarded traffic rather than inferring it from a successful page load on the PC. Where that behaviour is unclear, the whole arrangement rests on an assumption.
The console's addressing should come from the sharing arrangement, never from copying the PC's tunnel address onto it. Copying produces a duplicate address, a wrong gateway and a resolver pointing at something the console cannot reach. Let the downstream service hand out the configuration, then check what the console actually received.
Verify Console Traffic, Not the PC's
The only meaningful test observes the console's path. On the PC, the commands below show the interface layout, the neighbour table across the downstream link, and whether the console answers on a service port. Run them while a game session is actually connected.
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4Address
Get-NetAdapter | Select-Object Name, Status, LinkSpeed
arp -a | findstr 192.168.137.
Test-NetConnection 192.168.137.10 -Port 3074An interface with no address on the downstream side means sharing never started, which is a different problem from a console that cannot connect. An entry for the console in the neighbour table proves the link and the addressing are alive. A failing port test after that points at forwarding or the client's treatment of forwarded traffic, not at the cable. Compare the console's exit address against the PC's before concluding the tunnel is the path in use.
Keep the arrangement documented with its interface names and address ranges. When it breaks after the next update, that page saves an hour of rediscovery.