Write a VPN Design Brief Someone Can Actually Review

Most design reviews stall on the first question, because the request describes a product rather than a decision. A brief that names the flows, the owners and the failure behaviour can be answered in one meeting. A brief that says build a secure VPN cannot be answered at all. Work through the six checks below before sending anything, and the review turns into a comparison instead of a debate.

First, is the question a decision or a wish

A decision has alternatives and an observation that would choose between them. If you cannot name what you would look at to pick one, the question is still a wish. Write the alternatives down first, even if the list is only two items. Then write the trade-off that separates them.

A wish also tends to hide the audience. Say who has to approve the design, because the same brief reads differently to a network owner, a security reviewer and a finance approver.

Stop here if the answer is nobody, since an unowned decision will be remade by whoever complains loudest. That is a governance problem rather than a design problem.

Second, name the flows and the denials

List the source, destination and application for every flow that must work. Then list the flows that must keep failing, because a design that quietly permits them has changed the requirement without saying so. Address overlap and upstream reachability belong in this list as constraints rather than as surprises.

Be specific about direction. A site that may initiate connections to headquarters is a different design from one that may accept them, and the difference shows up in every rule you write afterwards.

Note the clients and their management state as well, since a managed device with an agent can do things a bring-your-own laptop cannot.

Keep the list short enough to test. Ten flows you can verify beat forty you cannot.

Check 3: separate facts from assumptions

Mark every statement that you have verified, and mark the ones you have not. Public addressing, available throughput and administrator access are the three assumptions that most often change the answer. If one of them is unknown, say how the design changes when it turns out either way.

An illustrative network is fine as long as it is labelled. The problem is a hypothetical branch that quietly acquires a second uplink or a public address block it never had.

Verify the assumption you can check before the review, because one measured fact removes an entire branch of discussion.

ip route get 10.50.0.10
traceroute -n -m 6 10.50.0.10
nc -vz 10.50.0.10 443

Fourth, write the failure contract

State what happens when the tunnel is down, and be explicit about the two different promises. Restoring new connections after a reconnect is easy to promise. Preserving sessions that were already established across a failure is a much stronger requirement, and it constrains the technology choice.

Then decide the fallback: block the traffic, route it another approved way, or do something different per application. A silent fallback to a direct path is a design decision even when nobody wrote it down.

Add the recovery target in plain language, such as how long a site may operate degraded, and who declares the incident.

Check 5 and 6: pick the seam and record the change

Choose one seam to argue about, because a review that tries to settle everything settles nothing. Routing, authorization and encryption are three different seams, and a brief should say which one the question is about. RFC 4301 is a useful reminder here, since it separates policy decisions, protected traffic and security associations rather than treating them as one object.

Then record what changed after the decision, including the assumptions that were revised. That record is what makes the next review shorter.

git diff --stat design/vpn-brief.md
grep -n 'assumption' design/vpn-brief.md
ip route get 10.50.0.10

A brief that passes all six checks produces a question with an answer: the design meets the stated flows and the failure contract, or a named constraint prevents it. When the constraint changes later, the record shows which decision has to be revisited and which one can stand. That is what makes the exercise reusable rather than a one-off argument.