How VPNs Actually Work

VPNs are marketed with language that ranges from technically vague to outright misleading. One ad says a VPN makes you anonymous. Another says it secures public Wi-Fi. Enterprise documentation talks about site-to-site tunnels, policy routing, split tunneling, and MSS clamping. All of those statements point at something real, but they are talking about different layers of the problem.

A VPN is not one specific protocol. It is a design pattern: create a virtual network interface, capture packets that would otherwise leave normally, encapsulate them inside another transport, send them to a tunnel endpoint, decapsulate them there, and then forward them onward according to the policy of that endpoint. Sometimes the goal is privacy from the local network. Sometimes it is secure access to a corporate subnet. Sometimes it is connecting two offices over the public internet. Sometimes it is forcing all outbound traffic through a provider in another country.

This article explains the mechanism beneath the marketing. We will cover TUN and TAP interfaces, WireGuard's Noise-based handshake, the difference between IPSec tunnel mode and transport mode, why MTU problems keep appearing in VPN deployments, how split tunneling is implemented, and the exact boundary between what a VPN does protect and what it absolutely does not.

The Tunnel Is a Virtual Network Device

Most VPN implementations start with a virtual interface.

On Unix-like systems the common abstraction is:

• TUN for layer-3 packets such as IP
• TAP for layer-2 Ethernet frames

A TUN device behaves like a point-to-point IP interface implemented in software. The kernel routes packets to it as if it were a normal network adapter. User-space or kernel VPN code reads those packets, encrypts and encapsulates them, and sends the resulting ciphertext over a real NIC such as Wi-Fi or Ethernet.

A TAP device sits one layer lower. It carries Ethernet frames, which makes it useful when a VPN needs to bridge layer-2 semantics such as broadcasts, ARP, or legacy software that expects to be on the same Ethernet segment. TAP is more flexible but also noisier and often less desirable on the public internet because it drags L2 behavior across a tunnel.

WireGuard is almost always used with TUN semantics. OpenVPN can use either TUN or TAP. Enterprise remote-access products often use virtual layer-3 adapters because they are simpler to route and scale.

Routing Decides Which Packets Enter the Tunnel

Creating the virtual interface does nothing until the routing table points traffic at it.

That is the real control point. Suppose the system has:

• eth0 for the normal uplink
• wg0 for a WireGuard tunnel

If the route to 10.0.0.0/8 points at wg0, packets for that private network go into the tunnel while everything else still exits via eth0. If the default route 0.0.0.0/0 points at wg0, then almost all outbound traffic enters the tunnel unless more specific routes override it.

This is why VPN behavior is really routing behavior wrapped in encryption. The tunnel endpoint is not "magically intercepting" packets. The host is simply told that some destinations are reachable through the virtual interface, and the packets are then encapsulated on the way out.

Encapsulation Means One Packet Carries Another

At the heart of a VPN is encapsulation.

An inner packet might look like:

• source 10.6.0.2
• destination 10.10.20.15
• TCP segment carrying some application payload

The VPN software takes that inner IP packet, encrypts it, wraps it inside an outer transport, and sends an outer packet such as:

• source 203.0.113.8
• destination 198.51.100.40
• UDP destination port 51820
• encrypted tunnel payload

The outer network only sees traffic between the tunnel endpoints. It does not see the original inner destination or application payload. At the far side, the VPN peer decapsulates the packet, validates and decrypts it, reconstructs the inner IP packet, and injects that packet into its own networking stack for onward forwarding.

A VPN can create the illusion that a host on one network segment is logically attached to another for that reason. The tunnel transports packets as payload.

WireGuard Keeps the Protocol Small on Purpose

WireGuard became popular partly because it avoids the giant configuration and negotiation surface of older VPN stacks.

At a conceptual level WireGuard does four important things:

1. identifies peers by static public keys
2. uses a Noise-based handshake to derive fresh symmetric session keys
3. transports encrypted packets over UDP
4. associates allowed inner IP prefixes with each peer

That last point matters more than many introductions admit. In WireGuard, peer configuration is both a crypto identity statement and a routing policy statement. If a peer is configured with AllowedIPs = 10.0.0.0/24, then packets for that inner prefix are associated with that peer. The implementation uses that mapping to decide which peer should receive which inner packet after encryption.

The result is refreshingly direct. There is no sprawling control channel full of feature negotiation. A peer has a public key, an endpoint, and a set of inner prefixes it is allowed to source or receive.

The WireGuard Handshake Comes From the Noise Framework

WireGuard's cryptographic handshake is based on the Noise framework, specifically the IK pattern with protocol-specific details. You do not need to memorize the entire transcript to understand what it buys.

The handshake aims to establish:

