Affiliate disclosure - This post contains affiliate links. If you subscribe through them, we earn a commission at no extra cost to you.
There is a category of device that cannot run a VPN client and never will: a games console, a smart TV whose app store has three apps in it, an e-reader, a network printer, anything embedded.
The usual answer is a VPN on the router, which puts everything in the house behind the tunnel whether it needs it or not. The narrower answer is this one: your laptop already runs the VPN, so let it route for one device over a cable.
What is actually happening
Your laptop has two network interfaces at that moment. The tunnel, which is the VPN's virtual adapter, and the Ethernet port with a cable running to the device.
Sharing means telling the operating system to forward traffic arriving on the Ethernet port out through the tunnel, and to hand the device an address so it knows where to send that traffic. The device does nothing special. It thinks it is plugged into an ordinary network.
Two facts follow, and both matter:
- The laptop must stay awake and connected. Close the lid and the device loses everything, not just the VPN.
- The device gets the tunnel's exit country, which is the whole reason for doing it.
Windows
Connect the VPN first, then plug in the cable. The order matters, because Windows binds the sharing to whichever interface is present when you enable it.
Open Network Connections (ncpa.cpl), right click the VPN adapter, then Properties, then the Sharing tab. Tick Allow other network users to connect through this computer's Internet connection, and in the dropdown below choose your Ethernet adapter. Not the other way around: the sharing is enabled on the connection being shared, and the dropdown names the connection receiving it.
Windows then assigns 192.168.137.1 to the Ethernet adapter and runs a small DHCP service on it. The subnet is fixed at 192.168.137.0/24, so the device receives one of 253 remaining addresses, and the value is hardcoded in Internet Connection Sharing rather than configurable in the interface. The device gets an address a few seconds after being plugged in.
Two known irritations. Internet Connection Sharing does not always survive a reboot, and re-enabling the tick box is the fix. And if the VPN client uses a TAP adapter rather than WinTun, the Sharing tab sometimes appears on the wrong entry: choose the adapter whose status shows the VPN's server address.
macOS
System Settings, then General, then Sharing, then Internet Sharing. Set Share your connection from to the VPN interface, and tick Ethernet in the list below. Enable the switch.
macOS is stricter than Windows here in a useful way: if the VPN uses a configuration profile rather than a network interface, it may not appear in the source list at all. In that case the tunnel is applied at the application layer and there is nothing to share, which is worth knowing before spending an hour in the settings pane.
Linux
With NetworkManager, the shortest route is one command per session:
nmcli connection add type ethernet ifname eth0 con-name partage ipv4.method shared
ipv4.method shared does all of it: address on the interface, DHCP for the client, and NAT out through the default route, which is the tunnel while the VPN is up.
If you prefer to see the moving parts, the manual equivalent is forwarding plus a masquerade rule, the same shape as any small router:
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
Replace tun0 with your tunnel interface, which ip route get 1.1.1.1 will name for you.
The two ways this leaks, and how to check
The tunnel drops and the laptop keeps routing. Sharing does not know anything about the VPN's health. If the tunnel falls, the default route becomes your ordinary connection and the device continues happily, now unprotected, with no visible change. A kill switch on the laptop is what closes this, and it is the single most important part of the setup: see what a VPN kill switch does.
DNS goes out the wrong door. The device asks the laptop, the laptop asks whichever resolver it was given, and on Windows that is often your ISP's. Traffic in the tunnel, lookups outside it. The test is direct: from the shared device, open our DNS leak test and confirm the resolver shown belongs to the VPN provider and not to your ISP.
Verify from the device itself, not from the laptop. The laptop is behind the VPN by definition; that proves nothing about what it forwards. Load an IP checking page on the console or TV and read the country there. If it shows your real one, the sharing is passing traffic around the tunnel rather than through it.
There is a third failure worth naming because it does not look like a network problem. The shared device negotiates the standard Ethernet MTU of 1500 bytes, but the tunnel it is being routed into is smaller, 1420 on WireGuard once its 60 bytes of overhead are accounted for. Small packets pass, large ones are dropped, and the symptom is a console that reaches the login screen and then stalls on a download. If path MTU discovery is being filtered, clamping the shared interface to 1400 is the direct fix.
When a cable is the wrong answer
If more than two devices need the tunnel, or if they need it when your laptop is closed, the answer is the router rather than the laptop: VPN on the router or on the device sets out the trade-off.
And if the device is a console, there is a shorter path that avoids all of this, covered in VPN for PS5 and Xbox.
Secure your connection with NordVPN
Threat Protection blocks trackers & malware · kill switch · 30-day money-back
