Your company's file server is on a private network at 192.168.10.20. You are at home, or in a hotel. Between you and the office is the internet: networks owned by strangers, which you can't trust with your data and which won't even carry packets addressed to a private address. A VPN solves both problems at once.
💡 In simple terms: a VPN is like putting your letter inside a locked, unmarked box and posting the box to your office. The postal workers can see the box travel from your house to the office address on the label, but they can't see what is inside or who the letter is really for. At the office, someone with the key opens the box and delivers the letter inside.
What a VPN is
A virtual private network (VPN) is a private connection built on top of a shared, public network. It is:
- Virtual, because there is no dedicated cable. The traffic shares the internet with everyone else.
- Private, because outsiders can't read it or change it, and devices at each end behave as if they were on the same private network.
- A network, because once it is up, ordinary IP traffic flows through it: file shares, web applications, Remote Desktop and more.
Two techniques make this work: encryption (scrambling the data so only the other end can read it) and tunnelling (wrapping each private packet inside a new, public packet).
Why VPNs exist
Working from anywhere
Staff at home or travelling need the office's internal servers, which are deliberately not reachable from the internet.
Joining offices together
A branch office needs the headquarters' servers. A private leased line is expensive; the internet is cheap but untrusted.
Untrusted local networks
On café or hotel Wi-Fi, other people (or the owner of the Wi-Fi) could watch unencrypted traffic. A VPN encrypts it all the way to the VPN gateway.
The important parts
| Part | What it does |
|---|---|
| VPN client | Software on a laptop or phone that builds the tunnel and adds a virtual network interface |
| VPN gateway (or concentrator) | The device at the office edge where tunnels end. Often a feature of the firewall or router |
| Tunnel | The logical link between the two ends, carrying encrypted packets |
| Authentication | Proving who is at each end: passwords plus MFA (multi-factor authentication), certificates or pre-shared keys |
| Keys | Secret numbers agreed during setup, used to encrypt and check every packet |
| Tunnel IP address | A private address the client gets inside the VPN, for example 10.8.0.5 |
Encryption: keeping the contents secret
Encryption turns readable data (plaintext) into scrambled data (ciphertext) using a key. Only someone with the right key can turn it back. Together with integrity checks and authentication, a VPN gives you three protections at once:
- Confidentiality: nobody on the path can read the data.
- Integrity: every packet carries a check value. If anyone changes even one bit, the receiver notices and throws the packet away.
- Authentication: each end proves who it is before the tunnel comes up, so you don't build a tunnel to an impostor.
These are the same goals as the CIA triad in Basic network security, and the same ideas behind HTTPS and TLS. When a tunnel starts, the two ends run a handshake: they prove their identities and agree on fresh keys, without ever sending the keys themselves across the network.
Tunnelling: a packet inside a packet
You learned in Encapsulation that each layer wraps the data from the layer above in its own header. Tunnelling does something unusual: it takes a complete IP packet, headers and all, and treats it as the data of a new IP packet. The original packet is the inner packet; the new wrapping is the outer header.
1. The original packet (inside the private network)
2. The tunnelled packet (crossing the internet)
Encrypted: nobody on the path can read or change this part
Here is what each part tells the devices along the way:
- The outer IP header uses public addresses: the home router's public address
198.51.100.77(after NAT) and the office VPN gateway203.0.113.2. Internet routers only read this header, so the packet is routed like any other packet. - The VPN header tells the gateway which tunnel and which keys to use. It also carries a counter that stops an attacker from replaying old packets.
- The inner packet carries the private addresses
10.8.0.5 → 192.168.10.20. It is encrypted, so an observer can't see the file server's address, the port (445, file sharing) or the data. - The check value (integrity tag) proves the packet was not changed in transit.
All those extra headers take up space: typically 50 to 80 bytes per packet. Because the outer packet must still fit within the normal 1,500-byte Ethernet limit, the inner packets must be a little smaller. VPN software usually lowers the tunnel interface's MTU (maximum transmission unit, the largest packet it can send), for example to 1,420 bytes, to make room.
How a VPN works, step by step
Here is what happens in a remote-access VPN from a laptop at home to the office:
1. Handshake · Laptop ↔ gateway, over the internet · UDP → 51820
Both sides prove who they are and agree on fresh encryption keys.
Tap this step's arrow for the details.
- Laptop:
- It is on the office network as 10.8.0.5
- File server:
- It is talking to an internal client at 10.8.0.5
- Internet:
- Encrypted UDP between 198.51.100.77 and 203.0.113.2
Notice that the firewall at the office needs only one inbound rule: allow UDP 51820 (or whichever port the VPN uses) to the gateway. Everything else stays closed. The firewall can then apply normal rules to the decrypted traffic, so VPN users can be limited to the servers they actually need.
Remote-access VPN
A remote-access VPN connects one device to a network. The user runs a VPN client, signs in (usually with multi-factor authentication), and their device joins the office network virtually.
- 1. The laptop sends an encrypted, wrapped packet. Outer header: 198.51.100.77 → 203.0.113.2. The home router and the internet see only this header.
- 2. The gateway unwraps and decrypts it. The inner packet 10.8.0.5 → 192.168.10.20 continues on the office LAN as normal traffic.
- 3. The server replies to 10.8.0.5. The office network knows that 10.8.0.0/24 is reached through the VPN gateway.
- 4. The reply goes back through the tunnel. Encrypted again, wrapped in 203.0.113.2 → 198.51.100.77.
Site-to-site VPN
A site-to-site VPN connects two whole networks. The tunnel is built between the edge devices (firewalls or routers) of each site and stays up permanently. Users don't run any VPN software. To them, the other office is just another subnet, reached through their default gateway.
- 1. The PC sends an ordinary packet. 192.168.20.15 → 192.168.10.20. The PC doesn't know a VPN exists; it simply uses its default gateway.
- 2. The branch firewall encrypts and wraps it. Traffic for 192.168.10.0/24 matches the tunnel. Outer header: 198.51.100.7 → 203.0.113.2.
- 3. The HQ firewall unwraps it. The original packet, 192.168.20.15 → 192.168.10.20, is delivered on the HQ LAN.
- 4. The reply makes the same trip in reverse. It is encrypted between the two firewalls and unencrypted on each LAN.
Site-to-site tunnels most often use IPsec. In IPsec tunnel mode, the tunnelled packet looks like this:
1. The original packet (inside the private network)
2. The tunnelled packet (crossing the internet)
Encrypted: nobody on the path can read or change this part
Remote-access vs. site-to-site at a glance
| Remote-access VPN | Site-to-site VPN | |
|---|---|---|
| Connects | One device to a network | A network to a network |
| Tunnel ends | VPN client on the device ↔ gateway | Firewall/router ↔ firewall/router |
| Software for users | Yes, a VPN client (or a browser for some TLS VPNs) | None |
| When it is up | When the user connects | All the time |
| Authentication | Each user: password + MFA, or a certificate | Each site: certificate or pre-shared key |
| Typical use | Home workers, travellers, IT support | Branch offices, links to a cloud network or a partner |
Common VPN protocols
You don't need to know the internals yet, but you should recognise the names and know what traffic each one creates, because firewalls must allow that traffic.
| Protocol | What it is | Traffic on the internet | Typical use |
|---|---|---|---|
| IPsec | A family of standards. IKE (Internet Key Exchange) does the handshake; ESP encrypts the packets | IKE on UDP 500; ESP as IP protocol 50, or inside UDP 4500 when NAT is in the way ("NAT traversal") | Site-to-site between firewalls of any vendor; also remote access (IKEv2) |
| SSL/TLS VPN | Uses the same TLS as HTTPS to protect the tunnel. OpenVPN and many vendor clients work this way | Often TCP 443, sometimes UDP (DTLS); OpenVPN defaults to UDP 1194 | Remote access; on TCP 443, it gets through hotel and guest firewalls that block most other ports |
| WireGuard | A newer, deliberately small VPN protocol with a fixed set of modern encryption methods | UDP, commonly port 51820 | Remote access and site-to-site; also many consumer VPN apps |
⚠️ You may still meet PPTP, an old Microsoft VPN protocol. Its security is broken, so don't use it.
Split tunnelling vs. full tunnel
Once a laptop is connected, which traffic goes into the tunnel? There are two options:
Full tunnel
Everything goes through the VPN, including normal web browsing. The office firewall inspects and logs all of it. This is safer on untrusted Wi-Fi, but slower, and it adds load to the office internet link.
Split tunnel
Only traffic for the office networks (e.g. 192.168.10.0/24) uses the tunnel. Everything else goes directly to the internet. This is faster, but the direct traffic gets no protection from the office.
- 1. Office traffic matches the VPN route. It is encrypted and sent through the tunnel.
- 2. Other traffic doesn't match the VPN route. With a split tunnel, it leaves directly through the home router. With a full tunnel, it would go to the VPN gateway first.
The choice is made in the laptop's routing table. On a Linux laptop with a split tunnel, you might see:
$ ip route default via 192.168.1.1 dev wlan0 proto dhcp metric 600 10.8.0.0/24 dev wg0 proto kernel scope link src 10.8.0.5 192.168.1.0/24 dev wlan0 proto kernel scope link src 192.168.1.23 metric 600 192.168.10.0/24 dev wg0 scope link
What to look for: the default via line still points to the home router (192.168.1.1 on wlan0). Only 192.168.10.0/24, the office LAN, goes to the tunnel interface wg0. In a full tunnel, the default route itself would lead into the tunnel.
What a VPN does not protect against
A VPN protects data in transit between two points. It is not a complete security solution, whatever some adverts suggest.
- Malware and phishing. A malicious download or a fake login page arrives through the tunnel just as easily as it would without one.
- A compromised device. If the laptop is infected, the VPN gives the attacker a ready-made, encrypted path into the office. This is why VPN users should be limited by firewall rules and segmentation.
- Traffic after the gateway. The tunnel ends at the gateway. From there, packets travel unencrypted unless the application uses its own encryption, such as HTTPS.
- The VPN operator. Your company, or a commercial VPN provider, can see where your traffic goes. A VPN moves trust from your local network to the VPN operator; it doesn't remove the need for trust.
- Tracking by websites. Logins, cookies and browser fingerprints identify you, whatever your IP address is.
- Split-tunnel traffic. Anything outside the tunnel gets none of its protection.
- Stolen passwords. If the VPN only asks for a password, anyone who phishes it can connect. Always pair VPN access with MFA.
A real-world example
Priya works for a company whose office LAN is 192.168.10.0/24. Working from a hotel, she opens the company VPN client. It connects to 203.0.113.2 over TCP 443, because the hotel Wi-Fi blocks most other ports, and asks for her password and an approval on her phone. She is given the tunnel address 10.8.0.5. The company uses a full tunnel, so her web browsing also goes through the office, where the firewall filters malicious sites. The office firewall allows VPN users to reach the file server and the intranet, but not the finance servers. When she disconnects, the tunnel and her 10.8.0.5 address disappear.
When a VPN fails
| Symptom | Likely cause | What to check |
|---|---|---|
| Can't connect at all | The VPN port is blocked by the local network or the office firewall | Try another network; check the firewall rule for the gateway (UDP 500/4500, UDP 51820, TCP 443 and so on) |
| Authentication fails | Wrong password, MFA not approved, certificate expired | The client log; certificate dates; the device clock (wrong time breaks certificates) |
| Connected, but can't reach office servers | Missing route, or the office doesn't route replies back to the VPN range | Routing table on the laptop; the gateway's logs and firewall rules |
| Connected, IP addresses work, names don't | The client isn't using the office DNS server | Run nslookup for the internal name; check the DNS settings on the VPN adapter |
| Office unreachable from one home only | The home LAN uses the same subnet as the office (both 192.168.10.0/24) | The laptop thinks the server is local and doesn't use the tunnel. Change one of the ranges |
| Small things work, large transfers stall | Packets too big once the outer headers are added (MTU problem) | Lower the tunnel MTU; check that ICMP "too big" messages aren't blocked |
| Everything is slow | Full tunnel to a distant or overloaded gateway | The delay, measured with ping; whether split tunnelling is allowed |
Useful commands
C:\> ipconfig PPP adapter Office VPN: Connection-specific DNS Suffix . : IPv4 Address. . . . . . . . . . . : 10.8.0.5 Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : Wireless LAN adapter Wi-Fi: Connection-specific DNS Suffix . : hotel.example IPv4 Address. . . . . . . . . . . : 10.20.4.117 Subnet Mask . . . . . . . . . . . : 255.255.252.0 Default Gateway . . . . . . . . . : 10.20.4.1
What to look for: the VPN appears as its own adapter, PPP adapter Office VPN, with the tunnel address 10.8.0.5. If you don't see it, the tunnel is not up. The Wi-Fi adapter keeps its normal hotel address and default gateway.
$ sudo wg show interface: wg0 public key: OFK4O86UQIJGFrBmBMCDAb7RIWYWIU8XSHdILsUfovI= private key: (hidden) listening port: 41414 peer: BzRq5o+70oNSMiHYtUMQJaQrR5Uk0McpKRXF4EJWaQY= endpoint: 203.0.113.2:51820 allowed ips: 192.168.10.0/24, 10.8.0.0/24 latest handshake: 48 seconds ago transfer: 1.24 MiB received, 310.52 KiB sent
What to look for: a recent latest handshake and growing transfer counters mean the tunnel works. No handshake at all usually means UDP 51820 is blocked somewhere or the keys don't match. allowed ips lists the networks sent into the tunnel; here, only the office ranges, so this is a split tunnel.
To check what the outside world sees, open What Is My IP with the VPN on and off. With a full tunnel, your public IP address becomes the VPN gateway's address.
Common mistakes
- Thinking a VPN makes a device safe. A VPN protects the path, not the device or the user.
- Allowing password-only VPN logins. VPN gateways are a favourite target for attackers with stolen passwords. Use MFA.
- Giving VPN users access to everything. Treat the VPN as another zone and allow only what each group needs.
- Using a common home address range for the office. Picking a range such as
192.168.1.0/24for the office causes endless "it only works from some homes" problems, because many home networks overlap with it. - Leaving the VPN gateway unpatched. It faces the whole internet, so security updates for VPN gateways are urgent.
- Confusing a VPN with HTTPS. Each protects a different part of the journey, and they are often used together.
- A VPN creates a private, encrypted path across an untrusted network such as the internet.
- Tunnelling wraps the whole original packet (private addresses) inside a new outer packet (public addresses).
- Encryption gives confidentiality; integrity checks catch changes; the handshake authenticates both ends.
- Remote-access VPNs connect one device; site-to-site VPNs connect whole networks through their edge devices.
- IPsec, SSL/TLS VPNs and WireGuard are the common protocols; each needs certain ports to be open.
- Split tunnelling sends only office traffic through the VPN; a full tunnel sends everything.
- A VPN does not stop malware, phishing or an attacker on an infected device.
Knowledge check
A packet travels through a remote-access VPN from 10.8.0.5 to 192.168.10.20. Which addresses can an internet router along the way read?
A company links a branch office's network to headquarters so that branch PCs can use HQ servers without running any software. What is this?
With split tunnelling, a user connected to the VPN visits a public news website. Which path does that traffic take?
An employee's laptop has malware. They connect to the company VPN with MFA. Does the VPN stop the malware reaching office servers?
A remote user connects to the VPN, but can't reach the office server 192.168.10.20. Their home network is also 192.168.10.0/24. Why?
Where to go next
VPN users are best treated as their own zone with limited access. That idea, applied to the whole network, is the subject of the next lesson: Network segmentation. To review how layers wrap each other, revisit Encapsulation; for the encryption used by websites, see HTTPS and TLS.