• mutual authentication using static public keys
• forward secrecy through fresh ephemeral keys
• key confirmation
• replay protection
• rapid rekeying for ongoing sessions

In broad terms:

1. the initiator sends an ephemeral public key plus encrypted identity material
2. the responder derives shared secrets, authenticates the initiator, and replies with its own ephemeral contribution
3. both sides derive symmetric transport keys
4. data packets then use those transport keys until the session is rotated

WireGuard also uses a cookie mechanism to reduce denial-of-service pressure from spoofed handshake floods. The responder can require a returning client to prove reachability before it commits significant resources to repeated handshake processing.

The elegance of WireGuard is that the handshake is small, opinionated, and tightly bound to the transport. There is no giant menu of ciphersuites, certificate chains, or legacy compatibility branches. That simplicity is a large part of its security story.

Data Packets Are Separate From Handshake Packets

After the handshake, ordinary data packets are much simpler. Each packet carries:

• a type field
• key identifier information
• counter / nonce material
• encrypted payload
• authentication tag

The receiver uses the key identifier to pick the correct session state, checks replay windows, decrypts, validates integrity, and then reinjects the recovered inner IP packet.

Notice what does not happen. The receiver does not "re-run the whole handshake" for every packet. The expensive asymmetric work is amortized. Once a session exists, data movement is just symmetric AEAD processing plus packet bookkeeping.

That matters for performance. It is one reason WireGuard usually feels light compared with older userspace VPNs carrying more framing overhead and a more complex control plane.

IPSec Solves the Same Problem With More Building Blocks

IPSec predates WireGuard and covers a broader architectural space. It is really a suite of components:

• IKE or IKEv2 for key exchange and security association setup
• ESP for encrypted packet transport
• AH for authentication without encryption, rarely used in practice today
• transport mode and tunnel mode

The design is powerful, mature, and common in enterprise networks. It is also heavier mentally because there are more moving parts and many historical deployment variants.

Transport Mode

In transport mode, IPSec protects the payload of the original IP packet while leaving the original IP header largely in place. That means the endpoints are the actual source and destination hosts.

This is a host-to-host protection model:

• original source and destination stay visible to the network
• the packet payload is protected
• useful when the communicating hosts themselves are the IPSec endpoints

Tunnel Mode

In tunnel mode, the entire original IP packet becomes the inner payload, and a new outer IP header is added for the tunnel endpoints.

This is the classic VPN model:

• outer header shows gateway-to-gateway or client-to-gateway transport
• inner packet preserves the original source and destination
• common for site-to-site VPNs and remote access

If you remember only one distinction, remember this: transport mode protects a conversation between the real endpoints, while tunnel mode carries one packet inside another between security gateways or tunnel peers.

Site-to-Site and Remote Access Have Different Goals

A site-to-site VPN usually connects whole routed networks.

Example:

• office A has 10.1.0.0/16
• office B has 10.2.0.0/16
• each office has a gateway device
• the gateways build a tunnel and advertise the remote prefixes

Hosts inside each office may not even know a VPN exists. They just route traffic for the remote subnet toward their local gateway, which handles encapsulation and encryption.

Remote-access VPNs are different. One endpoint is often a laptop or phone. The tunnel gives that single device access to selected internal resources or forces its general internet traffic through the company edge. That introduces client concerns such as DNS behavior, local LAN access, split tunneling policy, and roaming between networks.

The underlying mechanics overlap, but the operational tradeoffs do not. Site-to-site is mostly about routing between networks. Remote access is also about endpoint trust, posture, and user experience.

MTU Problems Are Not Optional; They Are Structural

VPN administrators eventually learn the same lesson: encapsulation costs bytes.

If an inner packet was already near the path MTU, wrapping it inside UDP, ESP, or another outer header can make the resulting outer packet too large for some link in the path. Then one of several bad things happens:

• fragmentation occurs, hurting performance and reliability
• ICMP "fragmentation needed" messages are blocked, so PMTUD fails
• packets black-hole silently

This is why a VPN that "works for most sites" can mysteriously stall on large transfers, HTTPS handshakes, or protocols with big packets. The small packets succeed. The larger ones hit the MTU cliff.

The practical fixes are:

• lower the tunnel MTU
• clamp TCP MSS on the tunnel path
• ensure PMTUD messages can return
• avoid unnecessary encapsulation layers

For example, if WireGuard rides over IPv4 plus UDP, the usable inner MTU is lower than the physical interface MTU by the size of the outer headers and WireGuard overhead. Set the tunnel MTU too high and you get intermittent pain that looks like "some applications hang for no obvious reason."

Split Tunneling Is Just Selective Routing

Split tunneling sounds policy-heavy, but technically it is simple: some destinations use the tunnel, others use the normal local uplink.

