VPN Definition: How It Works and When You’ll Use One

A VPN (virtual private network) creates an encrypted “tunnel” between your device (or network) and a VPN endpoint so traffic can cross the internet more safely. You’ll encounter a VPN in remote work, admin access, and site-to-site connectivity—especially when you need to reach private resources without exposing them directly to the public internet.

How a VPN works

At a high level, a VPN encapsulates your traffic inside another protocol and encrypts it so intermediate networks can’t read the contents. The VPN endpoint decrypts the traffic and forwards it onward.

The typical flow (remote-access VPN)

1. Client starts a VPN session - The user launches a VPN app (or OS-native VPN client) and selects a profile. - The client contacts the VPN gateway (corporate edge device or internet-hosted VPN server).

2. Authentication and key exchange - The client proves identity (credentials and often MFA such as push, TOTP, or a hardware key). - The client and server negotiate cryptographic parameters and derive session keys. - Common patterns include TLS-based handshakes (OpenVPN-style) or IKE/IPsec negotiation.

3. Tunnel establishment - The client creates a virtual network interface (often a “tun” interface). - The OS installs routes so specific traffic—or all traffic—goes into the tunnel.

4. Encapsulation + encryption - Original packets (e.g., TCP to an internal app) are encapsulated inside the VPN protocol. - Payloads are encrypted and integrity-protected. Intermediaries can usually still see that you’re using a VPN and the VPN server IP, but not the contents.

5. Decryption and forwarding at the VPN endpoint - The VPN gateway decrypts packets and forwards them:

   • To internal private networks (common for corporate VPNs), or
   • To the public internet (common for full-tunnel consumer-style routing)

6. Return traffic - Responses return to the gateway, are encrypted, and sent back through the tunnel to the client.

Routing choices: full tunnel vs split tunnel

• Full-tunnel VPN: All traffic (including internet browsing) goes through the VPN. This centralizes egress controls (filtering, inspection, egress policies) but increases bandwidth use and makes the VPN gateway a critical dependency.
• Split-tunnel VPN: Only traffic for specific networks (for example, 10.0.0.0/8) goes through the VPN; everything else uses the local network. This reduces load and latency but can introduce risk when devices are simultaneously on a corporate network path and an untrusted local network.

DNS and identity: common “gotchas”

• DNS handling: VPN profiles often push internal DNS servers and search domains. Misconfiguration can cause:
• Internal hostnames not resolving
• DNS leaks to local resolvers (privacy exposure and sometimes a policy violation)
• IP addressing: Clients are assigned a “virtual IP” from a pool. Overlapping IP ranges (home network and corporate network both using 192.168.1.0/24) can break access.
• Access control: Modern deployments often add:
• User/group authorization
• Device posture checks (OS version, EDR present, disk encryption enabled)
• Per-app/per-route entitlements

Quick ways to tell if a VPN is active

Check for a VPN interface and new routes.

# Linux: interfaces and routes
ip addr
ip route

# Linux: show WireGuard tunnels (if used)
wg show

# Windows: see active VPN connections
Get-VpnConnection
Get-NetIPInterface | Sort-Object InterfaceMetric
route print

# macOS: list network services and routes
scutil --nwi
netstat -rn

Look for: - A new interface (often tun0, utunX, ppp0, or vendor-named adapters) - New routes to private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) - DNS servers switched to corporate resolvers

When you’ll encounter a VPN

VPNs show up in everyday IT operations, security investigations, and small-to-mid business (SMB) network design.

Remote work and contractor access

The most common case: a user at home needs access to internal resources—file shares, ticketing systems, internal web apps, or admin tooling. IT uses a remote-access VPN to: - Reduce exposure of internal services to the public internet - Enforce authentication (often MFA) - Apply centralized security controls (where feasible)

Operational reality: VPN access becomes a choke point. Expect troubleshooting around: - MFA failures or token drift - Client updates breaking compatibility - DNS resolution failures for internal names - Conflicts with local networks and overlapping subnets

If your VPN authentication still relies heavily on reusable secrets, tighten credential hygiene first: see how do i create a strong password for a practical baseline.

