Write the Packet Path Before You Configure the VPN

Most VPN builds start with a client and a profile, and by the time the tunnel is up nobody can say which packet was supposed to traverse it. The first page of work is cheaper than the third hour of debugging: describe one intended connection end to end, on paper, before a configuration file exists. The exercise usually settles a question you had not asked yet, such as whether the requirement is an internet exit, remote access to a subnet, or a link between two sites.

One connection is enough to start. Three pages of topology usually hide the same missing answer.

Describe one request, not a diagram

Begin with the sender: an address range, an address family, and the application that originates the traffic. Then name the destination prefix and the service on it, down to the port and protocol, because a rule that allows the subnet but not the service is a rule that does nothing. The two addresses are the whole point, and everything below is the machinery that has to agree with them.

List the path in order: the physical link, the VPN endpoint at each end, the tunnel itself, and the network beyond it. Write the interface names if you know them, since that detail is what turns a description into something you can compare against a routing table later. Add the address each interface uses on the tunnel side. Without those two facts nobody else can check the record against the device.

Now name the one intended connection in a single sentence at the top of the page. If that sentence needs the word or, you have two designs and should treat them separately.

Follow the reply before the request

A path that only describes the outbound direction is half a document. Follow the response back and identify which device knows the sender's range, whether a translation changes the source on the way out, and where the return packet is expected to enter. The reply is where most builds fail, because the request is easy to observe and the answer is not.

Note any address translation explicitly, including where it happens and what the far end then sees. A peer that logs one address and routes to another is describing two different designs.

Treat name resolution as its own exchange rather than as part of the application's route. An internal record may need a resolver that is only reachable through the tunnel, and a path record that stops at the application prefix will not reveal it. The same applies to any certificate validation that depends on reaching an internal authority.

Give every decision an owner

For each route, firewall rule, selector and credential, write down which configuration holds it and which person may change it. An owner per line is what makes the document survive the first change request, because the alternative is a document that describes intent and a network that describes history.

Watch for two owners of one default. A client script and a network manager can both install routes without either one knowing about the other, and a gateway listener allowance is not the same permission as forwarding. Both cases produce a path record that is correct on paper and wrong on the wire.

Where a value is decided by a provider rather than by you, say so on the same line. A prefix delegated by a hosting company has a different change process than one you chose yourself. That note saves the next engineer a support ticket during an incident. It also explains why a change you approved had no effect.

Describe what breaks and how you recover

For each stage of the path, state what stops when the tunnel disappears and which outbound connection must remain reachable so you can fix it. A design that loses its management access together with the tunnel is a design that requires a site visit.

Full tunnel and split tunnel belong on this page as an explicit choice rather than as a checkbox, because they change both the failure mode and the recovery path.

Name a harmless test for each stage

Endpoint reachability, tunnel establishment, private address, private name and application permission are five different observations, and each needs a test that cannot be mistaken for another. A ping to the gateway proves the first two at best. A connection to the application port proves the fourth and fifth only if the name resolved through the intended resolver.

Write the test next to the stage it covers, including the command and the expected output. A page of precise paths beats a page of commands that never says which packets they were meant to affect.