Home VPN for Friends: Share the Exit, Not the LAN

Saying a friend may browse through your home connection is not the same as saying they may use your home network, and the gap between those two sentences contains the NAS, the printers, the router's admin page and every other device on the LAN. Each arrangement needs its own forwarding rules. Most shared-VPN incidents I hear about are not exotic attacks; they are a guest who reached something because nobody wrote down which boundary was being bought. Decide which contract you are offering, then express it in forwarding and access policy rather than in a message.

Two contracts that sound the same

Internet-only means the invited client's traffic leaves through your connection and nothing further. Full access means the same client also joins your local network, and that second contract silently includes the first, which is how people drift into it. The difference comes down to a handful of forwarding rules, and it is also the difference between sharing bandwidth and sharing a house. Write the contract down before you touch the firewall, because a rule you add afterwards is easier to justify than to remove.

Choose the internet-only contract unless somebody genuinely needs a LAN service, since a rule you never wrote is a permission you never granted. Then check which contract the client software implements, because a full-tunnel default can quietly deliver the wider one.

Boundary one: the household network

Guest traffic has no business on the household networks at all. A separate VPN subnet or a dedicated hosting segment makes that policy easier to express, but the different name enforces nothing on its own. Name the device that actually moves the packets and keep the crossing rules there, because a rule written on a machine that is not forwarding is decoration. When the VPN runs on the router, that enforcement point is the router's own forward chain.

A guest network with client isolation is a reasonable alternative, provided the VPN clients actually land on it. Either design needs the same test from a client rather than from the console.

Boundary two: the host and the other guests

Clients need the VPN service and nothing else on the machine that runs it, so management access stays a separate permission. It is the one most often granted by accident, because the tunnel listener and the administration interface sit on the same box. If the VPN terminates on the router, the tunnel port and the web or SSH interface are different subjects and deserve different rules. A rule that protects a login page should never be read as a ban on forwarding.

Internet access also does not require letting one invited client reach another. Remote-access pools often behave like a shared segment unless you say otherwise, so make the decision explicit in the pool configuration. For a handful of friends, isolation is the default worth choosing.

Map the paths before writing rules

A standalone appliance has two separate sets of packets to police: the ones that terminate on it and the ones it relays on behalf of a client. CISA's network guidance treats inbound, outbound and inter-network paths as access that needs justification, which is the right framing here. List the household prefixes as they really are, IPv4 and IPv6 both, because an IPv4-only block leaves a household that also routes IPv6 wide open at the same boundary. Then decide how clients get DNS and whether any resolver exception exposes only the intended service.

These are requirements rather than a universal recipe, because the rules depend on where the VPN terminates and where translation happens. Avoid adding a broad permit just to make the first browser request succeed.

What you are taking on, and how to test it

Sharing an exit creates an operating role. Invite people through the service's identity model, make removal practical, keep the host and router maintained, and decide how much of your upload the service may use. Requests leave from your address, so complaints and reputation problems arrive at your door even when no private device was touched. A technical isolation design says nothing about the legal position, and restricting traffic to common web ports does not make every permitted activity harmless.

Then test the denials with an authorised client rather than from the router console. Each of these should hold:

• Internet access works from the guest tunnel.
• NAS and printers are refused by address and by name.
• Router administration is refused from the tunnel address.
• A second invited client is unreachable.
• Removing the client's authorization actually ends access.

If the owner cannot maintain those boundaries and the operating duties, handing over a configuration file understates what the arrangement asks of them. That is the honest description of the service, and it belongs in the message that travels with the configuration.