How to document a VPN lockdown exception so it can be removed
An exception nobody can describe is permanent. Record the traffic it permits, the requirement, the failure behaviour and the component that removes it.
Bypasses whose purpose left with their author are the ones that outlive their usefulness, and lockdown policies collect them faster than any other kind of configuration. An exception written as "allow local network" is a rule nobody can defend and nobody can retire, because the requirement behind it departed with the person who added it. Such policies fail by carrying exemptions whose reason evaporated while the risk stayed. The moment to write the scope, the failure behaviour and the removal step is the moment you add the exception, while someone still remembers why.
This is a decision about what the note must contain, not a template to fill in. The four fields below are the ones that decide whether a reviewer can remove the rule a year later without a meeting. Each one exists because its absence has a predictable cost.
Why an undocumented bypass never gets retired
A bypass with no description cannot be tested and therefore cannot be safely removed. It survives every review because deletion looks risky while retention looks harmless, and each review that passes over it makes the next one easier to pass over too. The cost is invisible until an audit asks why a private range is exempt, and by then the answer is a shrug.
The record has to be short enough that people actually write it in the change window. One line for the traffic, one for the requirement it serves.
Writing the scope as traffic
List the application or destination range, the address families involved, the service and port, and the network context in which the rule applies, then name the approver and the exact client or platform setting that carries it. "Printer" is an intention; "TCP 631 to 192.168.1.50, home network only" is a scope someone can verify. If the answer to "where does this live" is "somewhere in the MDM profile", the record is not finished. A file path, a profile name or a registry key beats a description of where the setting might be.
Where the platform supports per-application rules, prefer them to address ranges, because allowing one application to bypass the tunnel is narrower than exempting a whole private subnet and it survives the device moving to a new address. Android's VpnService guide describes that per-application model; the desktop clients express the same idea through their own profile settings. Address-based exemptions are the fallback when the platform offers nothing narrower, which is why they need a sharper scope line.
Four kinds of exception, four removal risks
Exceptions are not one category, and their removal carries different consequences. Sharing a single line between two kinds is how retiring a printer also retires the ability to connect.
| Kind | Typical example | Removal risk |
|---|---|---|
| Endpoint bootstrap | reaching the gateway before the tunnel exists | high: nothing comes up without it |
| Captive portal | hotel or airport sign-in page | medium: only matters on untrusted networks |
| Local device | printer, casting target, test instrument | low: one service at one address |
| Excluded application | an app that must not use the tunnel | medium: depends on the app's own behaviour |
Keep bootstrap, portal, device and application exceptions on separate lines even when they happen to overlap in practice. A private-range exemption silently grants every neighbour on that subnet rather than the single device you meant to reach, and that is the difference between a scope you can defend and one you merely hope about.
What the bypass does when the tunnel drops
Ask three questions and write the answers down, because they decide whether the lockdown is real. Does the exception stay usable when the tunnel drops: for a captive portal it must, or nobody can ever sign in, while for a private resource it usually must not, or the policy is decorative. Does it apply on every network or only in the intended environment, since a rule scoped to the home subnet behaves very differently on a public network that happens to use the same range. Each answer changes both the rule and the note, so a question left unanswered is a decision someone else will make wrongly later.
The third question is what happens when the destination changes its address, where domain-based and address-based exemptions diverge. Domain-based rules depend on when resolution happens and on how the client applies the result, so they can quietly stop matching after a change that looks unrelated, and the failure looks like a broken VPN rather than a stale exemption.
Test, retest, and write the removal step
Write one harmless test for the allowed path and one nearby denied case: the printer page loads and the file share on the same subnet does not. That pair proves the exception is narrow, and it is the pair a reviewer can repeat without understanding the original request. Then set the retest triggers, because an exception never retested drifts away from the requirement it was written for, and the drift stays invisible until something breaks.
Finally, record how to remove the rule through the component that owns it, and keep secrets out of the note. Describing a service and a route never requires a private key, a password or anyone's browsing history, and a short maintained list beats a temporary rule that outlived the person who wrote it.