Share One VPN Connection With Every Device on Your LAN

One laptop holds the tunnel, the rest of the house wants the same access, and the first attempt is to point everything at the connected machine. It fails for reasons that have nothing to do with the VPN: the receiving host must forward the packet, rewrite its source, and make sure replies can find their way back. Miss any of the three and the connected laptop keeps working while every other device times out. The fix is a routing design, not a client setting.

Why pointing devices at the host fails

A host that receives a packet addressed to a remote network becomes a router for that moment, whether or not anyone configured it as one. Forwarding is off by default on Linux and on Windows unless a feature switches it on. Translation matters because the remote side must know where to send replies, and a private LAN address means nothing to it. The return route is the third piece, and it is the one people forget when the first ping appears to succeed.

Diagnose in that order instead of toggling settings at random. Each missing piece produces a slightly different symptom.

Enable forwarding and translation on the host

Two changes on the connected host cover the first two pieces: enable IPv4 forwarding and translate the LAN traffic onto the tunnel interface.

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o tun0 -j MASQUERADE

Persist the sysctl value in a file under /etc/sysctl.d, and recheck the masquerade rule after a reboot, since firewall front ends can flush custom chains. On Windows the sharing feature performs both steps, but it also re-addresses the LAN adapter to a fixed subnet and clears its gateway, which breaks static addressing and port forwards. Restore the router's path to the host at its new address before concluding that sharing failed. Then watch the rule counters increase while a second device sends traffic.

Give the LAN a path that survives reboots

The other devices need a route to the remote prefix, and the two ways of providing it differ in blast radius.

ip route add 10.8.0.0/24 via 192.168.1.20 dev eth0

Pointing a client's default gateway at the host sends all its traffic through the host, including local printing and file sharing, so unrelated things stop when the host sleeps. Adding a specific route on the router for the remote prefix is narrower: only destinations behind the tunnel go to the connected machine, and the rest of the LAN keeps working. The subnets above are examples, so substitute your own LAN and tunnel ranges. Either way, test from a second device with the tunnel up and then down.

Watch MTU before blaming the tunnel

Tunnels shrink the usable packet size, and the second device has no idea. Large transfers and TLS handshakes stall while small requests succeed.

ping -M do -s 1400 10.8.0.5

A reply proves that size crosses the path unfragmented; a timeout means encapsulation overhead pushed the packet past the tunnel's MTU. Lower the MTU on the sharing interface or clamp the maximum segment size on the forwarder, then repeat the same probe. Test the same size on the LAN side first, because a local failure points at the LAN rather than at the tunnel. Record the working size, since a later provider or tunnel change can move it.

For a single extra device, host sharing is enough. For a household, put the route on the router. When access must survive the laptop leaving with you, the tunnel itself belongs on a dedicated gateway.