This can be implemented by:

• installing routes only for internal subnets
• leaving the default route on the local network
• using policy routing to steer selected traffic classes differently

In a corporate setup, split tunneling often means:

• 10.0.0.0/8 via the VPN
• 0.0.0.0/0 via the local gateway

That reduces bandwidth pressure on the corporate concentrator and lets the user reach the public internet directly. It also reduces the organization's visibility and control, and it can create security concerns if the device is simultaneously attached to an untrusted local network and sensitive internal resources.

Full tunneling does the opposite: the default route also points through the VPN, so all traffic exits from the remote gateway. That is useful when the organization wants inspection, logging, geographic egress consistency, or protection on hostile local networks. It is more expensive and can introduce hairpin latency for ordinary web traffic.

DNS Leaks Are a Routing and Resolver Problem

Many users think "my IP is hidden" implies "my DNS is hidden." That is only true if DNS resolution also traverses the tunnel or is otherwise securely protected.

A DNS leak happens when:

• application traffic goes through the VPN
• DNS queries still go to the local network resolver

That local resolver may reveal which domains the user is accessing even if the HTTP or TCP packets themselves are tunneled. The fix is not mystical. The system must be configured so that the active resolver for relevant traffic is reachable through the tunnel, or DNS itself must be encapsulated securely inside the VPN policy.

Browsers and operating systems complicate this further with:

• DNS over HTTPS
• DNS over TLS
• application-specific resolver behavior
• split DNS for corporate zones

VPN design therefore cannot stop at packet encryption. Name resolution must be considered explicitly.

What a VPN Actually Protects

A well-configured VPN can protect several concrete things:

From the local network

The coffee-shop Wi-Fi, hotel network, or ISP access link sees encrypted traffic to the VPN endpoint instead of cleartext application payload and ordinary destination IPs for tunneled traffic.

From path observers between you and the tunnel endpoint

Anyone watching the outer transport path sees that you are using a VPN and where the tunnel endpoint is, but not the inner packet contents.

For access control

A VPN can extend private address space and authenticated reachability to remote hosts, making internal subnets available only to authenticated tunnel peers.

For egress location

If all traffic exits from the remote gateway, websites see the gateway's public IP, not the client's local IP.

These are valuable properties. They are also much narrower than many advertisements imply.

What a VPN Does Not Protect

A VPN does not make you generically anonymous. The destination can still identify you by:

• account login
• cookies
• browser fingerprinting
• application telemetry
• uploaded documents and metadata

A VPN does not make malware disappear from the endpoint. If the machine is compromised, the malware can exfiltrate data over the tunnel, around the tunnel, or before the tunnel starts.

A VPN does not stop the VPN provider or corporate gateway from seeing metadata it terminates. In fact, it moves trust:

• without a VPN, the ISP sees more
• with a VPN, the provider or organization running the tunnel endpoint sees more

A VPN also does not protect traffic that never enters the tunnel because of:

• split tunnel policy
• local subnet exceptions
• misconfigured routes
• DNS leaks
• application bypass behavior

The right question is therefore not "does a VPN make me safe." It is "which observer loses visibility, which observer gains visibility, and which traffic categories are actually inside the tunnel."

Performance Is Mostly About Crypto, Copies, and Path Shape

VPN performance depends on several layers:

• handshake cost, usually amortized
• per-packet encryption and authentication cost
• userspace versus kernel implementation overhead
• extra copies between kernel and userspace
• MTU and fragmentation behavior
• the geographic path to the tunnel endpoint

WireGuard often performs well because it lives in the kernel on many platforms, uses modern AEAD primitives, and keeps framing simple. OpenVPN in userspace over TCP can perform much worse, especially when TCP-over-TCP pathologies appear. IPSec can perform extremely well with hardware offload and mature gateway appliances.

Latency also matters. A "secure" full tunnel that sends all traffic to a far-away gateway may add so much RTT that the user experience degrades even if throughput remains fine. This is why many remote-access deployments use regional concentrators or selective routing.

Roaming and NAT Traversal Matter in the Real World

Modern clients move between Wi-Fi and cellular, sit behind NAT, and change outer IP addresses frequently. WireGuard handles this elegantly by binding peer identity to keys rather than to a long-lived fixed session tied to one outer address. When a valid packet arrives from a new source address, the peer can update the remembered endpoint.

That is operationally important. It means the encrypted relationship survives network changes more gracefully than older designs that were more tightly coupled to session state built around the original 5-tuple.

NAT traversal is another reason UDP is popular for VPN transports. Encapsulating in UDP makes it easier to pass through many middleboxes and keep mappings alive with periodic keepalives when needed.

There Is Always a Control Plane and a Data Plane

