Firewalls, proxies, VPNs, and load balancers

Overview

When you send a request to a server, you rarely reach the server directly. Between your machine and the application there is usually a chain of devices whose whole job is to filter, forward, protect, and distribute traffic. Together these devices form the network perimeter — the boundary where a private network meets the outside world.

Understanding the perimeter is what turns confusing results into readable ones. Why did a port report filtered? Why does one IP address seem to host a dozen different websites? Why did the same request return two different answers a second apart? Each of these has a perimeter device behind it, and once you can name the device you can reason about what is really happening.

This lesson builds directly on TCP vs UDP, ports, and the ones to know. In that lesson you learned that a service listens on a port and that a TCP connection is set up with a handshake. Here you will see what sits in front of those ports: the firewall that decides whether your handshake packet is even allowed through, and the proxies and balancers that may answer on the real server's behalf. In plain terms: last lesson taught you the door and its number; this lesson teaches you the security guards, receptionists, and traffic directors standing in the hallway before the door.

The four devices we cover are the firewall (a rule-based gate), the proxy (a middleman that forwards requests), the VPN (an encrypted tunnel that places you logically inside a network), and the load balancer (a distributor that spreads requests across many backends).

Why it matters

Perimeter devices are the hidden explanation behind a huge share of "wait, that's weird" moments in networking and security work.

• Filtered ports. A scan that reports no response almost always means a firewall silently dropped your probe — not that the host is offline.
• One IP, many apps. A single public address serving several unrelated websites is the signature of a reverse proxy or shared front end.
• Answers that change. If identical requests return different responses, a load balancer is probably sending you to different backend servers.
• Latency and caching surprises. A forward proxy or CDN may serve a cached copy, so you are not always seeing the live server.

Beyond explaining anomalies, these devices are themselves part of the attack surface. A firewall with an overly permissive rule, a reverse proxy that leaks backend hostnames in error pages, an exposed VPN or load-balancer management interface — each is a real, reportable finding. Knowing how the perimeter is supposed to work is the only way to spot when it is misconfigured.

Core concepts

The perimeter is a layered path. A request typically crosses several of these devices in sequence. Here is the mental picture to hold onto:

  Client                     Network perimeter                    Backend
  ------                     -----------------                    -------

  [You] --> [Firewall] --> [Load balancer] --> [Reverse proxy] --> [App 1]
              rules            spreads            TLS + routing  \-> [App 2]
            allow/block       requests           hides backend   \-> [App 3]

Not every network has all of them, and the order can vary, but the roles are stable. Let's take each device on its own.

1. Firewall

Definition. A firewall is a device or software that allows or blocks traffic according to a set of rules. Rules typically match on source IP, destination IP, port, and protocol (and modern "next-generation" firewalls can also match on the application itself).

Plain-language explanation. Think of a firewall as a bouncer with a guest list. Each packet arrives, the bouncer checks it against the rules top to bottom, and the first matching rule decides its fate: allow or deny. If nothing matches, most firewalls apply a default-deny.

How it works internally — stateful tracking. A stateful firewall keeps a table of active connections. When you start a TCP connection outbound, it records that flow so it can automatically permit the replies coming back. Unsolicited inbound packets that don't belong to any tracked connection get dropped. This is exactly why an outbound-initiated request works fine but an inbound scan of the same host hits a wall.

 Stateful firewall connection table
 +-------------+-------------+-------+---------+
 | Source      | Dest        | Port  | State   |
 +-------------+-------------+-------+---------+
 | 10.0.0.5    | 93.184.x.x  | 443   | ESTAB   |  <- reply allowed
 | 10.0.0.5    | 8.8.8.8     | 53    | ESTAB   |  <- reply allowed
 +-------------+-------------+-------+---------+
 Inbound packet to port 22 with no matching row --> DROPPED (filtered)

Drop vs reject. How a firewall refuses traffic changes what a scanner sees:

When to use it / when not to. Every internet-facing network should have a firewall — it is baseline hygiene, not optional. But a firewall is not a complete defence: it controls which ports and hosts are reachable, not whether the application behind an allowed port is safe. An open port 443 to a vulnerable web app is still a wide-open door.

Common pitfall. Treating filtered as offline. A filtered result means "a device chose not to answer," which is a strong signal something is alive and protected — not a dead end.

Knowledge check. A host replies with a TCP RST to your probe on port 25. Is that port more likely closed or filtered, and why?

2. Proxy

Definition. A proxy is an intermediary that receives a request and forwards it on someone's behalf. The three flavours differ by whose behalf they act on.

How a reverse proxy works internally. The reverse proxy owns the public IP and the TLS certificate. It decrypts incoming HTTPS, decides which backend should handle the request (often by hostname or URL path), forwards it over the internal network, receives the backend's answer, and relays it back to you. The backend's real address is never exposed.

   Client            Reverse proxy                Backends
   ------            -------------                --------
   HTTPS  ------>  terminates TLS
                   Host: shop.example  --> route --> [shop server]
                   Host: blog.example  --> route --> [blog server]
                   /api/*              --> route --> [api server]

When to use each / when not to. A reverse proxy is the right tool for centralising TLS and routing in front of many services; don't rely on it as your only security layer. An intercepting proxy is essential for authorised web testing of your own or in-scope traffic — never point it at systems you have no permission to test.

Common pitfall. Confusing forward and reverse. Remember the rule of thumb: a forward proxy protects/serves the client; a reverse proxy protects/serves the server.

Knowledge check. You scan one IP address and find it responds to three completely different websites depending on the Host header you send. Which perimeter device is almost certainly in play?

3. VPN

Definition. A VPN (virtual private network) is an encrypted tunnel that carries your traffic across an untrusted network as if you were physically connected to a private one.

Plain-language explanation. A VPN wraps your packets inside an encrypted outer packet and ships them to a VPN gateway, which unwraps them and drops them inside the target network. Logically, your laptop now sits behind the perimeter, able to reach internal hosts a firewall would otherwise block.

  Your laptop                  Internet                   Corporate net
  -----------                  --------                   -------------
  app data --> [encrypt] ==== encrypted tunnel ==== [VPN gateway] --> 10.0.0.0/8
                                                    decrypts, you're "inside"

When to use it / when not to. VPNs are the standard way to reach an internal engagement scope or to protect traffic on untrusted Wi-Fi. They are not anonymity tools and they do not make the inside network safe to attack without authorisation — being on the VPN still requires you to stay within your agreed scope.

Common pitfall. Assuming the VPN encrypts everything. Split-tunnel configurations send only some traffic through the tunnel; the rest goes out your normal connection in the clear.

Knowledge check. In your own words, why can you reach an internal 10.0.0.x host over a VPN but not directly from the public internet?

4. Load balancer

Definition. A load balancer distributes incoming requests across a pool of backend servers so no single server is overwhelmed.

How it works internally. Clients connect to one virtual IP owned by the balancer. For each new connection the balancer picks a backend using an algorithm — round-robin, least-connections, or a hash of the client IP — and forwards the request. Health checks pull failing backends out of the pool automatically.

            Virtual IP (one address the world sees)
                        |
                 [ Load balancer ]
            round-robin / least-conn
            /           |          \
     [backend A]   [backend B]   [backend C]
     v1.2 build    v1.2 build    v1.1 build  <- may differ!

Why this matters for testing. Two identical requests can land on two different backends. If those backends are on slightly different versions or configurations, your responses will disagree — a header present in one, absent in the other; a bug that appears "sometimes." That inconsistency is the signal that a balancer is present.

When to use it / when not to. Load balancers are essential for scaling and high availability. But they add a layer that must itself be patched and configured; a balancer that strips or forges the X-Forwarded-For header, for example, can undermine backend logging and access control.

Common pitfall. Chasing a "flaky" bug as if the server were random, when really you are bouncing between backends. Pin the connection (or note the backend identity) before concluding the behaviour is nondeterministic.

Knowledge check. You send the same login request twice and get a Server: nginx/1.20 header once and Server: nginx/1.18 the next time. What is the most likely explanation?

Syntax notes

This is a concept lesson, so there is no C syntax to memorise. What you should internalise instead is the vocabulary and how each device labels traffic. A compact reference:

FILTERED  = a firewall silently DROPPED your probe (no reply, timeout)
CLOSED    = host answered RST/unreachable; port has no listener
OPEN      = a service accepted the handshake

Forward proxy   -> in front of CLIENTS  (egress, caching)
Reverse proxy   -> in front of SERVERS  (TLS, routing, hiding backend)
Intercepting    -> in front of YOU      (Burp/ZAP, edit your own traffic)

VPN             -> encrypted tunnel; puts you logically INSIDE a network
Load balancer   -> one virtual IP -> many backends (inconsistent replies)

When you read a scanner's output, mentally map each odd result to the device that produces it. That mapping is the skill.

Lesson

Between a client and a server sit devices that filter, forward, and distribute traffic. Knowing they are there explains many surprising scan results.

Firewall

A firewall allows or blocks traffic based on rules. Those rules can match on source and destination IP, port, protocol, and sometimes the application itself.

A stateful firewall tracks the state of each connection. This lets it permit replies to traffic you started while still blocking unsolicited inbound traffic.

During a scan, a firewall is the reason a port shows as filtered (no reply) rather than open or closed.

Proxy

A proxy is an intermediary that forwards requests. There are three kinds worth knowing:

• Forward proxy — sits in front of clients. Used for egress control and caching.
• Reverse proxy — sits in front of servers. Handles TLS termination, routing, and hiding the backend.
• Intercepting proxy — a tool such as Burp or ZAP that lets web testers read and modify their own browser traffic.

VPN

A VPN (virtual private network) is an encrypted tunnel. It places a remote client logically inside a network.

On engagements, you often connect over a VPN to reach an internal scope.

Load balancer

A load balancer distributes requests across many backend servers. It can make one IP look like many machines, or many machines look like one.

As a result, identical requests may reach different backends. This matters when your results seem inconsistent.

Why it matters

These devices explain common anomalies:

• Filtered ports (firewall).
• A single front end serving many apps (reverse proxy).
• Responses that change between requests (load balancer).

They are also part of the attack surface. Misconfigured rules and exposed admin panels are real findings.

Code examples

This is a concept lesson, so instead of a program here is a complete worked walkthrough of an nmap scan against a firewalled host, plus the reasoning that turns the output into a conclusion. The scan itself is a standard, well-documented command; the value is in reading it correctly. (Only ever run scans against hosts you own or are explicitly authorised to test — for practice, tools like scanme.nmap.org are provided for exactly this purpose.)

$ nmap -Pn -p 22,80,443,3306,8080 example-lab.internal

Starting Nmap
Nmap scan report for example-lab.internal (10.10.5.20)
Host is up (0.031s latency).

PORT     STATE     SERVICE
22/tcp   filtered  ssh
80/tcp   open      http
443/tcp  open      https
3306/tcp filtered  mysql
8080/tcp closed    http-proxy

What this shows. Five ports were probed. Two are open (80 and 443 — a web front end), one is closed (8080 — a host answered but nothing is listening there), and two are filtered (22 and 3306 — a firewall dropped those probes silently).

How to read it.

• 80 and 443 open, together, on one address: classic web server, very likely behind a reverse proxy terminating TLS on 443.
• 22 filtered, not closed: SSH is probably running but the firewall only allows it from an admin network — you got no reply at all.
• 3306 filtered: the MySQL database is deliberately shielded from your source; a good sign the perimeter policy is doing its job.
• 8080 closed: the host itself responded with a rejection, so no firewall dropped it — there is simply no service on that port.

Expected takeaway. The mix of filtered and closed on the same host is the tell. If a firewall were dropping everything you would see all-filtered; the fact that 8080 comes back closed proves the host is reachable and it is a per-port rule (firewall) causing the filtered results, not a dead host.

Edge cases to keep in mind.

• Without -Pn, nmap first pings the host; a firewall that blocks ping would make nmap skip the host entirely. -Pn says "assume it's up, scan anyway."
• A load balancer in front could send different probes to different backends, so re-running a scan may show slightly different service banners.
• filtered can also (rarely) come from your own outbound firewall dropping the reply — always consider both ends of the path.

Line by line

Let's trace the scan result line by line, following what actually happened on the wire.

The key distinction, walked through slowly. For port 80, the three-step handshake from the previous lesson completed: your SYN, the server's SYN-ACK, your ACK. For port 8080, your SYN was met with a RST — an active "nobody's home" from the host itself. For port 22, nothing came back at all: your SYN vanished into a firewall's drop rule, and nmap waited, retried, and finally reported filtered.

That is the whole logic of perimeter reading in one scan: a reply (even a rejection) means you reached the host; silence means a device between you and the host chose not to answer. Everything else — reverse proxy on 443, DB shielding on 3306 — follows from pattern-matching those signals against the four devices.

Common mistakes

Mistake 1: Reading filtered as "the host is down."

• Wrong approach: "Port 22 is filtered, so this box must be offline — skip it."
• Why it's wrong: Filtered means a firewall actively dropped your probe. That requires a live device on the path. Other ports on the very same host may be open.
• Corrected version: Treat filtered as "alive and protected." Note it, try the ports that are open, and consider whether you can reach the filtered service from an authorised network segment or over the VPN.
• How to prevent it: Always scan several ports. A host that shows a mix of open, closed, and filtered is clearly up.

Mistake 2: Confusing forward and reverse proxies.

• Wrong approach: "The website is behind a forward proxy."
• Why it's wrong: Forward proxies front clients; the thing in front of a website is a reverse proxy.
• Corrected version: Reverse proxy = in front of the server. Forward proxy = in front of you.
• How to prevent it: Ask "whose traffic is this device protecting?" Server → reverse. Client → forward.

Mistake 3: Blaming randomness for load-balancer inconsistency.

• Wrong approach: "This bug only happens sometimes, the app must be flaky."
• Why it's wrong: Two requests may have hit two different backends running different versions.
• Corrected version: Check response headers/banners across requests. If they differ, you are behind a load balancer and should identify each backend before drawing conclusions.
• How to prevent it: Look for Server: header changes, differing cookies, or version strings that alternate.

Mistake 4: Assuming a VPN encrypts all your traffic.

• Wrong approach: "I'm on the VPN, so everything I do is tunnelled and private."
• Why it's wrong: Split-tunnel setups route only some subnets through the tunnel; the rest goes out normally.
• Corrected version: Confirm the routing table / VPN policy. Know which destinations actually traverse the tunnel.
• How to prevent it: Check your effective route for the target address before assuming it's covered.

Debugging tips

Perimeter devices don't throw compiler errors — they throw confusing results. Here is how to debug those.

Symptom: every port shows filtered.

• Likely cause: a firewall dropping all probes, or the host is genuinely unreachable.
• Steps: add -Pn to skip host discovery; try a known-open port like 443; confirm you can reach anything on that network segment. If literally nothing responds anywhere, suspect a routing or VPN problem, not the target.

Symptom: responses change between identical requests.

• Likely cause: a load balancer distributing you across backends.
• Steps: repeat the request several times and diff the response headers. Watch for alternating Server: versions, differing Set-Cookie values, or a load-balancer affinity cookie. Note the pattern before treating any single response as ground truth.

Symptom: one IP serves many unrelated sites.

• Likely cause: a reverse proxy or shared hosting front end routing by Host header.
• Steps: send requests with different Host values and observe the routing. Recognise this as expected reverse-proxy behaviour, not a vulnerability by itself.

Symptom: you can reach a host from one machine but not another.

• Likely cause: firewall source-IP rules, or one machine is on the VPN and the other isn't.
• Steps: compare the two source addresses against the expected allow-list; verify VPN connectivity and the effective route to the target.

Questions to ask when it doesn't make sense.

1. Did I get any reply, or pure silence? (Reply = reached host; silence = something dropped it.)
2. Are my results consistent across repeats, or do they alternate?
3. Am I on the network path I think I'm on (right VPN, right source IP)?
4. Could a cache (forward proxy / CDN) be serving me a stale copy instead of the live server?

Memory safety

This is a concept lesson with no C code, so there is no memory-safety concern in the usual sense. The equivalent discipline here is operational safety and robustness of your reasoning:

• Authorisation first. Only scan or proxy traffic to hosts you own or are explicitly permitted to test. Perimeter probing can trip intrusion-detection systems; unauthorised scanning can be illegal. Practice against sanctioned targets such as scanme.nmap.org or your own lab.
• Don't trust a single observation. Because load balancers and caches can vary responses, treat one reply as a data point, not a fact. Corroborate before reporting.
• Least privilege still applies to you. When you connect over a VPN into a scope, you inherit reach you didn't have before. Stay strictly within the agreed boundaries — being technically able to reach an internal host is not the same as being authorised to test it.
• Log and reproduce. Note the exact command, source address, and timestamp for every result so a surprising finding can be reproduced rather than argued about.

Defensive angle (the perimeter as attack surface). The devices in this lesson are defences, but each is also something an attacker probes:

• A firewall rule that is too permissive (e.g. management ports open to the whole internet) is a finding — pair it with the fix: restrict to an admin source range.
• A reverse proxy that leaks the backend hostname or version in an error page is a finding — the fix is to suppress verbose errors and strip internal headers.
• An exposed VPN or load-balancer management interface is a finding — the fix is to place management on a separate, restricted network.

Whenever you note a misconfiguration, describe it clearly, explain the risk, and state the corrective control — never leave a vulnerability described without its fix.

Real-world uses

Concrete real-world use cases.

• Every major website you visit sits behind a reverse proxy or CDN (nginx, HAProxy, Cloudflare, AWS ALB) that terminates TLS and routes to backend app servers.
• Corporate networks push all outbound web traffic through a forward proxy for filtering and logging.
• Remote work relies on VPNs (WireGuard, OpenVPN, IPsec) to place laptops logically inside the company network.
• High-traffic services (streaming, e-commerce, APIs) use load balancers to scale horizontally and survive individual server failures.
• Security testing uses intercepting proxies (Burp Suite, OWASP ZAP) as the everyday tool for inspecting and modifying web traffic during authorised assessments.

Professional best-practice habits.

For beginners:

• Always scan multiple ports and look at the mix of open/closed/filtered before concluding anything.
• Name the device behind each anomaly out loud — it forces you to reason instead of guess.
• Verify you're on the intended network path (correct VPN, correct source IP) before debugging the target.
• Keep a note of the exact command and result for every observation.

For advanced practitioners:

• Fingerprint the perimeter itself: identify the reverse proxy/CDN, detect load-balancer backends via header and timing differences, and map firewall rules by comparing filtered vs closed responses across ports.
• Account for caching and affinity when interpreting results; pin sessions where the balancer allows it.
• When reporting, separate expected perimeter behaviour from misconfigurations, and always pair a misconfiguration with a concrete remediation.
• Automate reproducibility (scripts, saved scan XML) so findings survive review.

Practice tasks

Beginner 1 — Classify the states.

• Objective: Cement the open/closed/filtered distinction.
• Requirements: Given this output, write one sentence per port explaining what happened on the wire and what device (if any) is responsible:

22/tcp   filtered
80/tcp   open
25/tcp   closed

• Constraints: Use the terms SYN, RST, and drop correctly.
• Hint: A RST is an answer; silence is not.
• Concepts: firewall, stateful filtering, handshake.

Beginner 2 — Match the device.

• Objective: Map anomalies to perimeter devices.
• Requirements: For each observation, name the single most likely device: (a) one IP serves three different websites by Host header; (b) identical requests return alternating Server: versions; (c) a port never replies at all; (d) your laptop can suddenly reach 10.0.0.5 after running a client.
• Constraints: One device per item; justify in a sentence.
• Hint: Re-read the summary table in core concepts.
• Concepts: reverse proxy, load balancer, firewall, VPN.

Intermediate 1 — Forward vs reverse in the wild.

• Objective: Explain proxy direction with a concrete scenario.
• Requirements: Describe a workplace where a forward proxy is used and a website where a reverse proxy is used. For each, state whose traffic it protects and one job it performs.
• Constraints: Use real-sounding but hypothetical examples; no real internal hostnames.
• Hint: "Whose behalf is this proxy acting on?"
• Concepts: forward proxy, reverse proxy, TLS termination.

Intermediate 2 — Design a firewall rule set.

• Objective: Apply least privilege to perimeter rules.
• Requirements: Write a short ordered rule list (in plain English or pseudo-rules) for a web server that should expose 80 and 443 to everyone, allow SSH (22) only from an admin subnet, and drop everything else. State which actions produce closed vs filtered for an outside scanner.
• Input/Output example: Input: probe to 22 from an outside IP → Output: filtered (dropped).
• Constraints: Rules are evaluated top-to-bottom, first match wins; end with a default-deny.
• Hint: Order matters — put the most specific allow rules first.
• Concepts: firewall rules, default-deny, drop vs reject.

Challenge — Diagnose the flaky endpoint.

• Objective: Combine multiple perimeter concepts to explain a real puzzle.
• Requirements: You test a login endpoint and observe: (1) about half your requests set a cookie named AWSALB, half don't; (2) response Server: header alternates between two nginx versions; (3) port 443 is open but port 22 is filtered; (4) an error page occasionally shows an internal hostname app-node-2.internal. Write a short report explaining what perimeter devices are present, which observation points to each, and identify the one item that is a misconfiguration (with its fix).
• Constraints: Ground every claim in a specific observation; no speculation beyond the evidence.
• Hint: AWSALB is a load-balancer affinity cookie; think about what an error page should never reveal.
• Concepts: load balancer, reverse proxy, firewall, misconfiguration + remediation.

Summary

The network perimeter is the layered path of devices between a client and a server, and reading it correctly turns confusing output into evidence.

Main concepts.

• Firewall — allows/blocks by rule; a stateful firewall tracks connections and silently drops unsolicited traffic, which is what produces a filtered port.
• Proxy — a middleman: forward (in front of clients), reverse (in front of servers, does TLS and routing, hides the backend), intercepting (Burp/ZAP for your own traffic).
• VPN — an encrypted tunnel that places you logically inside a network.
• Load balancer — one virtual IP spreading requests across many backends, a common cause of inconsistent responses.

Most important idea. A reply (even a RST rejection) means you reached the host; silence means a device on the path dropped your probe. That single distinction separates closed from filtered and drives all perimeter reasoning.

Common mistakes to avoid. Reading filtered as "host down"; confusing forward and reverse proxies; blaming randomness for load-balancer inconsistency; assuming a VPN tunnels everything.

What to remember. Name the device behind each anomaly, corroborate before concluding, stay strictly within authorised scope, and when you spot a perimeter misconfiguration, always pair it with its fix.

Practice with these exercises

• Token-bucket rate limiter (single slot)