A VPN is a tunnel with authentication at both ends. That is the entire promise. Everything it does well — confidentiality on untrusted networks, a stable address for a remote site, access to internal services — follows from those two properties.
Everything it does badly follows from people assuming it does more.
What the tunnel provides
| Property | What it means | What it does not mean |
|---|---|---|
| Confidentiality | Transit cannot be read | The endpoint is uncompromised |
| Integrity | Transit cannot be modified undetected | The application is trustworthy |
| Authentication | The ends are who they claim | The user is authorized for everything |
| Addressing | A remote host appears internal | The host is patched |
A VPN moves the trust boundary. It does not remove it. Once a device is on the tunnel it is on your network, which is exactly why "VPN access" and "network access" should not be synonyms.
A VPN is not anonymity
Commercial VPNs sell privacy from an ISP. An enterprise VPN does the opposite: it authenticates you, logs your session, and routes your traffic through a device your employer controls. Confusing the two is a common and consequential mistake.
Three shapes
| Shape | Connects | Typical use |
|---|---|---|
| Site-to-site | Two networks | A new campus back to the district |
| Remote access | One device to a network | Staff working from home |
| Clientless / proxy | One application to a user | Publishing a single internal app |
Site-to-site is a routing problem with encryption attached, which is why the routing series and this one overlap. Remote access is an identity and endpoint problem with encryption attached, which is why it keeps colliding with zero trust.
The threat model, stated plainly
A tunnel is worth its complexity when traffic crosses a network you do not control:
- A teacher's home internet, where the ISP and the coffee-shop Wi-Fi are both untrusted.
- A vendor's connection into a controller, where the alternative is an open management port.
- A point-to-point link over the public internet, where a fiber cut forced a temporary path.
It is not worth much when both ends are already inside your perimeter, and it is actively harmful when it turns a compromised laptop into an internal host with full access.
What it does not solve
- Authorization. Being on the VPN should not mean reaching every subnet. The zone model applies inside the tunnel too.
- Endpoint hygiene. A patched, managed device and an unmanaged one look identical to the tunnel.
- Lateral movement. Once inside, the tunnel does not stop a compromised host from scanning.
- Filtering. Split tunneling can bypass content filtering entirely, which in a district is a policy problem, not a technical one.
Worked example: a teacher at home
Before: the laptop uses the home network, reaches Google Workspace directly over TLS, and reaches the student information system through a public portal with MFA.
Does it need a VPN? For those two services, no — both are designed for the internet and are protected by TLS and identity. A tunnel would add latency and route district traffic through a district appliance for no security gain.
It does need one for the file share and the print server, which were never designed to be exposed.
That is the useful question: which service requires network-level access, and can it be moved to identity-level access instead? Every service you move removes a reason for a tunnel.
What breaks in production
- VPN as a flat network. Full tunnel plus full access is a remote office, not a security control.
- Shared credentials. One account for a whole department makes the audit meaningless.
- No device check. Any device with the password gets in.
- Split tunneling without policy. Filtering and logging stop at the tunnel boundary.
- The VPN appliance as a single point of failure, with no tested alternative.
Checklist
- You can name which services require the tunnel and why.
- Authorization inside the tunnel follows the same zones as inside the building.
- Access requires a named identity, not a shared credential.
- Device posture is checked, or explicitly accepted as a risk.
- Split tunneling is a documented decision with a filtering plan.
- The failure of the VPN appliance has been tested.
Next
The mechanics start with the protocol most site-to-site links use. Continue with IPsec Without the Acronym Soup.