It helps to separate every VPN into two conceptual planes:

• the control plane, which establishes identity, keys, and policy
• the data plane, which carries encrypted traffic after that setup exists

WireGuard compresses the control plane aggressively, which is one reason it feels simple. IPSec historically exposes a much richer control plane because IKE negotiates algorithms, identities, security associations, lifetimes, and many policy knobs. SSL VPN products often add an even more application-shaped control plane with portals, posture checks, device enrollment, and per-resource authorization.

This distinction matters because many deployment issues are not packet-encryption issues at all. They are control-plane issues:

• the client authenticated, but got the wrong routes
• the peer identity is correct, but the tunnel policy does not include the expected subnet
• keys are valid, but rekey timing creates short outages
• the data plane is fine, but the management plane pushed broken DNS servers

In operations, people often say "the VPN is down" when the data path is actually healthy and only the control-plane policy is wrong. Breaking that habit makes troubleshooting faster.

WireGuard's Simplicity Comes From Removing Negotiation Surface

Older VPN stacks often spend significant control-plane effort negotiating options:

• which cipher suite to use
• which hash to use
• which authentication mode to prefer
• whether to compress
• whether to use one extension or another

WireGuard largely refuses that complexity. The protocol is intentionally opinionated. That has several consequences:

Fewer downgrade edges

If the peers are not negotiating a huge menu of legacy options, there are fewer opportunities for misconfiguration or downgrade behavior to leave the session using something weaker than the operator intended.

Smaller implementation surface

Less feature negotiation means fewer parser paths, fewer state transitions, and fewer "if peer supports X but not Y" branches. This helps both auditability and performance.

Less flexibility for odd enterprise needs

The same simplicity can frustrate organizations that expect certificate hierarchies, X.509-heavy identity policy, or dozens of enterprise knobs wired into the tunnel protocol itself. WireGuard often solves those needs outside the protocol rather than inside it.

That tradeoff is part of understanding why WireGuard and IPSec coexist instead of one having completely replaced the other. They optimize for different operational philosophies.

A Packet Capture Explains More Than Most VPN Documentation

One of the fastest ways to understand a VPN is to think in terms of what tcpdump or Wireshark would show on each side of the tunnel.

On the client's physical interface

You would see:

• outer source IP equal to the client uplink
• outer destination IP equal to the VPN peer or gateway
• UDP or ESP packets depending on the protocol
• encrypted payload blobs

You would not see:

• the original inner destination IP for tunneled traffic
• the inner transport headers in plaintext
• the application payload

On the virtual tunnel interface

You would see:

• the inner source and destination addresses
• the normal IP packet exactly as the routed stack handed it to the tunnel
• no outer transport wrapper yet

On the far-side egress interface

After decapsulation you would again see:

• the recovered inner packet
• then, if the gateway forwards it onward, a normal outgoing packet toward the real destination

That packet-capture mental model makes several confusing statements concrete:

• "the coffee shop sees the VPN, not the website"
• "the website sees the gateway IP, not the client uplink"
• "the gateway can see more than the local ISP once the tunnel terminates there"

If you can picture the capture points, most VPN trust questions become much easier.

Full Tunnel, Split Tunnel, and Excluded Routes Are Policy, Not Magic

Users often treat tunnel mode as a binary. In practice it is a matrix of route decisions.

Consider a laptop with:

• default route via eth0
• internal corporate routes via wg0
• a specific exclusion route for the local printer subnet

That laptop is simultaneously:

• tunneled for some destinations
• local for others
• intentionally bypassing the VPN for still others

Enterprise clients frequently add special-case routes for:

• local LAN access so printers and meeting-room devices still work
• DNS resolvers
• SaaS services that should stay direct for performance reasons
• management networks

These policies can be reasonable. They also create blind spots. If the user believes "the VPN is on, therefore everything goes through it," excluded routes can defeat that assumption. Strong VPN products and admin consoles therefore try to make route policy explicit rather than leaving it as hidden system state.

Kill Switches Are Just Route and Firewall Enforcement

Consumer VPN apps love the phrase "kill switch," but technically it usually means one of two things:

1. remove or block all non-tunnel routes when the tunnel is down
2. install firewall rules that prevent traffic from leaving except via the VPN interface or toward the VPN endpoint itself

Without that enforcement, a tunnel outage can cause silent fallback to the ordinary local uplink. That may be acceptable in some enterprise setups. It is not acceptable if the operator's threat model assumes traffic must never leave outside the tunnel.

Kill switches therefore answer a specific failure-mode question:

"If the encrypted path drops unexpectedly, what does the host do next?"

Possible answers are:

• fail closed and send nothing
• fail open and use the local network
• allow only selected destinations outside the tunnel

