Network Security
Intermediate 16 min read Network Security
VPNs and Secure Remote Access
How remote users reach internal resources safely: site-to-site vs remote-access VPNs, WireGuard vs IPsec vs TLS, and the zero-trust cloud alternative.
VPNWireGuardIPsecremote accesstunnelingzero trust access
Introduction
What is this?
A VPN extends a private network over the internet by encrypting packets between endpoints; remote-access designs protect roaming users, site-to-site designs link offices via secure tunnels.
Motivation
Why do you need it?
- Remote work made the VPN the front door of most enterprises — it gets attacked before anything else.
- Choosing VPN tech (IPsec vs WireGuard vs TLS-based ZTNA) is a daily architecture trade-off.
- Tunneling teaches routing and security at once: what rides over what, and who controls the endpoint.
Think about it
Mental model
Imagine
Remote-access VPN
Think of
A courier who only shares documents inside a locked case
The case is checked at the door; inside, the pages are protected by the latch, not by trust in the road.
Mechanics
How it works
- The client builds a cryptographic tunnel to a concentrator/gateway, which demultiplexes encrypted packets onto the internal network.
- IPsec ESP tunnels encrypt the payload of each packet; IKE negotiates keying between peers.
- WireGuard uses static public keys + a lightweight handshake (Curve25519/ChaCha20) — dramatically simpler than IPsec to operate.
- ZTNA/cloud access brokers sit between identity and the app, letting remote users reach only the named service without a blanket inside-network presence.
Path of a packet through a remote-access tunnel
ClientVPN agent encrypts packet to gateway
Internetencrypted outer header only
Gatewayauthenticates client, terminates tunnel
Insideplaintext packet flows to internal host
Replysame path in reverse
Real world
In production
- A company flicked a WireGuard setup live for 200 remote engineers in a day; IPsec had taken their old team a quarter.
- A finance VPN enforces MFA at the gateway and time-boxes session lifetime to 8 hours.
- A cloud-first org replaced most VPN usage with cloud ZTNA: users reach only their assigned apps per identity policy.
Guidelines
Best practices
- Enforce MFA at VPN login; a VPN drops a credential, and MFA is the wall behind it.
- Rotate keys/certificates on a schedule and revoke per-user access instantly on termination.
- Tunnel split-tunnel policy deliberately: full-tunnel for sensitive data, split for casual browsing.
- Keep the gateway's own patch level boring and current — it is the highest-value target in the network.
Watch out
Common mistakes
- Using default preshared keys or long-term certs with no rotation — a leak of the key unwraps every tunnel.
- Forgetting split vs full tunnel means exfil rides the same tunnel: the corporate 'safe lane' becomes the export lane.
- Deploying VPN without MFA because 'the laptop is managed' — until a laptop gets stolen with a saved credential.
- Caring only about ingress consoles and leaving VPN ports open to the whole internet with old software.
When things break
Debugging tips
- Ping the tunnel address, then the internal host: the split tells you where the failure lives (tunnel vs inside).
- WireGuard 'Handshake didn't complete' means clock skew or wrong endpoint — check system time and public key.
- Sort timestamps on gateway logs; asymmetric routes commonly break stateful VPN filters.
Security
Security considerations
- Run VPNs only on infrastructure you operate; connecting to unknown public rendezvous is a covert-channel risk.
- Log and limit concurrent sessions; alert on a single credential creating many tunnels.
- Treat the VPN as the perimeter: combine with device posture checks, not trust in the tunnel itself.
Interviews
Interview checkpoint
Test yourself
Quick quiz
0/2
1
Which property is NOT provided by a VPN tunnel by itself?
2
WireGuard's cryptographic primitives include...
Go deeper