You move the legacy VPN proposal onto a second listener restricted to known peers. What does that buy?

## The problem being solved A head-end that accepts a weak proposal offers it to every caller that reaches it. If the exception exists for a fleet you cannot reconfigure, the exposure lasts as long as the fleet does, and the exposure is not limited to the fleet. The move is therefore to stop making the exception part of the surface that every caller touches, and to make it a property of a group. There are two shapes of the same idea, and the interview usually wants both named: - **A separate listener** — the legacy proposal set lives on its own address or port, reachable from a known peer set, while the primary head-end no longer offers it at all. - **A per-peer or tunnel-group binding** — one head-end, but the legacy proposal set is attached only to the group those identities land in, and the default policy everyone else negotiates against does not contain it. ## What it buys **The general negotiation surface loses the weak option.** A caller dialling the main head-end and offering only the legacy transform is refused, because there is now nothing in common. This is the whole point: the population that can select the weak proposal shrinks from "anyone who can route to the gateway" to "anyone who can reach the restricted endpoint and satisfy its binding". **The exception becomes enumerable.** Once it is a group rather than a default, the members are a list you can hold, review and shrink, and additions become visible events rather than silent inheritance. This is what turns the migration into cohorts you can cut one at a time. **It gives you a clean signal.** Any attempt to use the legacy proposal by an identity not in the group is now anomalous by construction, which is a far better thing to alert on than "someone used the old cipher". ## What it does not buy — and this is where candidates overclaim **The legacy tunnels are exactly as weak as they were.** Inside that group, an adversary who records traffic, or who sits on the path, is in the same position as before. If the legacy set is also what keeps a weak authentication method acceptable — a group secret identical across a shipment and readable from any one device sitting in a corridor — then anybody holding that secret still authenticates into the group. Narrowing the negotiation surface changes *who may select the weak option*; it changes nothing about *what the weak option protects*. Saying otherwise is the single most common failure on this question. **A source-address restriction is weaker than it sounds.** These populations sit behind carrier NAT, take DHCP leases that move, and in the cellular case get a different address every day. An address list is stale within a week, and it fails in both directions: legitimate devices locked out on a ward, or an entry that quietly stays open long after the device behind it was decommissioned. Bind by peer identity or tunnel group — the same handle your inventory is keyed on. ## The cost, which is where this estate bites The separate-endpoint version assumes you can point the devices at the new address. Frequently you cannot. Vendor-shipped clients on pumps, imaging carts, PLC gateways and kiosk terminals carry the head-end address in firmware or in a configuration the support contract forbids you editing. Repointing then means a vendor visit per device, scheduled around ward availability or a production line — which is the outage you adopted this approach to defer. That is why the per-peer binding on the existing address is usually the practical form: identical narrowing, no device touched. There is also a durable operational cost. A second endpoint standing apart from the main path tends to fall out of the main monitoring, the main configuration review and the main change process, and it survives the fleet it was built for. Attach an owner, an expiry date, and a retirement condition tied to the inventory — no peer on the legacy set across a full operational cycle — or you have relocated the exposure rather than reduced it. ## How to answer it Say what the split narrows (who may select), say what it leaves untouched (what the weak option protects and who can authenticate into it), pick identity binding over address binding and say why, and be honest that the elegant version may be unbuildable because the address is baked into firmware you are contractually not allowed to touch. Then close with the expiry, because an exception without one is the thing you will be asked about at the next audit.