Again, this is not mystical. It is routing and firewall policy shaped around a failure event.

TCP-over-TCP Is Usually a Bad Idea

One of the oldest VPN performance traps is tunneling TCP traffic inside another TCP transport, commonly seen with some older SSL VPN designs.

Why it hurts:

• inner TCP sees loss and backs off
• outer TCP also sees loss and backs off
• both layers retransmit and run congestion control independently
• latency spikes and head-of-line blocking amplify each other

This is why UDP-based transports are so common for VPNs. When the outer layer is UDP, the inner TCP session owns congestion control for the application data. There is still overhead and there can still be packet loss, but there are not two independent reliable transports fighting over the same path behavior.

OpenVPN over TCP can still be useful in restrictive environments where UDP is blocked. It is just something you use because the network forces you to, not because it is an elegant transport design.

Enterprise VPNs Often Need More Than Basic Tunneling

Consumer VPN discussion focuses on egress IP changes and last-mile privacy. Enterprise remote access usually wants a different bundle of outcomes:

• authenticated access to specific internal subnets
• device identity and posture checks
• per-application or per-resource authorization
• audit logging
• DNS policy for private zones
• access revocation tied to user lifecycle

This is why enterprise clients often feel heavier. They are not just setting up a tunnel. They are acting as a policy distribution and compliance endpoint. The tunnel is only one piece.

In modern zero-trust-style environments, some products go further and avoid the traditional "entire subnet reachability" model altogether. Instead of extending broad network access, they create per-application paths or brokered connections. The user still experiences something that feels VPN-like, but the access model is much narrower than a classic routed tunnel.

That distinction matters because "VPN" in corporate conversation sometimes means:

• an actual layer-3 tunnel with route injection
• a per-app tunnel on mobile
• a browser-based access proxy with no general IP reachability

All three are trying to solve secure remote access, but they are not architecturally identical.

Overlapping Address Space Breaks Naive Site-to-Site Designs

Site-to-site VPN diagrams in documentation often assume:

• site A has 10.1.0.0/16
• site B has 10.2.0.0/16

Reality is messier. Plenty of organizations discover that two offices, acquisitions, or partner networks both use the same RFC1918 space such as 10.0.0.0/24. Then the clean route-based model fails because the tunnel cannot distinguish which 10.0.0.5 you meant.

Operators handle this with approaches such as:

• renumbering one side, the cleanest but hardest organizationally
• NAT inside or around the tunnel
• policy-based routing tied to source context
• segmentation that avoids the overlap reaching the tunnel at all

This is one reason network engineers still care deeply about address planning. A VPN will happily encrypt traffic, but it cannot make ambiguous routing semantics disappear.

Path MTU Discovery Fails in Predictable Ways

MTU problems deserve extra attention because they produce some of the most confusing support tickets in VPN deployments.

A common failure pattern looks like this:

• small web pages load
• login works
• large downloads stall
• some HTTPS sites hang during handshake or page load
• ICMP appears to be filtered somewhere in the path

What happened is usually straightforward. The inner packet plus outer headers exceeded the true path MTU. If fragmentation is blocked or PMTUD feedback does not return correctly, neither endpoint learns the right size adjustment. The packets just disappear.

This is why MSS clamping exists. By lowering the advertised maximum TCP segment size at the tunnel edge, the system forces endpoints to use smaller segments that are more likely to fit once encapsulated. It is not elegant, but it is often practical.

In operations, MTU problems are not a sign that VPNs are fragile toys. They are a natural consequence of stacking protocols with real header costs over a path whose smallest supported frame size may be unknown or variable.

DNS Is Often the First Place Trust Gets Re-Centralized

Users think about VPNs in terms of IP addresses, but operationally DNS is often where control really recenters.

If the VPN pushes an internal resolver, then:

• private zones become reachable
• internal service names resolve correctly
• the tunnel endpoint can observe domain lookups for tunneled users

That may be necessary and entirely appropriate in an enterprise. It is also a reminder that a VPN often shifts metadata visibility rather than erasing it. Even when web traffic is end-to-end encrypted, resolver logs at the corporate or provider side can still reveal a great deal about user behavior.

The same issue appears in consumer VPNs. Moving trust from the ISP to the VPN provider often means moving resolver trust too. This is not automatically bad. It is just a trust relocation that users should understand.

Mobile VPNs and Per-App Tunnels Change the Routing Model

On phones and tablets, especially managed devices, a VPN may not be a single "all packets go here" system-wide tunnel. Mobile operating systems often support per-app VPN behavior where:

• only designated apps send traffic through the tunnel
• other apps use the normal uplink
• the tunnel is tied to enterprise app identity or MDM policy

