skip to content

A remote-access VPN authenticates a user with MFA and hands out a pool address - what does that session then reach?

level: juniorimportance: must knowfreq 78%

answer

  1. two decisions, not one
  2. the address arrives before any policy
  3. count destinations, not controls
  4. MFA gates admission only

basics

~20 s

A tunnel session reaches whatever the routing table and the filters behind the address pool allow, which by default is everything the concentrator can route to. Authentication decides who gets an address; it never decides which destinations that address may open.

solid answer

~50 s

The tunnel edge makes two separate decisions and interviews conflate them. The first is admission: do I accept this credential and this second factor, and hand out an address from the pool. The second is routing: what does an address from that pool reach once it is on the wire. Unless someone put a filter behind the pool with an enumerated allow list, the second answer is the whole routable estate. So the honest way to state the blast radius is a number - how many subnets, hosts and listening services a pool address can open on minute one - not the sentence "remote access is protected by MFA". An adversary holding a phished account and an approved push lands in exactly the same place a legitimate user does, with the same reach. MFA raised the price of getting an address. It changed nothing about what the address is worth once issued.

go deeper

for a junior

Be ready to say plainly that logging in gets you an address, and the address is what determines reach. Do not describe the tunnel's encryption as if it were an access decision.

for a middle

Explain the mechanics: the pool is an internal subnet routed into the estate, and absent a filter behind it the routing table alone answers the reachability question. Name what the edge control genuinely proves.

for a senior

Show you can quantify it - a reachable-destination count from a pool address - and that you know why the pool is still flat in most estates: nobody can enumerate what remote users legitimately need.

for a principal

Own the framing to a risk audience: admission controls and reach controls are separate budgets, and buying more of the first never buys the second. Be able to say what you are choosing not to fix and why.

## Two decisions, one box A remote-access concentrator makes two decisions that people hear as one. 1. **Admission.** Is this credential accepted, is the second factor accepted, does the device present the certificate or posture the policy demands? If yes, the session comes up and the client is given an address out of a **pool** - a block of internal address space reserved for remote sessions. 2. **Routing.** Once that address exists, what can it talk to? That is answered entirely by the routing table on the inside of the concentrator and by whatever filtering sits between the pool and the estate. The credential plays no further part. The leaf's whole point lives in the gap between them: **authenticated means routed, not authorised.** ## Why the default answer is "everything" A concentrator is normally deployed so remote staff can work, and "work" is not a list anybody has. The pool is therefore routed into the core the same way any other internal subnet is, and the estate's internal routing happily carries a pool address to every zone that has a route back. No policy is written down anywhere that says the pool may reach the backup network, the hypervisor management plane, the directory servers, the out-of-band console network or the finance segment - and none is needed, because reachability is the default and denial is the exception you must build. | What the edge control does | What it does not do | | --- | --- | | Decides whether a session is admitted | Decides which destinations that session may open | | Proves a credential and a factor were accepted | Proves a person was present or the device is clean | | Encrypts traffic in transit to the concentrator | Confers any authority on the traffic after it lands | | Produces a login record | Produces a record of what the session reached | ## The adversary's view An adversary who phishes an account and gets one push approved does not have to defeat anything after the edge. Their session is not an anomaly to any device in the path - it is a *permitted flow* from a pool address, indistinguishable on the wire from the same person's legitimate session an hour earlier. Every internal control they meet is one that was designed on the assumption that internal traffic is broadly fine. The interesting number is therefore not "how strong is the login" but "how many destinations did one accepted login just open". The same is true with no adversary at all: a contractor account issued for one application, a service account with a tunnel profile that nobody has reviewed in four years, or an acquired company's staff pointed at the same service after a merger, all inherit the same reach. ## Expressing it as a count The useful answer in an interview - and to a risk officer - is measurable. From a pool address, walk the routing table and the filters between the pool and each zone, and produce a destination count: *this pool can currently open 41 internal subnets and roughly 9,000 listening services, including the hypervisor management network and the backup control plane*. That sentence ends the argument that MFA is containment, because it is a number that MFA does not change. ## What it costs to shrink it This is the part candidates skip, and it is why the problem persists. Turning the pool into a default-deny position requires knowing what the remote population legitimately needs, application by application. In most estates nobody knows: application owners can name the front door of their own service but not the callers it makes, the flows are not documented, and a wrong deny is not an alert on someone's queue - it is a broken business flow at nine in the morning with a name attached to it. That discovery burden is the real reason the pool stays flat, and saying so is a better answer than pretending the design was an oversight. A competent answer therefore has three parts: name the two decisions, state that the second one is unowned by default, and price the fix honestly rather than promising an allow list nobody can staff.

  • How would you measure the pool's blast radius rather than assert it?
    Take a pool address as the source and evaluate the inside routing table plus every filter between the pool and each zone, then report the result as a count: how many subnets are reachable and how many listening services answer inside them. It is a static reachability statement, and it is repeatable, so you can show the number falling after each tranche of work. A policy document is not a substitute - it says what was intended, not what routes.
  • A risk officer says MFA plus a device certificate means a stolen account cannot cause harm. What is the correction?
    Authenticated means routed, not authorised. Both controls act only on admission: they change who can obtain a pool address, and neither changes what the address reaches afterwards. An adversary with a valid credential and an approved factor gets the same address, the same routes and the same destination count as the real user. The containment argument has to be made behind the pool, or it has not been made.
  • Does a login record tell you what the session did?
    No. It tells you a credential and a factor were accepted at a time, and which address was issued. What the session reached is only visible in flow or filter records from behind the pool, and those record a five-tuple, byte and packet counts and timestamps - never who was typing. If you keep only the login records, you can prove that access happened and nothing about its consequences.

A building pass that opens the front door is not a statement about which floors you may walk on. If every internal door is unlocked, the strength of the front-door check tells you nothing about where a stolen pass goes.

saying these in an interview costs you the question

  • Says MFA at the tunnel edge limits what an intruder reaches
  • Treats an encrypted tunnel as evidence the traffic is authorised
  • Claims the VPN is a security control so the inside is protected
  • Answers with a policy statement instead of a destination count
  • Assumes login logging would reveal misuse of a valid session

context