VPN basics
Every method Port forwarding closed with shares one property: the traffic still crosses the public internet in the clear, visible to any router or network operator positioned along the path, and reaching a private service still means opening something to the outside. A VPN takes a different approach to the same underlying goal — reaching a private network from somewhere else — by doing the opposite of opening anything: it builds an encrypted, private path across a network that is itself public, so that from the inside it looks and behaves like a direct, local connection, no matter how many untrusted networks the traffic actually crosses to get there.
Tunneling: a packet carrying another packet
The mechanism underneath every VPN is tunneling — wrapping one packet entirely inside another. The client builds a normal IP packet addressed to something on the private network, exactly as if it were sitting on that network directly. Instead of sending that packet as-is, the VPN software encrypts it and wraps it inside a second, outer packet addressed to the VPN gateway. That outer packet is the only thing any router between the client and the gateway ever sees.
Original packet: [ Src: 10.8.0.5 Dst: 10.0.0.20 | payload ]
|
encrypted and wrapped
|
Tunneled packet: [ Src: 203.0.113.9 Dst: 198.51.100.1 | encrypted( original packet ) ]
Every router between the client and the VPN gateway forwards that outer packet exactly the way it forwards any other IP packet — it has no reason to treat it specially, and no way to see what's inside it. Only the VPN gateway holds the key to decrypt the outer packet's payload, recover the original inner packet, and forward it onward into the private network as if it had arrived locally. The reverse happens for the return trip. From the client's own operating system, the whole exchange looks like a second network interface — commonly named tun0 or wg0 — that traffic to the private network's addresses gets routed through, indistinguishable at the application layer from a normal local connection.
5: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1420 qdisc fq_codel state UNKNOWN group default qlen 500
inet 10.8.0.5/24 scope global tun0
That 10.8.0.5 is an address on the VPN's own private range, assigned the moment the tunnel comes up — the same private-addressing concept Public vs Private IP already covered, just applied to a virtual network that only exists between VPN participants rather than to a physical LAN.
Two shapes the same tunnel takes
Nearly every VPN deployment is one of two shapes, distinguished by what's actually connecting to what:
- Remote-access VPN. A single device — an employee's laptop, a phone — connects to a VPN gateway to reach a private network it isn't physically part of. This is the shape most people mean by "turning on a VPN": one client, one tunnel, one gateway.
- Site-to-site VPN. Two entire networks connect to each other permanently, with a gateway device at each end maintaining the tunnel continuously rather than a single client dialing in on demand. Types of networks already described exactly this setup — a company connecting offices in different cities into one logical WAN over a permanent encrypted tunnel between each site's gateway, rather than a dedicated leased line.
The distinction matters for planning, not just terminology: a remote-access VPN needs client software or configuration on every device that connects, while a site-to-site VPN needs configuration only on the two gateways, and every device behind each gateway gets access automatically without installing anything.
Split tunnel versus full tunnel
Once a remote-access VPN is up, a separate question decides which traffic actually uses it: all of the client's traffic, or only traffic destined for the private network the VPN exists to reach.
- Full tunnel routes every packet the client sends — including ordinary web browsing that has nothing to do with the private network — through the VPN gateway first. This is standard for corporate VPNs where the organization wants to apply its own firewall rules and monitoring to all of an employee's traffic while connected, and it's also what most consumer privacy-focused VPN services do by design, since routing everything through the provider's gateway is the entire point of the product.
- Split tunnel routes only traffic destined for the private network's address ranges through the tunnel, and lets everything else — a video call, a random website — go straight to the internet through the client's normal connection, unencrypted by the VPN and untouched by the private network's policies.
Full tunnel: Client -> [ everything ] -> VPN gateway -> private network AND internet
Split tunnel: Client -> [ 10.0.0.0/8 traffic only ] -> VPN gateway -> private network
Client -> [ everything else ] -> normal internet path directly
Split tunneling is faster and lighter on the gateway, since it isn't relaying traffic that never needed to touch the private network at all. It's also a smaller security boundary by design, which is exactly why some organizations forbid it outright: if the client machine is compromised while split-tunneled, the attacker's traffic to the wider internet never passes through the corporate gateway's monitoring at all, only the traffic actually addressed to the private network does.
What a VPN protects against, and what it doesn't
A VPN's encryption protects the tunnel itself — nobody positioned on the path between client and gateway can read the traffic in transit, and nobody can tamper with it without detection. That's a genuinely strong guarantee for the specific threat of a hostile or untrusted network in between, which is exactly why connecting over an unencrypted public Wi-Fi network at a coffee shop or airport is one of the most commonly cited reasons to use one.
A VPN encrypts the path, not the endpoints. Once the inner packet reaches the private network at the far end of the tunnel, it's decrypted and travels in the clear from that point on, exactly like any other traffic on that network — the device-level NAT article and the reverse proxy article both already covered what "in the clear on an internal network" actually looks like at that stage. A VPN also does nothing to protect a client that's already compromised: malware running on a VPN-connected laptop reaches the private network through the tunnel exactly as easily as the legitimate user does, because the tunnel authenticates the device or user, not the intent of every packet it carries afterward. Access control on the private network's own resources — the same firewall rules, authentication, and segmentation Public vs Private IP already insisted on for NAT — still has to exist independently; a VPN is not a substitute for it.
Practical scenario: a VPN that connects but reaches nothing
An employee connects to the company VPN from home, and the client reports "Connected" with no error. But every attempt to reach an internal resource — a wiki, an internal API — times out, while the employee's ordinary internet browsing works completely normally throughout.
default via 192.168.1.1 dev wlan0
10.0.0.0/8 via 10.8.0.1 dev tun0
192.168.1.0/24 dev wlan0 scope link
The routing table looks correct — a specific route for 10.0.0.0/8, the company's internal range, does point through tun0, and the default route for everything else correctly still goes out the home Wi-Fi. The tunnel interface itself came up. The next place to look is whether the far end — the VPN gateway — actually has a route back:
PING 10.0.0.20 (10.0.0.20) 56(84) bytes of data.
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
This is a routing problem on the gateway's side, not the client's — the client's outbound packets are reaching the tunnel and leaving correctly, confirmed by the interface being up and the route table being correct, but nothing is coming back. A common cause on the gateway side is exactly this: the VPN server assigns the client an address in its own tunnel range (10.8.0.0/24 here) but the internal network's own devices and firewall have no route pointing traffic destined for 10.8.0.0/24 back through the VPN gateway — so replies from 10.0.0.20 have nowhere to go once they try to leave the internal network back toward the client. The fix lives entirely on the private-network side: adding a route on the internal network's own gateway or firewall that sends 10.8.0.0/24 — the VPN's client pool — back through the VPN server, so return traffic can find its way back through the tunnel it arrived from.
Don't test VPN routing changes on the only path you have into a network
If the VPN gateway itself is also how you administer the private network's firewall or routing remotely, a mistaken route change can cut off the very access you're using to make the change. Confirm out-of-band access — console access, a second administrative path, or someone physically on-site — before changing routing on a gateway you're currently connected through.
Practice exercises
- Bring up any VPN client you have access to (a corporate VPN, a personal WireGuard setup, or a free trial of a consumer VPN service in a lab context) and run
ip addr showbefore and after connecting. Identify the new interface and the address it was assigned. - Explain, using the tunneling diagram above, why a router positioned between the client and the VPN gateway cannot read the contents of the inner packet even though it successfully forwards the outer one.
- A company wants employees' work traffic monitored and filtered while connected, but doesn't want to pay for the bandwidth of relaying employees' personal streaming and browsing through its own gateway. Which tunnel mode fits, and what does the company give up by choosing it?
This article deliberately stayed at the level of what a VPN does and how tunneling works structurally — it didn't get into how the encryption itself is negotiated, which protocol a given deployment should choose, or how WireGuard's approach differs from IPsec's. That comparison, along with the tunneling protocols behind other secure connections, belongs to the security module next in this course.