This is useful for keeping corporate traffic inside policy without forcing all personal traffic through the same path. It also means the debugging model changes. A user can truthfully say "the VPN is connected" while one app uses the tunnel and another does not.

From an architectural perspective, this is simply a more granular routing policy. The selection key is not only destination prefix. It may also include application identity or traffic class.

What Websites, ISPs, and VPN Providers Each See

Trust questions become much clearer when broken down by observer.

The local ISP or Wi-Fi operator sees:

• that you are talking to a VPN endpoint
• packet sizes and timing
• probably not the tunneled destinations or payloads

The VPN provider or corporate gateway sees:

• the fact that you connected
• your apparent outer source IP
• the inner destinations for traffic that terminates or exits there
• often DNS metadata if it also provides the resolver

The destination website sees:

• the public IP of the VPN egress
• whatever identity you reveal at the application layer
• cookies, fingerprints, accounts, uploaded data, and behavioral signals

This breakdown is why statements such as "a VPN hides everything" are unserious. A VPN changes which observer gets which view. It does not delete observability from the universe.

Security Incidents Often Happen at the Tunnel Endpoint, Not in the Tunnel

The tunnel protocol can be perfectly sound and the deployment can still fail because the endpoint system is weak.

Examples:

• a compromised VPN concentrator can inspect or tamper with traffic after termination
• weak account controls on the remote-access gateway can let attackers enroll as valid users
• broken split-DNS policy can expose internal names externally
• permissive routes can hand a contractor far more network reachability than intended

This is a useful corrective to protocol obsession. Engineers sometimes spend enormous time debating AEAD choices while the real risk is:

• poor identity management
• overly broad access
• missing host hardening on the concentrator
• lack of logging and session review

The tunnel matters. The security of the thing terminating the tunnel matters just as much.

Troubleshooting a VPN Means Working Layer by Layer

When a VPN is misbehaving, the cleanest diagnostic sequence is usually:

1. Is the control plane healthy? Are the peers authenticated, keys current, and policy installed?
2. Is the outer path healthy? Can packets actually reach the tunnel endpoint over the real network?
3. Is the virtual interface up and addressed correctly?
4. Are the expected routes present?
5. Are firewall rules allowing the intended inner and outer traffic?
6. Is DNS aligned with the routing policy?
7. Is MTU small enough for the real path?

This layered method prevents the common mistake of blaming encryption when the actual problem is a bad route, blocked UDP, or a resolver pointing somewhere wrong.

It also reinforces the broader thesis of this article. A VPN is not a monolithic magic box. It is a stack of understandable networking decisions: interfaces, routes, encapsulation, keys, and policy. Troubleshoot it that way and it becomes far less mysterious.

NAT Traversal Exists Because Real Paths Break Elegant Designs

One reason IPSec gained a reputation for operational complexity is that the public internet path between peers is full of devices that are happier with UDP than with native security formats. NAT devices and firewalls often track UDP state comfortably while mishandling or blocking more specialized traffic shapes.

NAT Traversal matters for that reason. When peers detect a NAT in the path, they can encapsulate protected traffic inside UDP so middleboxes are more likely to pass it and maintain state correctly. The cryptography is not changing. The packet shape is.

This explains a lot of field behavior:

• a tunnel may work in one environment and fail in another because the middleboxes differ
• an engineer may think "IPSec is flaky" when the real issue is path treatment of non-UDP traffic
• debugging has to ask what the outer packet actually looks like on the wire

UDP won not only because it is simple, but because it survives real networks more reliably.

Route-Based and Policy-Based VPN Thinking Are Different

Not every VPN is best understood as "an interface plus routes." Some deployments are effectively policy engines that say certain traffic selectors must be protected.

In a route-based design:

• the tunnel behaves like an interface
• routes point prefixes at that interface
• the networking stack behaves mostly as usual

In a policy-based design:

• the interesting object is the selector policy
• traffic matching that policy is captured and protected
• routes alone may not explain behavior fully

Both models are valid. The important operational point is knowing which mental model applies to the system in front of you. If you are debugging a policy-based tunnel by staring only at the route table, you can miss the actual decision mechanism entirely.

Dynamic Routing Often Runs Across Site-to-Site Tunnels

Production site-to-site VPNs frequently carry routing protocols across the tunnel rather than relying only on static routes. That means the tunnel is not just moving application packets. It is also carrying the control traffic that tells each side what networks the other side currently owns.

Typical examples include OSPF or BGP riding inside the tunnel. The benefits are obvious:

• automatic learning of new prefixes
• cleaner failover across multiple tunnels
• route preference tuning without editing every static entry

The cost is more moving parts. Now a branch-office complaint of "the VPN is down" may really mean:

