🔒 08-01: VPN Concepts and Types¶

📌 What Is a VPN?¶

A VPN (Virtual Private Network) lets you extend a private network over a public one — typically the Internet — so that traffic between two points feels like it's traveling over a physically isolated, trusted link, even though it's actually crossing shared, untrusted infrastructure.

The word breakdown tells you exactly what it does:

Virtual — there's no dedicated physical wire; the "private network" is simulated on top of shared public infrastructure.
Private — the traffic inside it is protected (usually encrypted) so outsiders on the public network can't read or tamper with it.
Network — it behaves like a real network: hosts get addresses, traffic gets routed, and applications work as if they were on a local LAN.

💡 Think of a VPN like an armored, opaque tube built through a crowded public tunnel system. Anyone can see that a tube exists and that traffic is moving through it, but they can't see what's inside, and they can't easily cut in or tamper with the contents.

Why VPNs Exist¶

Before VPNs, organizations that needed to connect two offices securely had two bad options:

Lease a dedicated private line between the two sites — secure, but extremely expensive and slow to provision.
Just use the regular Internet — cheap and fast to set up, but any data sent in the clear can be read or modified by anyone on the path (an ISP, a compromised router, an attacker doing a 03-01: Packet Sniffing Basics-style capture).

A VPN gives you the economics of option 2 with (most of) the security of option 1: cheap, public transport, but the payload is protected in transit so it doesn't matter that the underlying network is untrusted.

There's a second, equally common motivation: access control. Many organizations keep internal resources (file servers, admin panels, databases) reachable only from inside the corporate network, and never expose them directly to the Internet. A VPN lets a remote employee — working from home, a coffee shop, or another country — "become" part of that internal network temporarily, so they can reach those resources without the organization having to expose them publicly.

🧩 How a VPN Fits Together¶

A VPN typically involves:

A VPN server (gateway) — a designated host that sits at the edge of the private network and is reachable from the outside.
A VPN client — the remote user's device, or a router at a remote site, that connects to the gateway.
A tunnel — the logical, protected path between client and server, carried over the public network.
Authentication — a step where the client proves who it is (and sometimes the server proves itself too) before the tunnel is trusted.

Once the tunnel is established, traffic destined for the private network is picked up by the client, wrapped and protected, sent across the public Internet to the VPN server, and unwrapped there before being delivered to its real destination inside the private network. The reverse happens for return traffic.

💡 Without a VPN, if internal resources rely on IP address as a proxy for "this request is trustworthy" (e.g., "only allow connections from 10.0.0.0/8"), an attacker who can reach the network at all has a much easier time getting in — IP addresses are easy to spoof or route around. A VPN forces every remote party to authenticate before they're treated as "inside," which is a much stronger guarantee than "your packet happened to arrive with the right source address."

🌍 Site-to-Site VPN vs. Remote-Access VPN¶

VPNs come in two main flavors, distinguished by what is being connected.

Site-to-Site VPN¶

Connects two entire networks to each other — for example, a company's New York office network and its London office network. The VPN tunnel runs between two gateway devices (routers/firewalls), and it's largely invisible to the end users and machines on either side; they just see a single, larger private network.

Endpoints: network gateway ↔ network gateway
Typical use: connecting branch offices, data centers, or cloud VPCs to on-premises infrastructure
Always-on, persistent tunnel — not something a person manually connects to each morning

Remote-Access VPN¶

Connects a single device (a laptop, phone, or home PC) to a private network. This is the "VPN client app" most people are familiar with — you open an app, authenticate, and your individual machine becomes a temporary member of the remote network.

Endpoints: individual client ↔ network gateway
Typical use: an employee working from home connecting to the company network; a traveler reaching internal tools
Connection is initiated and torn down on demand, by a person or device

Feature	Site-to-Site	Remote-Access
Connects	Two networks	One device to a network
Initiated by	Gateway devices (automatic)	End user (manual, on demand)
Typical users	No direct user interaction	Individual employees/travelers
Example	HQ ↔ branch office	Laptop ↔ corporate VPN
Scale	Fixed number of sites	Many, changing client devices

💡 The underlying tunneling and encryption technology (IPsec, TLS-based VPNs, etc.) is often the same for both types — what differs is who the endpoints are and how the tunnel gets set up.

🧱 Where a VPN Fits Relative to a Firewall¶

It's easy to conflate VPNs and firewalls because both sit at the network edge and both are "security" devices, but they solve different problems and are usually complementary, not substitutes.

A firewall (see 05-01: Firewall Concepts & History) is a policy enforcement point: it decides which packets are allowed to cross a trust boundary, based on rules (source/destination address, port, protocol, connection state). It doesn't inherently protect the content of allowed traffic — a firewall that allows port 80 traffic through does nothing to stop that traffic from being read by anyone on the path.

A VPN is a confidentiality and integrity mechanism plus an access mechanism: it protects the content of traffic between two points and can be used to make a remote device appear to be "inside" a trust zone that a firewall protects.

In practice, the two work together:

The VPN gateway is usually one of the very few things a firewall permits to be reached directly from the Internet.
Once a client authenticates and the tunnel is up, the firewall's internal rules can now trust that traffic as if it came from inside the private network — because the VPN already verified who the client is.
Everything else inbound from the Internet is still dropped by the firewall, exactly as before. The VPN doesn't replace the firewall's default-deny posture — it creates one narrow, authenticated, encrypted doorway through it.

💡 A common beginner mistake is thinking "we have a VPN, so we don't need strict firewall rules." In reality, a compromised VPN client becomes a fully trusted (and now internal) attacker — which is exactly why VPN authentication strength and endpoint hygiene matter so much (more on this in 08-06: VPN Attacks & Weaknesses).

🛠️ The Two Essential Pieces of a Real VPN¶

Every real VPN implementation needs to solve two separate problems:

Tunneling — how do you take a packet destined for the private network and carry it across the public network to the right place? This is a routing/encapsulation problem, covered in depth in 08-03: Tunnel vs. Transport Mode.
Protection — how do you make sure that packet can't be read or modified while it's inside the tunnel? This is a cryptography problem, covered in 08-02: IPsec Fundamentals and 08-04: Building a VPN Tunnel.

💡 It's entirely possible to build a "tunnel" with zero encryption — you're just wrapping one packet inside another and routing it. That's a valid learning exercise for understanding tunneling mechanics, but it is not a VPN in the security sense until protection (encryption + integrity) is added. Don't confuse "my traffic goes through a tunnel" with "my traffic is safe."

📌 Key Takeaways¶

A VPN extends a private network over a public network, giving you the low cost of the Internet with the confidentiality of a dedicated line.
VPNs solve two problems at once: protecting traffic in transit, and letting remote parties authenticate their way into a network that isn't directly exposed.
Site-to-site VPNs connect two whole networks (gateway to gateway); remote-access VPNs connect a single device to a network (client to gateway).
A VPN and a firewall are complementary: the firewall enforces the boundary and default-deny policy; the VPN creates one authenticated, encrypted doorway through that boundary.
Relying on source IP address alone for trust is weak — a VPN's authentication step is a much stronger basis for deciding who is "inside."
A real VPN needs both tunneling (getting the packet there) and protection (keeping it confidential and tamper-evident) — tunneling alone is not security.
A compromised VPN client is treated as a trusted internal device, so VPN authentication and endpoint hygiene are critical, not optional extras.