An adversary owns your VPN head-end outright — how does the inside leg's position change what they originate?
answer
- two adversaries, not one
- passing through versus originating
- whose policy can the compromise edit
- the identity-store flow you cannot delete
- an enumerable list, not zero
basics
~20 sOwning the box deletes its own policy as a control: the adversary now originates traffic and chooses source addresses. From a core-VLAN landing they reach whatever the core routes; from a screened tier, only what a device they cannot administer permits.
solid answer
~50 sDistinguish two adversaries. One is merely getting traffic past the head-end — riding a session, exploiting a policy gap — and is still bounded by what the appliance forwards and by downstream rules keyed on the client pool. The other owns the appliance: they originate traffic themselves, choose any source address on the inside leg, use every inside interface, and read what the box holds, including the credential it uses to query the identity store two zones deeper. Every policy on the appliance is theirs to rewrite. Position is what still differs. Landed on the core VLAN, that traffic is ordinary internal traffic to anything the core routes. Landed in a screened tier, everything crosses a device the head-end's admins cannot change — which is why a broad management allow for its address cancels the design.
go deeper
Know that an attacker who controls an appliance also controls the rules configured on it, so those rules stop being a control at that moment.
Explain the difference between traffic passing through the head-end and traffic originated by it, and why source addressing and interface choice change with ownership.
Show the two landing zones side by side, name the flows the screened position cannot remove, and describe how exception drift in the second rule base erodes the claim.
Own the requirement that the permitted-origination list is a written artefact with a named reviewer, and the argument for separating administration of the two devices even when it costs an operating model.
## Two different adversaries, routinely conflated Interviewers ask this to see whether you separate **bypassed** from **owned**, because the two produce very different pictures and only one of them is bounded by the appliance. **Bypassed.** The adversary gets packets past the head-end's intent — a session they should not have, a gap in the policy, traffic that matches a rule written for someone else — but the box is still running the defender's configuration. Their traffic is sourced from the client pool, subject to whatever the head-end forwards, and visible to any downstream rule keyed on pool addresses. It is a policy failure, and policy is still the thing that constrains them. **Owned.** The adversary controls the appliance. Now: - they **originate** traffic rather than passing through it, choosing source addresses freely on the inside leg — including addresses that downstream rules were written to trust; - they use **every** interface the box has, not the one the diagram shows the tunnel using; - they can read what the box stores, and a remote-access head-end stores a lot: the service credential it uses to query the identity store, certificates and their private material, cached configuration, sometimes shared secrets for other network services; - **the head-end's own policy is no longer a control at all**, because it is theirs to edit. Everything the appliance was supposed to enforce is gone. The only question left is what the *rest of the network* still enforces about traffic leaving that box. ## Why the position decides that answer | Landing zone | What the owned head-end can originate | Who can change that answer | | --- | --- | --- | | Core VLAN | anything the core will route, sourced as ordinary internal traffic | the head-end's own admins, i.e. the compromised plane | | Screened tier behind a separately administered device | only what that device permits from the head-end's address | a different team, under a different change process | That second row is the entire value of terminating outside the estate, and note carefully what it is: not "an extra firewall", but **a policy the compromise cannot rewrite**. If the same team administers both boxes with the same credentials, you have bought a hop and not a boundary — worth saying out loud, because it is the honest weakness of most real deployments. ## The flows you cannot remove Be honest about what the screened position does **not** buy. The head-end must reach an identity store to authenticate anyone, and that store lives deeper in the estate. That flow is permitted by construction, so an owned head-end inherits it. You can bound it — a single destination, a single service port, no reverse initiation, and no other rule that lets the head-end address the same zone for anything else — but you cannot delete it. The same applies to whatever logging, time and certificate-validation paths the box needs. This is exactly the answer that separates a candidate who has drawn the design from one who has had to sign it: the screened position converts "reaches everything" into "reaches an enumerable, written-down list", and the list is not empty. ## How the boundary is usually voided In practice the second device's rule base acquires an allow for the head-end's address, for management, for backup, for a clustering heartbeat with a peer in another tier, or "temporarily" during a migration. Each one is defensible on its own and each one widens the enumerable list. The design's real requirement is therefore procedural as much as topological: the list of permitted originations from the head-end is a written artefact with an owner and a review, or the design decays into the first row of that table within two years. ## Answering it well Lead with the owned/bypassed distinction. State that owning the box deletes the appliance's own policy as a control, so only external policy remains. Give the two positions and what each bounds. Then volunteer the flows you cannot remove and the exception drift that eats the rest — that last part is what turns a correct answer into a credible one.
- The screened tier's device is administered by the same team as the head-end. What have you actually bought?A hop, not a boundary. The value of the outside position is a policy the head-end's compromise cannot rewrite; if the same administrative plane and the same credentials reach both, an adversary who owns the first reaches the second by the same route. It still helps against a purely network-level compromise of the appliance, but you should not claim it bounds a full takeover.
- Which flow from the head-end can you never remove, and how do you bound it?Authentication traffic to the identity store, which by definition lives deeper than the tier. Bound it to a single destination and service, deny everything else from the head-end's address, forbid reverse initiation from that zone back to the tier, and write the resulting permitted-origination list down as an owned artefact that gets reviewed — because that list is your blast-radius claim.
- How does the picture differ for an adversary who merely gets a session past the head-end?They are still inside the defender's configuration. Their traffic is sourced from the client pool, shaped by whatever the appliance forwards, and matchable by downstream rules keyed on pool addresses. That is a policy failure to fix in the policy. Owning the box removes all of it, which is why the two cases need different mitigations and should not be argued as one.
saying these in an interview costs you the question
- Owning the appliance and stealing an account are the same problem
- The appliance's rules still limit an attacker who controls it
- A screened tier means the head-end reaches nothing internal
- Multi-factor authentication bounds a compromised head-end
- The second device is a boundary even under identical administration