• the encrypted tunnel is established
• but the routing adjacency inside it is not healthy
• so no useful reachability exists

This is another reason experienced operators separate control plane from data plane even inside VPN discussions.

Authentication Lifecycle Is as Important as Cipher Choice

Tunnel protocols get compared on cryptography, but deployments live or die on how authentication is managed over time.

Questions that matter just as much as the cipher:

• how are devices enrolled
• how are users revoked
• how is MFA integrated
• can identity be tied to device posture
• what happens when a laptop is stolen
• how are temporary accounts handled

Static keys, certificates, usernames, device identities, and brokered access models each make different operational promises. In enterprise environments, the complexity people attribute to "the VPN" is often really identity lifecycle complexity wearing a tunnel-shaped costume.

Segmentation Quality Determines How Dangerous a Successful VPN Login Is

A VPN does not have to imply broad internal access. Good designs increasingly treat tunnel establishment as only the first gate. After the tunnel comes policy:

• which prefixes are installed
• which ports are reachable
• which DNS zones resolve
• whether access is tied to a role, device state, or just-in-time approval

This matters because older remote-access designs often behaved like "connected means inside." Modern designs try to avoid that by making the VPN path narrow even after successful authentication. Put differently, the tunnel is there, but the reachable network behind it is deliberately small.

That shift is one reason some teams keep the VPN but radically change what it grants.

Sometimes the Right Answer Is Not a Traditional VPN

Because "VPN" often stands in for "secure remote access," teams sometimes default to a full tunnel when the real need is narrower. In some situations the better answer is:

• an application proxy
• an identity-aware reverse proxy
• a bastion host
• a brokered connection to one service instead of a routed subnet

That does not make VPNs obsolete. It just sharpens the question. If the actual requirement is "reach this internal dashboard safely," extending broad layer-3 reachability may be more exposure than the problem requires. Understanding how VPNs work helps precisely because it lets you recognize when a different remote-access pattern is a better fit.

Consumer Apps Hide Most of This, but the OS Still Does the Same Work

Commercial VPN apps often present one toggle and a country picker. Underneath that minimal UI, the operating system is still doing the same fundamental tasks:

• creating or activating a virtual interface
• installing routes
• updating DNS settings
• tracking peer endpoint state
• enforcing firewall or kill-switch policy

The app mostly automates configuration and key distribution. That convenience is useful, but it can also obscure what is actually happening. When something breaks, the glossy interface often has no vocabulary for:

• which routes were installed
• whether DNS really changed
• whether the app is doing full tunnel or split tunnel
• whether the kill switch is firewall-based or route-based

Engineers debugging even consumer VPN products often end up back at native operating system tools such as route tables, packet captures, interface status, and resolver configuration for that reason.

A Good VPN Design Minimizes Surprises During Failure

Many of the worst VPN user experiences do not come from steady-state operation. They come from transitions:

• the laptop changes networks
• the outer IP changes
• the tunnel rekeys
• the peer becomes unreachable
• DNS updates race with route changes

A good design therefore is not only secure when everything is healthy. It is predictable when something fails. Users and operators should know:

• whether traffic stops or falls back
• whether local LAN access remains
• whether DNS reverts or stays pinned
• how quickly sessions recover after roaming

Those are not secondary details. They are the difference between a tunnel that is theoretically correct and one that behaves safely under the messy conditions real devices encounter every day.

VPNs Are Most Useful When Their Boundaries Are Understood

Teams get into trouble when they expect a VPN to solve problems that belong to other layers. The tunnel can secure transport across an untrusted path, move trust to a chosen endpoint, and extend selected network reachability. It cannot clean a compromised laptop, fix a weak identity system, or stop an application from revealing who the user is. The most successful deployments are the ones where operators understand exactly where the tunnel starts helping and exactly where that help ends.

Packet Size, Timing, and Destination Class Still Leak Outside the Tunnel

Even when payload and inner addressing are hidden, the outside world often still learns useful metadata from the outer flow:

• packet sizes
• burst timing
• session duration
• which VPN endpoint was used
• whether traffic looks like bulk transfer, interactive browsing, or mostly idle keepalive behavior

That does not negate the value of the tunnel. It simply reinforces the theme of bounded protection. A VPN hides some things well and leaves other categories of metadata visible by design. Engineers planning around censorship resistance, traffic analysis, or provider trust need to account for those remaining signals instead of assuming encryption made them disappear.

The Simplest Troubleshooting Tool Is Often the Route Table

Because VPN products wrap themselves in polished UI and authentication workflows, engineers sometimes forget that the fastest sanity check is still extremely old-fashioned:

• what interfaces exist
• what routes point where
• which resolver is active
• what the packet capture shows on the physical NIC versus the tunnel interface