Admin access and “break glass” connectivity

Admins use VPNs as a safer alternative to exposing management ports publicly. Examples: - RDP/SSH access without opening inbound rules to the internet - Access to internal management networks for firewalls, hypervisors, or OT systems

Security note: A VPN is not a substitute for least privilege. If an endpoint is compromised, VPN access can become a pivot into internal networks—especially with broad routes and weak segmentation. In incident response, teams often discuss the blast radius of a credentialed session; see what is the blast radius of a credential for how to reason about “what could this account reach?”

Branch offices and site-to-site links

A site-to-site VPN connects two networks (HQ and a branch) over the internet—usually between firewalls/routers. You’ll see this when: - SMBs add a second office without leased lines - Cloud networks (VPC/VNet) connect back to on-prem environments - Partners exchange data between networks

Common pain points: - MTU/fragmentation causing “some apps work, others hang” - Routing mistakes and asymmetric paths - PSK/key rotation and certificate lifecycle issues

Public Wi‑Fi and untrusted networks

Users often hear “use a VPN on coffee shop Wi‑Fi.” Practical benefits: - Protects traffic from local network snooping (especially for non‑TLS or misconfigured apps) - Reduces exposure to certain local attacker techniques (opportunistic interception)

Caveat: Most web traffic is already HTTPS. A VPN can still help by protecting DNS and reducing local visibility, but it does not automatically make unsafe browsing safe, and it won’t remove malware risk.

If you want a consumer VPN primarily for untrusted networks while traveling, providers like NordVPN or Surfshark are common options to compare: Check NordVPN pricing → and Try Proton VPN →.

Incident response and threat hunting

During investigations, VPN logs can be key evidence: - Who connected, when, from which IP, and using which device/client version - Failed logins, MFA challenges, unusual geo/ASN, impossible travel - Session duration and assigned virtual IPs (useful for correlating internal activity)

Log patterns you’ll commonly look for

Vendor formats vary, but you’ll commonly see: - Successful authentication (user, source IP, MFA result) - Tunnel established (virtual IP assigned) - Tunnel teardown (duration, bytes in/out) - Policy decisions (allowed/denied routes, posture check pass/fail)

A quick IR checklist: - Identify the user account and source IP - Confirm MFA result and method - Extract assigned VPN IP to correlate with internal logs - Check for new device fingerprints or unusual client versions - Review concurrent sessions and connections outside normal hours

VPN protocols and related terms

• Remote-access VPN: A device connects to a VPN gateway to reach internal networks.
• Site-to-site VPN: Two networks connect via VPN gateways, forming a persistent tunnel.
• IPsec: A suite of protocols used for VPNs (especially site-to-site); commonly negotiated with IKE/IKEv2.
• WireGuard: A modern VPN protocol focused on simplicity and performance; uses public-key cryptography.
• OpenVPN: A widely used VPN that typically runs over TLS; flexible and common in enterprise/SMB deployments.
• SSL VPN / TLS VPN: VPNs using TLS transport; often delivered via client apps or browser portals.
• MFA (Multi-Factor Authentication): Additional verification often required for VPN access.
• Split tunneling: Routing only some traffic through the VPN; improves performance but can increase risk.
• DNS leak: DNS queries go to local resolvers instead of the VPN’s intended DNS servers.
• ZTNA (Zero Trust Network Access): An alternative approach providing app-level access rather than broad network-level connectivity.

Practical security tips (what actually improves outcomes)

• Use MFA everywhere the VPN is exposed (and prefer phishing-resistant options when possible).
• Limit routes: avoid “entire internal network” access unless it’s required.
• Log and alert on unusual sources, new devices, and repeated failures.
• Harden endpoints: VPN security is only as strong as the connecting device.
• Use a password manager for unique VPN credentials (especially for admin access). 1Password is a popular option: Try 1Password →.
• Pair with anti-malware/EDR for devices that connect from unmanaged networks. Malwarebytes is a widely used choice: Get Malwarebytes →.

---

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.