Work Laptop on a Personal VPN: What Actually Crosses

Joining a company laptop to a home VPN puts it in two places at once, and the interesting question is smaller and more useful than the alarming one. Nobody connected an Ethernet cable between the office and the house, and no route magically makes the home network an extension of the corporate subnet. What exists is a single endpoint with access to both environments, and three separate mechanisms decide what can actually move between them. Walking those three, from the endpoint outward, produces an answer an administrator can act on instead of a debate about labels.

Start at the Endpoint, Not the Network Diagram

The endpoint is where both connections meet, so it is where the review begins: which processes run, what they can reach, and who controls them. A diagram that shows two clouds connected to a laptop is accurate and unhelpful, because it implies a link that may not exist. Replace it with a list of the applications that can talk to each environment, and note the account each one runs under. That framing also keeps the review proportionate, since a laptop with two tunnels is not the same object as two networks joined together.

That list is the inventory the rest of the review works from. If it contains a sync client, a browser profile signed into both environments and a build agent with credentials, the review already has its subjects.

Three Crossing Points, Reviewed Separately

Application access is the first crossing point, and it does not require any forwarding. A browser tab, a sync client or a build agent on the endpoint can read from a resource in one environment and submit data to a resource in the other. That capability exists whether or not the operating system forwards packets between interfaces, and it is the mechanism people miss when they conclude that no bridge means no risk. Reading the list of applications is therefore more informative than reading the interface list.

Identity and data form the second crossing point. Corporate credentials, session cookies, downloaded documents and management rights live on the endpoint, and joining another network does not disclose them by itself. What changes is the set of parties that could influence the endpoint while it holds those credentials, which is a question about the trustworthiness of the personal network rather than about routing. That is a judgement the endpoint owner cannot make alone, and it is not answered by the absence of a forwarding rule.

Network forwarding is the third, and the only one that can turn the laptop into a transit device. IP forwarding, internet connection sharing, a proxy or a bridging feature can each do it, and each is a configuration that is either enabled or not. Inspect that state directly instead of inferring it from the presence of a VPN client. On a managed machine the answer is usually no, and verifying it converts an assumption into a fact worth recording.

Ask for One Resource, Not Two Networks

Most real requirements are narrower than they first appear: one console, one file share, one internal web application. State the requirement that way and let the owner of the resource decide whether it belongs on this endpoint at all. A request framed as two networks joining is difficult to approve and easy to refuse; a request for one named service has an answer.

If the answer is yes, prefer the narrowest supported path and keep it inside the organization's existing controls. A managed second profile or a scoped application entry preserves monitoring and policy; a competing personal configuration quietly replaces them, and nobody knows which one wins after the next update.

Include DNS and Route Effects

Name resolution changes the moment a second profile is active. A personal client may push its own resolver, a browser may use encrypted DNS of its own, and a policy table may route internal names to a different server than the corporate configuration expects. None of those requires forwarding, and any of them can send an internal hostname to the wrong place.

Resolve-DnsName intranet.corp.example -Type A
Get-DnsClientNrptPolicy -Effective
route print 0.0.0.0

Capture those three outputs before and after the second profile connects. The difference between them is the effect that actually reaches the user, and it is often larger than the routing change the ticket describes. Keep both captures so a later reviewer can see what changed rather than what was intended.

Verify and Keep a Way Out

Test the approved application from the real process and user context, not from an administrator shell on the same machine. Then confirm that unrelated destinations remain unreachable where the design requires it: a boundary nobody tested is a boundary nobody can claim. Disconnecting the personal tunnel should restore the previous state, and that restoration is worth checking while someone is still watching.

Test-NetConnection -ComputerName files.corp.example -Port 443
Get-NetConnectionProfile

The NIST guidance on zero-trust architecture is useful here because it removes network location as an automatic source of trust, which is exactly the assumption at issue. The question is not whether the home network is trustworthy by nature; it is who can reach which resource, from which endpoint, through which enforcement point. Answer those three, and keep the evidence with the decision.