Firewalls, NAT, and VPNs

"Imagine your network as a medieval city: firewalls are the city walls and gates, NAT is the clever gatekeeper who knows everyone's real and fake names, and VPNs are secret tunnels that let you travel safely, unseen by prying eyes!"

Picture your router tonight, sitting quietly on a shelf, doing something you will never see and almost never think about: turning away strangers. Every few seconds, a packet arrives from somewhere on the open internet, addressed to your home network, asking to come in — a scanning bot in another country probing for an open door, background radiation of a hostile internet that never sleeps. Almost all of them are refused, silently, instantly, without you lifting a finger. You never see the rejection. You never see the attempt. That invisible, relentless act of turning strangers away at the gate is the subject of this chapter, and it has a much older, much more human history than you might expect.

The Wall Is Older Than the Internet

The word "firewall" did not start in a computer science paper. It started in construction codes, after cities kept burning down. Following the Great Fire of London in 1666 — which destroyed roughly 13,000 houses in four days because flames simply leapt from one wooden building to the next — building regulations across Europe began requiring thick masonry walls between adjoining structures, specifically designed to stop a fire in one unit from spreading to its neighbor. Later, steam locomotive builders borrowed the same idea and the same name: a metal firewall was bolted between the boiler, where the actual fire burned, and the cab, where the crew sat, so that a firebox failure wouldn't cook the people driving the train. In both cases, the wall wasn't there to prevent every possible disaster — it was there to contain one, so it couldn't spread to everything else.

Computer networking borrowed the metaphor for the exact same reason, and it took a real disaster to make the borrowing urgent. Chapter 1.10 already told the Morris Worm story in full — a graduate student's replication bug taking down roughly a tenth of the early internet in a single weekend — and it's the same incident that made this chapter's subject urgent: it was the first event to make it viscerally clear, to a lot of very smart people at once, that "connected to everything" also meant "reachable by anything." Researchers at Bell Labs, including Bill Cheswick and Steve Bellovin, spent the years afterward formalizing exactly the kind of gatekeeping this chapter is about — and by the early 1990s, "firewall" was the name everyone had settled on for it.

Firewalls: The First Line of Defense

Think of a firewall as the wall and guarded gate around your digital city. Only visitors matching a specific description get through; everyone else is turned away without so much as an explanation. Formally, a firewall monitors and controls incoming and outgoing network traffic based on a set of rules, usually matched against the 5-tuple: source IP, destination IP, source port, destination port, and protocol (TCP, UDP, and so on). Everything a firewall does, no matter how sophisticated, ultimately boils down to checking a packet against that five-part description and deciding: let it through, or don't.

Firewalls come in a few flavors depending on where they stand guard:

• Hardware firewalls are dedicated appliances at the network's edge, like a security checkpoint built into the city gate itself.
• Software firewalls are programs on an individual machine, like a personal bodyguard protecting exactly one client.
• Cloud and security-group firewalls are rules enforced by the cloud provider, protecting virtual machines that may not even share physical hardware — a gate with no physical wall, purely a policy enforced on your behalf.

And they differ just as much in how closely they look at what passes through:

• Stateless (packet-filtering) firewalls evaluate each packet in isolation against static rules — fast, but blind to context: they cannot tell an established, welcome conversation from a fresh, unsolicited one using the same port.
• Stateful firewalls track the condition of each connection — has a handshake completed? Is this part of a conversation we already allowed? — so they can permit reply traffic without a separate rule for every conceivable reply.
• Next-generation (NGFW) or application-layer firewalls read the actual payload, not just the header, telling legitimate HTTPS traffic apart from a disguised, malicious protocol riding the same port 443.

[Internet] ---[Firewall]--- [Internal Network]

Firewalls exist because networks are, structurally, an open invitation: every device with an IP address is theoretically reachable by every other device with one, since the internet was built to route around damage and connect strangers, not to keep them apart. A firewall is the layer of judgment bolted onto a system that was never designed to say no by default.

NAT (Network Address Translation): The Master of Disguise

NAT is the clever gatekeeper who hands every visitor a temporary badge on the way in and keeps a private ledger of who's really who. Formally, NAT rewrites IP addresses — and often port numbers — as packets cross a boundary, most commonly translating many private internal addresses down to one shared public address.

