A user asks for local-subnet access on an always-on VPN laptop so they can print at home. What do you grant?
answer
- The subnet is whatever DHCP just handed you
- Home and conference look identical to the client
- The tunnel is up, so the laptop bridges
- Grant flows and ports, not a prefix
- Owner and expiry, or it is permanent
basics
~20 sGrant the ports printing needs, outbound-initiated, with an owner and an expiry - not the whole subnet. The exception follows whatever prefix DHCP just handed the laptop, so at a conference it reaches hundreds of strangers' devices.
solid answer
~50 sThe request sounds small and is not, because of how the exception is defined: `local subnet` means the prefix the client currently holds, not `home`. The same rule that reaches a printer at home reaches every device on a conference segment, in both directions if you do not keep it outbound-initiated. And the tunnel is up meanwhile, so the laptop bridges: a compromised device on that segment gains adjacency to a machine that is inside your network. Grant narrowly - raw print on TCP 9100, IPP on TCP 631, discovery on UDP 5353 - outbound-initiated only, with the host firewall's inbound deny untouched. Then treat it as a register entry with a named requester, an approver and an expiry, because the failure mode is not one bad exception, it is two hundred permanent ones nobody can justify.
go deeper
Know what the setting does in plain terms: it permits traffic between the laptop and the network it is plugged into, and that network is not always the user's home.
Explain that the exception follows the current prefix rather than a place, and name the specific printing flows you would allow instead of the whole subnet.
Demonstrate that you would grant narrowly, keep it outbound-initiated with inbound deny intact, and manage it as a register with owners and expiries rather than a one-off change.
Own the trend rather than the ticket: decide at what proportion of the estate the exception invalidates the always-on claim, and take that number to whoever funded the programme before an incident does.
## The request and what it actually asks for `Allow local subnet access` is the friendliest-looking switch in an always-on deployment. A home worker cannot print, a user cannot reach a network drive or cast to a display, and the fix is one checkbox. What the checkbox says is: while the tunnel is up, permit traffic between this laptop and the subnet it is directly attached to. The critical property is that the exception is **defined by the address the client currently holds**, evaluated continuously. It is not a property of a place. At home it means a small network of the user's own devices. On conference Wi-Fi it means the same permission toward every device sharing that broadcast domain, which can be hundreds of machines belonging to people you have never met. The client cannot distinguish the two from the addressing: private address ranges are used by both, and any signal the network offers about its identity is a claim the network makes about itself. ## Why it is worse than a normal exception Two properties compound. **It is a permanent hole, not a timed one.** A captive-portal window is seconds to minutes and closes itself. This one is on whenever the machine is on a network, for the life of the exception. **The laptop is a bridge while it is open.** Unlike the portal case, the tunnel here is *up*. The machine holds a path into the corporate network and, at the same time, a permitted path to an unknown segment. A device on that segment — an unpatched printer, a camera, someone's laptop — now has adjacency to a host that is inside your network. You have not given it access to your network, but you have shortened the distance considerably, and the whole justification for always-on was that the endpoint has exactly one network path. Direction matters and is frequently assumed rather than checked. If the exception is expressed as `permit the local subnet` in a stateless way, it permits inbound as well. Keep it outbound-initiated, and keep the host firewall's own inbound default-deny in place independently, so that the printing exception cannot widen inbound exposure by accident. ## What to actually grant Work from the flows, not from the subnet: - raw print (TCP 9100) or IPP (TCP 631), depending on the printer; - multicast DNS discovery (UDP 5353), only if the user genuinely needs discovery rather than a fixed address; - outbound-initiated only, stateful, with inbound unchanged. That is a materially different grant from the whole prefix, and most clients can express at least the port scoping. If yours cannot, that limitation is itself the finding to raise, because the alternative you are being asked to accept is unbounded. Also consider the answers that avoid the exception entirely: a print path that goes over the tunnel to a corporate print service, a directly attached cable, or simply telling the user that casting to a hotel television is not something a corporate laptop does. Refusing well means offering the user something, not just declining. ## The part that is really being tested: the register One exception is a technical decision. Two hundred is an operating model, and it is the one you inherit. The discipline that keeps it survivable: - a named requester and a named approver on every entry, and if you are the person who approves them, you sign each one yourself rather than delegating to a queue; - an expiry with re-approval, so that entries granted for a printer that was thrown away three years ago fall off; - a periodic report of how many devices carry it and why, so the trend is visible before it becomes untouchable; - a standing question for each renewal: is this still the narrowest grant that solves the user's actual problem? Interviewers ask this because it separates people who have configured an always-on client from people who have run one. The configuration takes an afternoon. The exception register is what the job actually is, and the honest answer includes the fact that you will be personally unpopular for keeping it short.
- Can the client tell a home network from a conference network before applying the exception?Not reliably. Both use private address ranges, and anything the network offers about its own identity is an assertion made by the party you do not trust. Some deployments narrow it with weaker signals such as the prefix size or a known public egress address, which raises the bar without settling the question. Treat the exception as active on every network, and scope it as if the segment were hostile, because sometimes it is.
- What do you offer the user if you refuse the exception outright?A path that keeps the single-tunnel property: printing to a corporate print service over the tunnel, a directly attached cable for the home case, or a documented statement that casting and local file shares are not supported on this build. A refusal with no alternative comes back as a manager escalation and you lose the argument on the second attempt, so bring the alternative to the first conversation.
- How do you stop the exception register from becoming permanent?Give every entry an owner and an expiry, require a re-approval that restates the business need, and publish the count and trend to whoever sponsored the always-on programme. The number is the argument: an estate where a quarter of devices carry a local-subnet exception no longer has an always-on posture, and the sponsor should learn that from your report rather than from an incident.
It is a door that opens onto whichever street the building happens to be on that day, and today the building is in a stadium car park.
saying these in an interview costs you the question
- Says private address space means the local subnet is trusted
- Grants the whole prefix instead of the printing ports
- Assumes the exception is outbound-only by default
- Approves it once with no owner, no expiry and no review
- Believes the client can tell home Wi-Fi from conference Wi-Fi