Those checks answer a surprising percentage of "the VPN is broken" reports. If the route table says the destination never enters the tunnel, the crypto details are irrelevant. If DNS is still using the local resolver, the leak is already explained. The network stack usually tells the truth if you ask it directly.

VPN Design Is Really About Choosing Which Network You Trust More

In the end, the biggest architectural decision behind a VPN deployment is trust relocation. You are deciding that for some traffic, a chosen gateway or provider should sit closer to the traffic than the local network does. Sometimes that is a corporate edge protecting access to internal systems. Sometimes it is a commercial provider replacing the local ISP as the main observer of your traffic patterns. The technical mechanics stay the same. What changes is which organization you are deliberately moving your trust toward.

That framing keeps the whole topic honest. A VPN is not the absence of trust. It is a deliberate reassignment of trust to a different network position.

Understanding that one point prevents most category errors. If you know which observer lost visibility, which observer gained visibility, and which routes actually enter the tunnel, you already understand more about VPNs than most marketing copy ever explains.

It also explains why the same tunnel can be an excellent enterprise access tool, a useful privacy improvement on hostile Wi-Fi, and still not be anything close to anonymity. The mechanism is consistent. The surrounding trust model is what changes.

That is ultimately why VPNs confuse so many people. The packet mechanics are straightforward. The promises people project onto those mechanics are not.

If you keep the discussion pinned to interfaces, routes, encapsulation, keys, and who terminates the tunnel, the subject stays concrete. As soon as it drifts into vague words like "private" or "anonymous" without naming the observer and the traffic class, confusion comes back immediately.

That is the discipline worth keeping: always ask which packets move, which packets do not, and who can still see the metadata that remains outside the encrypted wrapper.

With that framing, VPN behavior stops feeling mystical and starts feeling like normal networking with better transport protection.

That is the right place to leave it.

It is enough.

The mechanism stays concrete.

The packet path stays explainable.

That matters daily.

Operationally.

The Tunnel Endpoint Also Becomes an Observability Boundary

A VPN changes who can observe traffic, which means it also changes which logs and controls become useful.

If the tunnel terminates at a corporate edge, the operationally important records often include:

• concentrator session logs
• identity-provider events
• internal firewall policy hits
• split-tunnel route decisions

If the tunnel terminates at a commercial provider, the useful evidence shifts toward:

• client route and DNS changes
• local kill-switch behavior
• provider endpoint selection
• application-layer signals that still reveal identity or destination intent

This matters because the tunnel itself is not the whole system. The endpoint inherits routing authority, policy authority, and much of the troubleshooting burden. A VPN deployment becomes easier to reason about once teams are explicit about which side of the tunnel is now responsible for logging, filtering, and incident response.

Authentication Failure And Transport Failure Are Different Incidents

Users often report both as "the VPN is down," but they point to different parts of the system. If the tunnel packets never form, the problem may be reachability, NAT traversal, MTU, certificate validation, or firewall policy. If transport comes up but access still fails, identity and authorization logic may be the real blocker.

Separating those cases saves time:

• did the client establish the secure session at all
• did key exchange complete
• did the user or device satisfy identity checks
• did post-auth routes and policies actually arrive

That distinction matters operationally because different teams often own the layers. Network engineers may fix transport. Identity or endpoint teams may fix posture and access policy. A mature VPN service stays supportable when those responsibilities are visible instead of being buried inside one generic "connect" button.

That separation also improves incident response. When transport telemetry and identity telemetry are reviewed together, teams can usually tell whether the failure belongs to path engineering, access control, or device posture before the troubleshooting loop becomes noisy.

The Right Mental Model

A VPN is a packet-transport machine, not a magic privacy spell. It creates a virtual interface, uses routes to decide which traffic enters that interface, encapsulates the resulting inner packets inside an encrypted outer transport, and hands them to a remote peer that decapsulates and forwards them onward.

Once you see it that way, most confusing behavior becomes predictable:

• split tunneling is just selective routing
• DNS leaks are resolver traffic escaping the intended path
• MTU failures are encapsulation overhead meeting a smaller downstream link
• WireGuard peer configuration doubles as inner-prefix routing policy
• IPSec tunnel mode carries whole packets while transport mode protects an existing host-to-host packet

The trust model also becomes clearer. A VPN can hide traffic from the local network and from intermediate observers, but it shifts visibility toward the tunnel endpoint. It can give secure remote access, enforce egress policy, and protect hostile last-mile environments. It cannot prevent the destination from knowing who you are if the application itself reveals it.

That boundary is the difference between understanding VPNs and merely using them. A VPN is extremely useful. It is just useful for the specific reasons the network stack actually provides, not for the vague promises marketing would prefer you to believe.