What do a VPN head-end's negotiation logs prove about which peers still need the legacy proposal?

## Why the log is the inventory Every other source of truth here is an assurance. The asset register says what was bought, the vendor says what the firmware supports, the clinical engineering team says which wards have carts. None of those is evidence that a peer will fail tomorrow when you remove a proposal. The gateway's negotiation records are, because they are a record of what actually happened on the wire. This is why the change board wants them and why a cutover argued from a spreadsheet gets rejected. But the record has a precise meaning, and the failure mode of this leaf is reading more into it than it says. ## What a negotiation record proves A successful negotiation record proves that **a peer identity established a session using a particular transform, at a particular time, from a particular address**. That is the whole claim. In particular: - It proves the peer *used* the legacy set. It does not prove the peer *can only* use the legacy set. - It proves *something presenting that identity* connected. Identity is a credential, not a device. - The source address is where the packets came from at that moment, which behind carrier NAT or a churning DHCP pool is not a stable handle on anything. If your gateway logs the peer's **offered** proposals as well as the **selected** one, you have a second and much more useful signal: capability. A peer that offered both sets and was handed the legacy one is not blocking the migration at all — your own preference ordering put it there. That distinction routinely collapses the "cannot move" population by more than half before anybody visits a ward, and it is free. A peer that offered the legacy set alone is the genuine article: firmware negotiates only what it shipped with, and the vendor contract forbids you touching it. ## What absence proves, which is almost nothing "No peer has used the legacy proposal for thirty days" proves that no peer used it for thirty days. It does not establish redundancy, and the gap between those two statements is where enforcement day goes wrong: - **Spares in stores.** A cupboard of pumps that will be issued next month, imaged at the configuration they shipped with. - **Seasonal and intermittent estates.** A clinic that runs two days a week, a ward closed for refurbishment, a production line that only runs a particular product in one quarter. - **Failover paths.** A site-to-site tunnel that exists solely so a DR site can take over, and which by design is idle until the day it is not. - **Devices that are down for another reason** and will be repaired into a network that no longer accepts them. A failed negotiation is also worth pulling separately: peers that are trying and failing for some other reason never appear in your successes, and if you build the inventory only from established sessions you will not see them at all. So the window matters more than the count. Cover at least one full operational cycle — a quarter-end, a maintenance shutdown, a scheduled DR test — and say explicitly in the change record what the window did *not* cover. ## Turning the log into something a change board accepts The useful artefact is not a log extract; it is a joined list: | Column | Why it is there | | --- | --- | | Peer identity | The only stable handle across NAT and DHCP | | Offered set | Separates "cannot move" from "was not asked to move" | | Last seen on legacy | Drives the cohort order | | Named owner | Somebody who can authorise the outage for that cohort | | Cohort / site | So the cut can be staged ward by ward, line by line | The rows with no owner are the point of the exercise. A gateway carrying a decade of exceptions will produce identities nobody in the room recognises — a contractor's laptop, a test rig, a merged subsidiary's tunnel — and those are found by this exercise or not at all. The honest close is a fallback, not a certainty. You are proving that the population you can see is handled, and pairing that with an agreed reversal: the legacy proposal restored within a stated time if a cohort reports devices down. A change board will accept a measured window with a rollback far more readily than a claim that nothing is left. ## What an interviewer is listening for That you know what the record does and does not assert, that you separate the selected transform from the offered set, that you refuse to treat a quiet window as redundancy, that you inventory by identity rather than address, and that you turn the log into a cohort list with owners rather than an assurance that the migration is safe.