Firewalls, VPNs, and IPsec

Two different jobs: filtering versus wrapping

In the previous guide you watched TLS build a private channel between one browser and one server, proving the server's identity with a certificate and then encrypting everything inside. That is powerful, but it is narrow: it protects one application's conversation, and it only works because both ends speak TLS. Real organizations need cruder, broader tools too — defences that act on every packet regardless of which program sent it, and protections that cover machines that have no idea security is happening. This guide is about two of those: the firewall, which decides which packets are even allowed to pass, and the VPN, which wraps your traffic in a protective outer envelope all the way across the Internet.

It helps to keep the two jobs separate in your head. A firewall is about filtering: of the packets that arrive at a boundary, which ones do we drop and which do we let through? A VPN is about wrapping: take packets that would otherwise travel the open Internet in the clear, and put them inside an encrypted, authenticated tunnel so that anyone watching the wire — the eavesdropper and the man-in-the-middle you met in the first guide of this rung — sees only sealed envelopes. Filtering controls who may talk; wrapping controls what an onlooker can learn. Most organizations use both, in layers, because neither one does the other's job.

Stateless versus stateful firewalls

The simplest firewall is a list of rules applied to each packet one at a time, judging it only by what is written in its own headers: the source and destination IP addresses, the protocol (TCP or UDP), and the port numbers. A rule might say 'allow anything to TCP port 443' (so web traffic gets in) and 'drop everything to TCP port 23' (so nobody reaches the ancient, insecure Telnet service). Because it remembers nothing between packets, this is called a stateless or packet-filter firewall. It is fast and cheap, and for blunt rules it works fine.

But statelessness has a real weakness. Suppose someone inside your network opens a connection to a web server: a packet leaves on TCP port 443, and the server's reply comes back. A stateless firewall has no memory that you started that conversation, so to let normal replies in, it must keep a broad rule open for incoming traffic on high port numbers — and that same broad opening can be abused by traffic nobody asked for. The cure is the stateful firewall, which remembers the connections it has seen. When it watches your outgoing packet leave, it records the conversation in a table; when a reply arrives, it checks whether it belongs to a connection you actually started. Replies to your own connections are welcomed; unsolicited packets pretending to be replies are not in the table, so they are dropped.

Notice that a stateful firewall is leaning on something you already know. To recognize a connection it tracks the three-way handshake — the SYN, SYN-ACK, ACK exchange that opens every TCP connection — and follows the sequence numbers afterward. This is also where a stateful firewall can spot trouble: a flood of SYN packets that never complete the handshake is a classic SYN flood, the denial-of-service attack you will meet in the next guide. Tracking state is what lets the firewall tell a real conversation from noise.

IDS and IPS: watching, then acting

Because a firewall's judgement is coarse, organizations add a second pair of eyes. An intrusion detection system, or IDS, sits and watches traffic, comparing it against known attack patterns and against a sense of what normal looks like, and raises an alarm when something seems wrong — a port scan creeping across your machines, a known exploit signature, a flood of half-open connections. An IDS only watches and reports; it is a smoke detector, not a fire door. Its close cousin, the intrusion prevention system or IPS, is allowed to act: when it recognizes an attack it can drop the offending packets or block the source outright. The difference is one word — an IDS detects, an IPS prevents — and in practice the same product often does both.

Be honest about the limits, though. An IDS that matches known signatures is blind to a brand-new attack nobody has a signature for yet, and one that flags anything 'unusual' will cry wolf at the harmless oddities of real traffic — too many false alarms and people stop listening. And just like a firewall, an IDS struggles to inspect encrypted traffic: if the payload is TLS-protected it can study the envelope (who is talking to whom, how much, how often) but not the words inside. These tools narrow the gap that a plain firewall leaves; they do not close it.

VPNs and IPsec: a second envelope around your packets

Now to wrapping. A virtual private network, or VPN, lets two machines — or a laptop and an office network — behave as though they share a private link, even though their packets actually cross the public Internet. The trick is a tunnel: each original packet, headers and all, is treated as mere data and placed inside a brand-new outer packet, which is encrypted and sent across the Internet to the far end, where the outer wrapper is stripped off and the original packet pops out to continue its journey. This is exactly the encapsulation idea from the very first rung — a packet inside a packet — used here for protection instead of layering. IPsec is the most common standard for building these tunnels at the network layer, wrapping ordinary IP packets so that whole networks can be joined securely.

Before the VPN (out in the open):

  [ IP hdr | TCP hdr | your data ]   <- readable by anyone on the path

Through an IPsec tunnel (ESP):

  [ new IP hdr | ESP hdr | ENCRYPTED{ IP hdr | TCP hdr | your data } | ESP auth ]
     |                       |                                          |
   to the VPN              hides the original               proves it wasn't
   gateway                 packet entirely                  forged or altered

IPsec is not one mechanism but a small toolbox, and it reuses every idea from the earlier guides in this rung. The two ends first run a key-exchange handshake (called IKE) that uses public-key cryptography to authenticate each other and to agree on a fresh shared secret — solving the key-distribution problem exactly as TLS does. Then they protect each packet with a protocol called ESP, which encrypts the payload for confidentiality and attaches a message authentication code, the HMAC-style integrity tag from the cryptography guide, so the receiver can detect any tampering. IPsec also includes sequence numbers in each packet specifically to defeat the replay attack — a captured packet replayed later is recognized as stale and discarded. Confidentiality, integrity, authentication, anti-replay: the whole CIA wishlist, applied not to one app but to every packet on the wire.

1. Two endpoints (say your laptop and the office gateway) run the IKE handshake: they authenticate each other with certificates or a shared key and use public-key cryptography to agree on a fresh symmetric session key — without ever sending that key across the wire.
2. Your laptop has a packet to send. Instead of putting it on the Internet directly, it encrypts the entire packet with the session key and attaches an integrity tag and a sequence number.
3. It wraps the encrypted blob in a new outer IP header addressed to the office gateway, and sends that across the open Internet. Anyone watching sees only laptop-to-gateway traffic of unreadable contents.
4. The gateway receives it, checks the integrity tag (rejecting anything forged or altered) and the sequence number (rejecting replays), decrypts the payload, and recovers the original packet.
5. The gateway forwards that original packet onward into the office network as if your laptop had been sitting there all along. Replies come back the same way, encrypted in the reverse direction.

What a VPN does and does not promise

It is worth being clear-eyed about VPNs, because they are heavily marketed and widely misunderstood. What a VPN genuinely gives you is a protected segment: between your machine and the VPN's exit point, your traffic is encrypted and integrity-protected, so your local network, your coffee-shop Wi-Fi, and your Internet provider can no longer read what you are doing or tamper with it. That is real and useful. But the protection stops at the exit. From the VPN's exit point onward to the actual website, your traffic travels exactly as it normally would — which means the VPN operator becomes the new party who can see your unencrypted traffic. You have not removed trust; you have moved it from your local network to whoever runs the VPN.

Two more honest points. First, a VPN is not the same thing as TLS, and it does not replace it. If the website you visit uses HTTPS — and it should — then your traffic is already end-to-end encrypted to that site, VPN or no VPN; the VPN just adds an extra wrapped segment near your end. The two protections live at different layers and solve overlapping but distinct problems. Second, do not confuse a VPN with anonymity. Your traffic still has to exit somewhere, that exit has an IP address, and the destination still learns plenty about you from the request itself. A VPN hides your traffic from your local network and your provider; it does not make you invisible.