VPN & ZTNA

Remote access used to mean one question: are you inside the tunnel? If yes, you got the LAN. If no, you got nothing. That model is still running in most companies — and it's still wrong for most workloads. This level walks the evolution from the classic perimeter VPN to Zero Trust Network Access (ZTNA), using the same four-tuple every identity-aware proxy actually evaluates: (user, app, device posture, network).

Analogy

A castle with a drawbridge is a perimeter. Once you're across the moat, you can wander the great hall, the kitchens, the armoury, the crown jewels. Guards at the drawbridge do one big check — "is this person on the list?" — and then nothing after.

A museum with one attendant per exhibit is zero-trust. Every room has its own ticket-taker who inspects your ID, checks the type of ticket you're carrying, and peeks at the lanyard to make sure your visit is still valid. You can't "break into" the Renaissance wing just because you're inside the lobby.

The castle is a VPN. The museum is ZTNA.

The classic VPN

A VPN (Virtual Private Network) opens an authenticated, encrypted tunnel from your laptop into the corporate network. Anything on the corporate LAN is then reachable over the tunnel: file shares, Jira, internal DNS, the dev database. The access-control check happened once, at tunnel-setup — after that the packets flow unchecked.

Two sub-flavours matter:

• Full-tunnel — every packet, including google.com, travels through the corporate VPN gateway. Corporate DNS and DLP see everything; home-internet latency gets added to your YouTube. Still useful for regulated environments that want one egress point.
• Split-tunnel — only traffic to corporate CIDRs / DNS suffixes enters the tunnel. Your home traffic stays home. Lower latency, less egress cost, but now you need to be careful: corporate DNS names that accidentally resolve on the split-out path, or routing overlaps between home networks (192.168.1.0/24) and corp subnets, will silently bypass the tunnel.

Classic VPN products: Cisco AnyConnect, Palo Alto GlobalProtect, OpenVPN, WireGuard, Pulse Secure, Fortinet FortiClient. They're a shared commodity — the protocol is solid; the policy model is the problem.

Why the perimeter leaks

Two failures kill the "trust the tunnel" model:

1. A flat LAN is too wide a grant. Once the laptop's on the corporate subnet, it can talk to anything the subnet can reach: the HR Oracle server, the dev cluster, the printer with the default password. The 2013 Target breach started with an HVAC vendor's VPN account.
2. Device posture is invisible. The laptop could be full of malware, patched three years ago, with USB auto-run enabled — the VPN gateway has no idea. It authenticated the user, not the machine.

Once your workforce is mostly remote, the LAN is everywhere anyway. A perimeter you can't draw is a perimeter you can't defend.

Enter BeyondCorp

In 2014 Google published "BeyondCorp: A New Approach to Enterprise Security." The idea: stop trusting the network. Every request — not every tunnel, every request — is authenticated against identity + device posture, and authorised per-app by policy. The corporate VPN goes away; an identity-aware proxy (IAP) sits in front of each app.

Four posture signals usually flow in:

• Identity — who is this, from which SSO (Okta / Entra ID / Google) with what groups?
• Device — is this a company-managed laptop (MDM-enrolled in Intune / Jamf / Kandji)? Patch level? Disk encryption on? EDR running?
• Context — geolocation, time of day, impossible-travel, risk score from the IdP.
• App sensitivity — a wiki page is not the production database; policy scales with blast radius.

ZTNA is the productisation of BeyondCorp. Real products:

• Cloudflare Access — anycast identity-aware proxy; free tier works at small-business scale.
• Tailscale — WireGuard mesh with ACLs on identity + tags; closer to "VPN done right" than a classic ZTNA.
• Zscaler Private Access (ZPA) — enterprise ZTNA, broker-based, one of the largest deployments globally.
• Google BeyondCorp Enterprise — the canonical one, sold as a Chrome-integrated service.
• Cisco Secure Access / Duo Network Gateway — Cisco's pivot from AnyConnect to ZTNA.
• Palo Alto Prisma Access — cloud-delivered SASE with ZTNA and VPN side-by-side.

VPN vs ZTNA at a glance

	VPN	ZTNA
Trust boundary	The tunnel	The request
Network posture	Required (you must be inside)	Irrelevant
Device posture	Not checked	Checked per request
Lateral movement	Whole LAN reachable	Only the specific app
Protocol support	Any TCP/UDP	Mostly HTTP(S), SSH, RDP
Revocation	Kill the session	Deny the next request (instant)
Typical failure	Stolen creds → LAN access	Stolen creds → one app until posture fails

ZTNA is not strictly better. For non-HTTP legacy protocols (SMB to a fileshare, arbitrary TCP to a homegrown daemon) a VPN is still the cheapest thing that works. Most shops run both: VPN for the long tail, ZTNA for the apps that matter.

Gotchas in the field

• Split-tunnel DNS leaks. Your split-tunnel sends *.corp through the VPN but google.com out the side. If internal.corp.com has a public DNS record too, the resolver may win the race and the connection takes the wrong path, bypassing DLP. Use DNS suffix routing + split-horizon DNS or just full-tunnel for regulated subsets.
• ZTNA policies that lock admins out. The policy says "device must be MDM-enrolled + Okta group = engineering". Then MDM goes down, or the Okta group is renamed. The admin who could fix it is on the same policy. Keep a break-glass identity outside the policy chain — hardware-token local account, IP-allowlisted.
• Session persistence vs re-auth. A VPN session lives for hours; revoking it means kicking the tunnel. ZTNA re-evaluates on each request, so revocation is instant — but aggressive session TTLs feel like friction. Tune to minutes for sensitive apps, hours for the wiki.
• Non-compliant !== malicious. A compliant device that missed last week's patch shouldn't be treated the same as an unmanaged personal laptop. Tier posture signals; don't collapse them into one bit.
• "Zero-trust" is a posture, not a product. Vendors sell "zero-trust" everything; the architecture is a set of decisions (authenticate every request, assume-breach the network, policy-per-app). Check the decisions, not the sticker.

The evaluation

The playground asks you to classify requests. The rule set the playground uses is the same one the challenge grades against:

1. Public marketing pages → direct (no identity).
2. Sensitive app + non-compliant or unknown posture → denied.
3. Production database → always ztna (per-request posture).
4. Intranet / corp GitHub from off-network → ztna (BeyondCorp — the network doesn't matter).
5. SaaS CRM on corp wifi + compliant → direct (vendor SSO is enough).
6. Anything else sensitive on corp wifi → vpn (legacy perimeter, still cheap).
7. Everything else sensitive + compliant off-network → ztna.

The visualizer shows the two architectures side-by-side. A VPN-routed request travels user → gateway → app inside the trust ring. A ZTNA-routed request travels user → identity-aware broker → per-app proxy, with the network dropping out of the picture entirely.

The one-line rule

If the network decides whether the request is allowed, it's a VPN. If the request decides, it's ZTNA. The future of corporate access is requests, not tunnels — but the tunnel is still the right tool for the long tail of legacy protocols that never learned to authenticate themselves.