NAT exists because of a piece of arithmetic nobody in 1981 took seriously enough. IPv4 addresses are 32 bits long, which sounds generous until you do the multiplication: roughly 4.3 billion possible addresses, in a world that would go on to connect billions of phones, laptops, servers, and eventually light bulbs. By the early 1990s, with the Web about to set off an explosion of new devices, engineers at the Internet Engineering Task Force ran the numbers and got worried: at the growth rate they were seeing, the entire IPv4 address space looked set to run out well before the decade was over. Two pieces of duct tape held the dam together long enough for a real fix to arrive: CIDR, a smarter way of carving up address blocks, and NAT, formalized by Kjeld Egevang and Paul Francis in RFC 1631 in 1994 — if an entire household or office could share a single public address instead of needing one each, the shortage could be deferred by decades. It worked far better than anyone expected; NAT alone is a large part of why IPv6, designed as the real long-term fix back in the 1990s, only became strictly mandatory for large providers this past decade.

NAT shows up in a few common shapes:

• SNAT (source NAT) rewrites the source address of outbound packets — what your home router does, silently, for every device inside it.
• DNAT (destination NAT) rewrites the destination address of inbound packets — what lets a single public IP forward traffic to a specific internal server, such as port-forwarding to a home server.
• PAT (port address translation), the specific and very common case of NAT where many internal hosts share one public IP by also remapping port numbers, so the router can tell exactly which internal device each reply belongs to.

[Private Devices]
   |
[NAT Router] <---[Public IP: 203.0.113.5]---> [Internet]

NAT does have one well-known cost: it quietly breaks true end-to-end connectivity, the original design promise of the internet. Two devices sitting behind two different NATs cannot simply dial each other directly, because neither one has a real, routable address the other can reach from the outside — there's no true address to knock on, only a disguise. This is the exact problem that peer-to-peer applications — video calls, file-sharing tools, online multiplayer games — solve with techniques like NAT hole punching, where both sides send outbound packets first so their respective NATs create temporary, matching mappings that let replies slip through, or by falling back to a relay server when even that trick fails.

VPN (Virtual Private Network): The Secret Tunnel

If a firewall is a wall and NAT is a disguise, a VPN is the tunnel dug underneath both of them — a secure, encrypted, authenticated passage between your device and a remote endpoint, so that anything traveling inside it stays hidden from whoever might be listening along the way.

Eavesdropping on a wire is not a hypothetical worry invented by paranoid engineers; it has happened, for real, at a scale that reads like a spy novel. During the Cold War, in an operation code-named Ivy Bells, American Navy divers located a Soviet undersea communications cable in the Sea of Okhotsk and physically attached a recording device to it — not by cutting the cable, but by tapping it, listening to unencrypted signals traveling along its length. The tap ran undiscovered for years, quietly proving a point every network engineer since has had to internalize: if a cable carries your traffic in the clear, anyone with physical access to it, or to any point between you and your destination, can potentially read it. A VPN's answer is blunt and effective — encrypt everything before it ever leaves your device, so even a perfect, undetected tap sees only noise.

