VPN Architecture and Tunneling

A VPN, or virtual private network, creates an encrypted path between your device and a remote gateway. Everything inside that path is protected from local observers such as a public Wi-Fi operator, a hotel network, or an ISP watching the access link. That protection is useful, but it is easy to misunderstand what it does and does not hide.

The first step is tunnel establishment. Your device runs a VPN client and authenticates to a VPN server using credentials, certificates, or pre shared keys depending on the protocol. Protocols such as WireGuard, IPsec, and OpenVPN then perform a key exchange to derive short lived session keys. Once that handshake succeeds, both sides can encrypt and authenticate packets so that intermediaries can see only outer transport details such as the destination VPN server, packet sizes, and timing.

After the tunnel exists, the client changes routing. In a full tunnel configuration, your default route points to the VPN, so most traffic goes through the encrypted tunnel before it exits to the wider internet. In split tunnelling, only selected destinations use the VPN while everything else goes out normally. Full tunnelling gives stronger privacy and central control. Split tunnelling reduces latency and bandwidth costs, but it creates more ways to leak traffic accidentally.

Inside the tunnel, your original packets are encapsulated. The VPN client takes an IP packet destined for a website or corporate service, wraps it in an encrypted outer packet, and sends it to the VPN gateway. The gateway decrypts it, sees the real destination, and forwards it on your behalf. Replies return to the gateway, which re-encrypts them and sends them back through the tunnel. To outside services, the visible source IP is usually the VPN gateway rather than your home or mobile address.

That change in source IP is why consumer VPNs are marketed for privacy and geolocation shifting, while company VPNs are used for private access to internal systems. In both cases, however, trust moves rather than disappears. Your café network can no longer inspect your traffic, but the VPN provider or corporate gateway can see much more. If the provider logs aggressively, injects ads, or handles DNS badly, a VPN may improve one risk while worsening another.

DNS handling is a common weak point. If your web traffic uses the tunnel but your DNS queries still go to the local resolver, you leak which domains you are visiting. Good VPN clients push DNS settings through the tunnel and often include a kill switch, which blocks network access if the tunnel drops unexpectedly. Without a kill switch, an unstable connection can silently revert traffic to the normal route.

Performance also changes. Encryption costs CPU time, extra encapsulation can reduce the effective MTU, and the remote exit point may be geographically far away. Some protocols, especially those using UDP, are fast but can be blocked on restrictive networks. Others are more compatible but slower. Mobile devices add another complication because roaming between networks can interrupt tunnels unless the protocol handles session changes cleanly.

So a VPN is best seen as a secure transport and routing tool, not a cloak of invisibility. It can protect data in transit on untrusted networks, provide controlled access to internal services, and hide your local IP from destination sites. It cannot stop browser fingerprinting, malware on your laptop, phishing, or a dishonest provider. The real design question is always who you are choosing to trust, and whether the tunnel actually covers the traffic you care about.