Proxies, VPNs & NAT: When the Path Isn't What You Expect

Chapter 7 found that traffic behaved differently depending on whether it came from the office, over VPN, or directly from home — and left the actual mechanism unexplained. This chapter covers the three things most likely to be quietly rewriting the path itself: NAT changing which address the far end actually sees, a VPN routing only some traffic (or all of it) somewhere unexpected, and a proxy sitting in the middle without the client necessarily even knowing it's there.

NAT: Why "My IP" and "The IP the Server Sees" Aren't the Same

Chapter 3's ipconfig output showed a private address like 192.168.1.42 — an address that's only meaningful on the local network. The router performing Network Address Translation (NAT) rewrites that private address to its own public one before traffic leaves the local network, and rewrites the reply back on the way in. This matters diagnostically more than it might seem: a server's own logs, or a firewall rule written to allow a specific "user's IP," will reference the public, NAT'd address — not the private one the user's own machine reports. Comparing the two, when they're expected to match and don't, is a genuinely common source of confusion.

A quick "what's my public IP" check like this is worth running before comparing a user's own reported address against anything in server logs or a firewall rule — otherwise you're comparing two genuinely different addresses and drawing conclusions from a mismatch that was never meaningful in the first place.

VPN: Full Tunnel vs. Split Tunnel

Chapter 7's ticket resolves here: a full-tunnel VPN routes every packet through the VPN, internal and general internet traffic alike — while a split-tunnel VPN routes only traffic destined for specific internal ranges through the tunnel, leaving everything else to go directly out the local internet connection as normal. Whether a given connection actually goes through the tunnel or not depends entirely on which mode is configured — "connected to VPN" alone doesn't tell you which one you're dealing with.

Proxies: Explicit and Transparent

An explicit proxy is one the client is deliberately configured to use — a browser or application setting pointing traffic at a specific proxy server. A transparent (or intercepting) proxy redirects traffic without any client-side configuration at all, commonly used on corporate networks for content filtering or security scanning — which means a support engineer troubleshooting a client that has no proxy settings configured can still be dealing with one, invisibly, at the network level.

One specific transparent-proxy behavior is worth knowing before Chapter 9 goes deep on TLS: some corporate security proxies perform TLS inspection — decrypting HTTPS traffic, inspecting it, then re-encrypting it with the proxy's own internal certificate before passing it on. A browser that already trusts that internal certificate authority (often pushed out by IT via group policy) sees nothing unusual. A script, a command-line tool, or any client that doesn't already trust that same internal CA will see the connection as presenting an untrusted certificate — because, from that client's point of view, it is one.

Working Example: A Script That Fails Where a Browser Doesn't

A ticket: an automation script calling an external API fails with a certificate validation error, but a colleague can reach the exact same API fine from their browser, from the same corporate network. Both facts turn out to be true, and neither is really about the API itself:

The browser trusts the corporate network's own internal certificate authority, pushed out to every managed machine — so it sees the TLS-inspecting proxy's re-issued certificate as perfectly valid and never shows a problem. The script's HTTP client, running with its own default trust store, has never heard of that internal CA, and correctly refuses to trust a certificate signed by an authority it doesn't recognize. Neither the API nor the network connection is actually broken; the fix belongs to the script's own environment — installing the corporate CA certificate into its trust store — not to anything on the network path itself. Chapter 9 covers reading a TLS handshake failure like this one in full.

Hands-On Exercises