VPNs earn their keep in several distinct situations: protecting your data on untrusted networks like public Wi-Fi; letting a remote device appear to be "inside" a private network, the classic remote-access VPN used by employees working from home; connecting two entire private networks over the public internet (a site-to-site VPN, linking a company's two office branches without leasing a dedicated line); and masking your apparent location and IP address from the sites you visit.

A full-tunnel VPN routes every scrap of a device's traffic through the tunnel; a split-tunnel VPN only routes traffic destined for specific, usually internal, destinations through it, letting everything else — ordinary web browsing — go directly to the internet, trading some privacy for speed and simplicity.

[Your Device] ===(Encrypted Tunnel)===> [VPN Server] --- [Internet]

That last row has its own small history. PPTP, developed by a consortium that included Microsoft engineer Gurdeep Singh-Pall in the mid-1990s, was the first VPN protocol most ordinary people ever used, simply because Windows shipped built-in support for it — suddenly a small business could let an employee dial into the office network from home without leasing an expensive dedicated telephone line. It also turned out, over the following decade, to have serious cryptographic weaknesses, which is exactly why the table lists it as legacy: convenience got there first, and security caught up afterward, a pattern that repeats constantly in this field.

Firewalls decide who's allowed to knock, NAT decides what name the knocker uses, and a VPN decides who's allowed to overhear the conversation — three different jobs that only look like one because home routers bundle all three.

How They Work Together

Line the three up and a modern home or office network turns out to run a small, silent ritual on every single connection: the firewall blocks unwanted traffic at the gate, based on rules and, usually, connection state; NAT translates addresses so everyone inside can share one public face, incidentally hiding the internal network's true shape from outside eyes; and the VPN lets you travel safely through untrusted territory, making a remote device look, to the firewall, like it's already standing inside the walls it protects.

Real-World Example: Safe Surfing at a Coffee Shop

1. You connect to the coffee shop's public Wi-Fi — a network you don't control, run by people you've never met, shared with strangers you can't vet.
2. Your VPN client establishes an encrypted tunnel to your company's VPN server, the digital equivalent of stepping into that tunnel under the wall the moment you sit down.
3. NAT at the coffee shop's router still translates your device's address for its own outbound traffic, same as always — the VPN tunnel simply rides inside that translated connection.
4. Your company's firewall is configured to accept internal-network traffic only when it arrives through the VPN, rejecting everything else at the edge.
5. You work as if you were plugged in at the office, even sitting in a crowded, unfamiliar room full of strangers.

That whole sequence — wall, disguise, tunnel — happens in the time it takes to open your laptop and load your email, standing on the shoulders of a fire code from 1666, a worm outbreak in 1988, an address-exhaustion panic from the early 1990s, and a Cold War cable tap the public didn't learn about for years. None of this machinery announces itself. It just quietly works, the way a good wall always has.

Frequently Asked Questions

If my home router's NAT already blocks unsolicited inbound connections, do I even need a separate firewall? Yes, and the chapter's warning box on NAT explains exactly why: NAT blocks unrequested inbound traffic only as a side effect of having nowhere to translate it to, not because it was designed to inspect or filter anything. A single port-forwarding rule, something plenty of people add without thinking twice, punches a hole straight through that side effect, and NAT still does nothing to stop malicious traffic between devices that are already inside the same private network.

Why can't two people behind home routers just video-call each other directly, the way two web servers can? Because NAT breaks the internet's original promise of true end-to-end reachability — neither device has a real, publicly routable address the other side can dial into, only a temporary disguise assigned by its own router. That's exactly the problem NAT hole punching was invented to solve: both devices send outbound packets first, tricking their respective NATs into opening matching temporary mappings, so replies can slip through a door neither side ever officially opened.

Is a stateful firewall just a fancier version of a stateless one, or a fundamentally different idea? It's a genuinely different idea, not just an upgrade in speed. A stateless firewall judges every packet in total isolation, which forces awkward, overly broad rules just to let ordinary web replies back in. A stateful firewall instead remembers which connections you actually started, so it can wave through only the replies that belong to those specific conversations — the same trick that quietly lets a home router work without you ever configuring a firewall rule yourself.

Does turning on a VPN mean nobody can track what I do online? No, and this chapter's warning about VPNs is worth taking seriously: a VPN protects your traffic from your local network and your ISP, and it changes which IP address a website sees, but the VPN provider itself typically sees everything your ISP used to see, and anything traveling inside the tunnel — login cookies, account sign-ins, browser fingerprints — travels right along with you. A VPN defends the path your data takes, not your identity once that data arrives somewhere.

Why does the coffee-shop walkthrough bother layering a VPN on top of NAT and a firewall instead of just picking one? Because each one is solving a completely different problem, and the coffee-shop scenario needs all three at once: NAT is still busy sharing the shop's one public address among every customer's device, your company's firewall is set to reject anything that doesn't arrive through the VPN, and the VPN is what makes your laptop look, from the firewall's point of view, like it never left the office at all. Drop any one layer and the other two stop cooperating the way the walkthrough describes.

Fun Facts & Memes

• The word "firewall" protected buildings and locomotives from real fire for over three centuries before it ever protected a single byte of data.
• NAT is the reason you can have twenty smart bulbs, three laptops, and a smart fridge all online at home, sharing a single public IP address that the outside world sees as just one machine.
• WireGuard's entire codebase is famously small enough that security researchers can read — and have read — the whole thing line by line, unlike some older VPN protocols spanning hundreds of thousands of lines of code accumulated over decades.
• The Morris worm's creator was, in a small irony of history, the son of a chief scientist at the National Security Agency, and the incident he caused led directly to the founding of the first Computer Emergency Response Team (CERT), still coordinating security responses today.