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

A VPN (Virtual Private Network) creates an encrypted tunnel so your traffic can traverse untrusted networks more safely. In practice, you’ll encounter VPNs in remote access (users → company) and site-to-site links (office ↔ cloud/branch). If you manage VPN access, prioritize MFA, DNS/split-tunnel policy, and logging early—those decisions usually determine whether a VPN is a secure enabler or a recurring incident source.

How a VPN works

At a practical level, a VPN wraps your normal network traffic inside an encrypted, authenticated connection between two endpoints:

Client endpoint: typically a user device (laptop/phone) or a network gateway (firewall/router).
Server endpoint: a VPN concentrator, firewall, cloud VPN gateway, or dedicated VPN server.

Once the tunnel is established, traffic is routed through it according to policy. From the user’s perspective, they may appear to be “on” the corporate network (remote access VPN) or two sites may behave like one extended network (site-to-site VPN).

Core components (what’s actually happening)

Handshake / negotiation - The endpoints agree on a protocol (e.g., IPsec or TLS-based VPN), cryptographic parameters, and authentication method. - Authentication can be certificate-based, username/password, device certificates, or federated identity—often with MFA.
Encryption and integrity - Packets moving through the tunnel are encrypted to prevent eavesdropping and include integrity checks to detect tampering. - This matters most across untrusted networks (public Wi‑Fi, commodity ISP links, the open internet).
Encapsulation (tunneling) - Your original packet (e.g., destined for an internal app) is encapsulated inside a VPN packet. - The outside network only sees traffic between you and the VPN server, not the inner destinations.
Routing and access control - The VPN server decides what networks you can reach (e.g., only 10.20.0.0/16). - Split-tunnel vs. full-tunnel settings determine whether only corporate traffic or all traffic goes through the VPN.
Name resolution (DNS) considerations - A frequent source of security and usability issues is DNS: which DNS servers the client uses while connected. - Misconfigured DNS can leak internal lookups to public resolvers or break access to internal services.

Common VPN types you’ll see

Remote access VPN: user device connects to an organization’s network (classic “work from home” VPN).
Site-to-site VPN: two networks (e.g., branch office ↔ HQ, on-prem ↔ cloud) connect through gateways.
Client-based vs. clientless
Client-based: requires an installed app/agent (common for IPsec, WireGuard, many “SSL VPNs”).
Clientless: often browser-based for specific apps; less common now for broad network access.

Split tunnel vs. full tunnel (why admins care)

Split tunnel is a top decision point because it affects both security posture and bandwidth:

Full tunnel: all user traffic (including internet browsing) goes through the VPN.
Pros: centralized inspection, consistent egress IP, reduced data leakage risk.
Cons: higher bandwidth load on VPN infrastructure, potential performance impact.
Split tunnel: only specific routes go through the VPN; other traffic goes directly to the internet.
Pros: better performance and scalability.
Cons: increased exposure if endpoints are compromised; potential for DNS leaks; more complex troubleshooting.

A quick way to verify whether a client is full-tunnel is to inspect routes after connecting:

# Linux: view route table
ip route

# macOS: view routing table (simplified)
netstat -rn

# Windows: view routes
route print

If the default route (0.0.0.0/0) points to the VPN interface/gateway, you’re likely in full-tunnel mode.

When you’ll encounter a VPN

VPNs show up in day-to-day operations more often than many teams realize. Here are the most common scenarios security pros, IT admins, and SMB owners run into.

1) Remote work and contractor access

Employees and contractors use a VPN to access internal tools such as:

file shares, intranet portals, internal ticketing systems
admin interfaces (hypervisors, switches, firewalls)
private cloud resources (private subnets, internal load balancers)
legacy apps that aren’t internet-exposed

What to do next (admin checklist): - Require MFA for VPN authentication (and avoid SMS where possible). - Use device posture checks if available (managed device, EDR present, disk encryption). - Limit access with least privilege routes (don’t hand out broad 10.0.0.0/8 access by default). - Log VPN sessions and ship to SIEM.

If you’re hardening endpoints that will connect over VPN, pair this with a solid endpoint protection baseline; see our comparison of options for business PCs: best antivirus for windows business endpoints 2026.

2) Connecting offices, data centers, and cloud networks

A site-to-site VPN is a common bridge during migrations or for permanent hybrid setups:

branch office ↔ headquarters
on-prem ↔ cloud VPC/VNet
cloud ↔ cloud (when direct peering isn’t feasible)

Operational realities: - Performance depends on ISP quality and VPN crypto overhead. - MTU/fragmentation issues are common when encapsulation is involved. - Routing conflicts (overlapping RFC1918 ranges like 192.168.1.0/24) can break connectivity.

3) Using public Wi‑Fi or untrusted networks

A VPN is frequently used to reduce the risk of eavesdropping on untrusted networks. This is especially relevant when:

traveling
using hotel/airport Wi‑Fi
working from cafés
tethering through unknown networks

Important nuance: a VPN helps protect data in transit, but it does not automatically secure the endpoint, prevent phishing, or guarantee the VPN provider can’t see metadata. HTTPS still matters, endpoint security still matters, and identity security still matters.

If you’re looking for a consumer VPN for travel or coffee-shop Wi‑Fi: providers like NordVPN (Check NordVPN pricing →) or Surfshark (Try Proton VPN →) are common choices. For org-managed remote access, use a business-grade VPN/SSO/MFA approach rather than relying on consumer VPN apps.

4) Third-party integrations and vendor access

You may see VPNs used to connect with vendors for:

managed service access to your environment
B2B integrations (EDI-style connections, internal API access)
remote support channels to industrial/OT networks

Security considerations: - Prefer time-bound access and strong identity controls. - Monitor vendor sessions and restrict reachable subnets. - Avoid “always-on” broad network tunnels where possible.

Troubleshooting notes: common symptoms and log patterns

VPN issues tend to fall into a handful of buckets:

Authentication failures: wrong credentials, expired cert, MFA mismatch.
Phase 1/Phase 2 negotiation failures (IPsec): mismatched proposals, PSK/cert mismatch.
Routing/DNS problems: tunnel is “up” but nothing resolves or routes.
MTU problems: some apps work, others hang (especially large transfers).

Examples of signals to look for:

# General patterns (varies by vendor)
AUTH_FAIL / authentication failed
no proposal chosen / proposal mismatch
CHILD_SA / phase2 negotiation failed
peer not responding / DPD timeout
DNS request timed out / NXDOMAIN for internal names while on VPN

On endpoints, validate DNS settings after connecting:

# Linux (systemd-resolved environments)
resolvectl status

# macOS
scutil --dns

# Windows
ipconfig /all

If internal domains are being resolved by public DNS, that’s a red flag for DNS leakage or misconfiguration.

Practical takeaways (what to prioritize)

If you’re choosing or auditing a VPN setup, prioritize:

MFA everywhere (prefer app/hardware-based factors)
Least-privilege routing (narrow subnets and ports; avoid broad internal access by default)
Strong logging + monitoring (centralize session logs; alert on unusual geo/time/device patterns)
DNS and split-tunnel design (prevent leaks; ensure internal names resolve correctly)

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