Publishing a home VPN: what you actually expose

You forward one port for the tunnel and tell yourself the change is scoped. In practice the port only admits packets; what sits behind it is the exposure. Three things decide that exposure: the socket listening on the public side, the identity the tunnel accepts, and the destinations that identity can then touch. Each needs its own answer, because a careful choice in one does not constrain the others.

A port forward is not a service

A router rule moves packets toward a host; it does not name the process reading them. The forwarding page and the listening socket live in different places, which is why a rule can point at a machine that no longer runs the service. To find out what actually answers, look on the host: ss -lntup lists every listening socket with the process that owns it. Then match that process to a component, a version and an owner.

Removing the rule you remember creating does not close the door. A UPnP mapping may have added itself, an IPv6 address can stay reachable after the IPv4 entry is gone, and a second publishing method may exist on another machine. Read the router's UPnP mapping list as well as its static entries, then test from outside the network.

A login is not a LAN permission

The tunnel decides who may connect; the resources decide what a connected client can open. NIST's zero-trust guidance makes the same split at network scale: an address proves nothing about authorization. Give one enrolled laptop one task, such as reading a file share on a named host, and write that pair down. A tunnel address should not inherit administrator access to the rest of the house.

Also inspect the paths a summary leaves out: client-to-client traffic, bridge membership, internet forwarding and source translation. Each can join two systems your written task never mentions. Turn off the ones the task does not need, then list what the client can still reach.

A clean scan proves very little

An open port is a fact about one address and one protocol; a successful login is a fact about one credential. Neither says what happens next. Test the intended operation on the intended host, then try an identity that was never enrolled, a service nobody approved, and the management interface that should stay private. The last test is usually the one that fails.

Test both address families and every path you publish. A scan of the IPv4 address says nothing about a listening IPv6 service, and an internal test cannot see a NAT loopback problem or an upstream filter. Run at least one check from outside, on a connection that does not come back through the same router.

Write the exposure down

A short table turns the review into something the next person can audit. Fill it from the outside in, one row per reachable service, and keep it with the configuration, not in a chat thread. If a row has no owner, that is a finding.

Rows that only say "the VPN" are not rows yet. A row needs the socket, the host, the identity and the destination, because that is what an auditor or an attacker would test.

Plan the retirement before you need it

A tunnel you cannot revoke is a permanent door. Decide in advance how to retire a device credential, end a live session, and restore access after an upgrade breaks the service. Keep a recovery route that does not run through the tunnel, because the tunnel is the thing you will be repairing. Store it where you can reach it without that machine.

The review is finished when the intended destination works and the unwanted ones do not. It is not a guarantee that no vulnerability exists, and a scanner's green label substitutes for neither. Hand the table and the recovery note to whoever inherits the setup.