Firewall, Forward vs Reverse Proxy, and VPN

By the end of this lesson you will be able to

• Explain what a firewall checks, why rule order and “default deny” matter, and how a stateful firewall lets replies back in.
• Tell a network firewall, a WAF, an IDS and an IPS apart, and design a simple DMZ.
• Configure cloud security groups and NACLs without the classic ephemeral-port mistake.
• Explain forward and reverse proxies, who each one represents and hides, and how HTTPS passes through a proxy (CONNECT).
• Describe what a reverse proxy does in production: load balancing with health checks, TLS termination, caching, routing, rate limiting, X-Forwarded-For, and where an API gateway fits.
• Explain how a VPN tunnel works, the main protocols, remote-access vs site-to-site, and exactly what a VPN does and does not hide.
• Name the typical attack at each network layer and the defence that works at that layer, and explain why zero trust and mTLS go beyond a network perimeter.

#Three middlemen, three different jobs

Between your device and a server there are often machines that are not the final destination but still handle your traffic. The three you will meet everywhere:

They are often combined: a company network has a firewall at the edge, staff browse through a forward proxy, the website sits behind a reverse proxy, and remote staff connect through a VPN. Keep their jobs separate in your head and the combinations become easy.

#Firewall

A firewall is a network security system that inspects incoming and outgoing traffic and allows or blocks it based on predefined security rules.

[Unfiltered internet] ──► [Firewall: rule inspection] ──► [Secured internal network]
                                    │
                               (block / drop)

#Packet filtering: rules, order and default deny

The most basic firewall job is packet filtering. For every packet it reads a few header fields:

• Source IP and destination IP: who is sending, and to whom.
• Source port and destination port: which service (443 = HTTPS, 22 = SSH, 3306 = MySQL…).
• Protocol: TCP, UDP, ICMP.
• Direction: inbound (from outside to inside) or outbound (inside to outside).

It compares them with a rule table, from the top down. The first matching rule decides, and the rest are not read. If nothing matches, the default policy applies, which on any well-run firewall is deny.

• Inbound rules filter traffic coming in. Classic example: keep port 22 (SSH) closed to the world, and open it only to the admin’s address or a VPN.
• Outbound rules (egress filtering) control traffic going out. Examples: stop office computers reaching harmful or banned categories of site, or stop an infected machine connecting to its attacker on an unusual port.
• Order is part of the policy. A specific allow (“SSH from 192.0.2.50”) must sit above the general deny (“SSH from anyone”). A forgotten “allow any to any” at the top silently disables everything below it.
• Default deny, then allow what you need is far safer than “allow everything, then block what looks bad”. You cannot list every bad thing; you can list the few good ones.
• Drop vs reject. Dropping sends nothing back (scanners learn less); rejecting replies with a TCP RST or ICMP error (honest clients fail fast). Internet-facing edges usually drop.

#Stateful inspection

A simple packet filter judges each packet alone. That creates a problem with replies. When your laptop opens a connection to a website, it uses a random high source port (an ephemeral port, say 51000). The website’s answer arrives inbound to port 51000. A stateless filter must have a rule for that, and since the port is random the rule must be broad (“allow inbound to 1024–65535”), which also lets in anything else aimed at those ports.

A stateful firewall solves this by tracking whole connections in a state table (also called a connection table). Outbound connections create an entry; inbound packets are allowed only if they belong to an existing entry. Modern firewalls work this way, as the notes say: they do not decide from one packet alone, they track the whole session, and let traffic in only if it is the response to a valid request started from inside.

Two practical consequences:

• Home routers and cloud security groups are stateful, which is why “block all inbound, allow all outbound” just works: replies come back, unsolicited connections do not.
• State tables are finite, so idle entries expire. A long-lived connection that sends nothing (a database pool, a chat socket) can be silently cut by a firewall or NAT device in between. Keepalives shorter than the idle timeout prevent it.

#Hardware and software firewalls

Use both layers: the network firewall stops most junk at the edge, and the host firewall still protects a machine if something inside the network is compromised or a laptop joins café Wi-Fi.

#Beyond packet filters: WAF, IDS/IPS and the DMZ

A packet filter sees addresses and ports. Many attacks arrive on port 443, inside perfectly valid connections. Other layers catch those:

• WAF (Web Application Firewall): works at the application layer. It terminates TLS, reads the HTTP request and blocks attacks such as SQL injection, cross-site scripting (XSS) and abusive bots. Cloudflare, AWS WAF and open-source rule sets are common.
• IDS (Intrusion Detection System): watches a copy of the traffic for known attack signatures and unusual behaviour, and alerts. It is not in the path, so it cannot stop anything by itself.
• IPS (Intrusion Prevention System): sits inline and blocks what it detects. More protective, but a false positive blocks real users, and it must keep up with full traffic speed.
• NGFW (next-generation firewall): one appliance combining stateful filtering, IPS, application awareness (“this is Facebook video”) and often TLS inspection.
• DMZ (demilitarised zone): a separate network zone for servers the internet must reach (web servers, mail relays). The internet can reach the DMZ; the DMZ can reach the inside only through narrow, specific rules. If a DMZ server is broken into, the attacker is still outside the database network.

#Firewalls in the cloud: security groups and NACLs

In AWS (and similarly in other clouds) every packet to a server passes two filters:

The bug in the second scenario catches almost everyone once: a NACL that allows only port 443 outbound drops every response, because responses go to the client’s ephemeral port, not to 443.

#Proxy servers

Proxy means “representative”: someone who acts on another’s behalf. A proxy server is a middleman that receives requests and makes them itself. There are two kinds, and their purposes are opposite:

Forward proxy:
[Client A, B, C] ──► [Forward proxy] ──► [Internet] ──► [Destination server]
(hides the clients and sends requests on their behalf)

Reverse proxy:
[Internet clients] ──► [Reverse proxy] ──► [Server 1 / Server 2 / Server 3]
(hides the servers and receives requests on their behalf)

The quick test: whose side is it on? A forward proxy is configured and run by (or for) the clients. A reverse proxy is run by the website owner, and clients usually do not know it exists.

#Forward proxy

A forward proxy sits in front of the clients. When a client wants a site, it does not connect directly: it asks the proxy, and the proxy fetches the data from the site and hands it back.

Its main purposes:

• Anonymity: the destination server sees the proxy’s IP, not the client’s real IP.
• Bypassing geo-restrictions: a proxy in another country makes you appear to be there. The same trick bypasses office or school restrictions, which is why organisations block known proxies.
• Content filtering and access control: an office can stop staff using Facebook or irrelevant sites, block malware and phishing sites for everyone, and log who went where.
• Caching: popular files are served from the proxy, saving bandwidth (much less effective today, because most traffic is HTTPS and cannot be cached by a proxy that does not decrypt it).

How the client reaches the proxy:

• Configured proxy: the browser or OS has the proxy’s address. For plain HTTP it sends the full URL to the proxy (GET http://example.com/news).
• HTTPS through a proxy: the browser sends CONNECT example.com:443, the proxy opens a TCP connection and then just relays encrypted bytes. TLS stays end to end; the proxy knows the host name, not the page. Seeing inside requires TLS interception: the company installs its own root certificate on staff devices and the proxy decrypts and re-encrypts. That is powerful and risky, and apps that pin certificates break.
• PAC file (proxy auto-config): a small JavaScript file that tells the browser which proxy to use for which URL (“internal sites direct, everything else via the proxy”). Companies push it to all devices.
• Transparent (intercepting) proxy: nothing is configured; the network gateway silently redirects traffic into the proxy. Hotel Wi-Fi login pages and some ISP caches work this way.
• SOCKS proxy: a lower-level proxy that relays any TCP (and SOCKS5 also UDP) connection, not just HTTP. SSH can create one (ssh -D).

#Reverse proxy

A reverse proxy sits in front of the servers. Users think they are hitting the real web server, but they are actually hitting the reverse proxy, which accepts the request and passes it to a suitable internal server (a backend node).

What it does for you:

• Load balancing: spreads millions of users across several backend servers (round robin, least connections, IP hash), using health checks to stop sending traffic to a server that fails.
• Security and DDoS protection: the origin servers’ real IPs stay hidden, so attackers can only hit the proxy, which is built to absorb floods (Cloudflare is the famous example). This only works if the origin also refuses traffic that does not come from the proxy.
• TLS (SSL) termination: the heavy encryption work happens between client and proxy, so backend servers are free for application work, and certificates live in one place.
• Caching: static content (images, files, CSS) is served from the proxy without bothering the servers.
• Plus, in practice: compression, rate limiting (429 Too Many Requests), path- and host-based routing to different services, adding X-Forwarded-For and X-Forwarded-Proto headers so backends know the real client, request size limits and timeouts, and zero-downtime deploys by draining one server at a time.

Popular software: Nginx, HAProxy, Envoy, Traefik, Caddy; managed: Cloudflare, AWS Application Load Balancer, Google Cloud Load Balancing. How these programs work inside is the subject of Web Servers and App Servers.

#Where TLS ends

Where the encryption stops decides what the proxy can do. Termination gives it full visibility (cache, route, add headers); re-encryption keeps every hop encrypted, as compliance or zero-trust networks require; passthrough keeps the keys on the backend but turns the proxy into a blind layer 4 relay that routes only on the server name (SNI).

#The API gateway: a specialised reverse proxy

An API gateway (Kong, AWS API Gateway, Apigee, Envoy-based gateways) sits where a reverse proxy sits, but understands APIs: it verifies tokens (JWT, API keys), enforces per-client quotas, routes /v1/orders and /v1/users to different microservices, transforms or combines responses, and gives one place for API logs and metrics.

Rule of thumb: put cross-cutting concerns in the gateway (authentication, rate limits, routing, logging), and keep business logic in the services. A gateway that knows too much becomes a bottleneck every team has to change.

#Forward vs reverse proxy

The notes list “VPN services” as a forward-proxy example. The role is similar (a middleman that hides your IP), but a VPN works at the network layer for all traffic from every app, while a proxy usually works per application. The comparison table in the VPN section below makes the difference precise.

#VPN (Virtual Private Network)

A VPN creates an encrypted, secure virtual tunnel across an open, untrusted public network such as the internet.

                     Unsecured public network
[Client] ═══ encrypted VPN tunnel (e.g. AES-256) ═══► [VPN server] ──► [Target website]

How it works:

1. Tunnelling protocol: VPN client software (WireGuard, OpenVPN, IPsec) sets up a tunnel between your device and the VPN server, after both sides authenticate and agree keys.
2. Encryption: every packet leaving your device is encrypted (with AES-256, or ChaCha20 in WireGuard) and wrapped inside a new packet addressed to the VPN server. Your ISP, a hacker on the same Wi-Fi or the Wi-Fi owner cannot see what you send or receive, or which sites you visit.
3. IP masking: your traffic reaches the website via the VPN server, which forwards it from its own address. The website sees the VPN server’s IP instead of yours.

Inside the tunnel it is literally a packet inside a packet:

#Protocols

Older protocols such as PPTP are broken and should not be used.

#Remote-access vs site-to-site

• Remote-access VPN: one user’s device connects to the company network, gets an internal address, and can reach private servers. Needs client software and strong sign-in (with a second factor).
• Site-to-site VPN: two gateways keep a permanent tunnel so two offices (or an office and a cloud network) act as one network. Devices need no VPN software. Cloud providers sell this as a managed service.
• Consumer VPN services (NordVPN and similar) are remote-access VPNs whose “company network” is simply the internet, used for privacy on public Wi-Fi or to appear in another country.

#Full vs split tunnel, DNS leaks and kill switches

• Full tunnel: all traffic goes through the VPN. Most private, lets a company filter everything, but slower and loads the VPN.
• Split tunnel: only some traffic (company networks) goes through the VPN; the rest goes directly. Faster, but the device is on the open internet and the private network at the same time.
• DNS leak: the tunnel is up but DNS queries still go to the ISP’s resolver outside it, revealing every name you visit. A good VPN client pushes its own resolver and blocks DNS outside the tunnel. WebRTC in browsers can similarly reveal your real IP.
• Kill switch: if the tunnel drops, a local firewall rule blocks all traffic until it reconnects, instead of silently falling back to your real connection.

#VPN vs proxy vs Tor

#Attacks by layer, and the defence at each

Firewalls, proxies and VPNs are each one layer of protection. Attacks arrive at every layer of the network model, and each layer has its own defence. The rule of thumb: an attack can only be stopped by something that sees its layer. A packet filter cannot see an SQL injection inside a valid HTTPS request, and a WAF in the data centre cannot see ARP spoofing on an office LAN.

Two ideas come out of that table:

• Defence in depth. No layer is enough on its own. The edge firewall cuts out most junk so the expensive layers above are not overwhelmed; the WAF is a safety net for buggy code; the code itself is the real fix for injection. If one layer fails, the next one still stands.
• Encryption protects everything below it. An ARP-spoofing attacker or a cable tap gets only ciphertext if the traffic is TLS or a VPN. That is why modern networks encrypt even inside traffic, which leads straight to zero trust.

#Between services: mTLS and zero trust

The classic company network is a castle with a moat: a firewall at the edge, and everything inside trusted. Its weakness shows the day an attacker gets one machine inside, through a phished laptop or a vulnerable web server: from there they can reach everything else, because the inside trusts the inside. This lateral movement is part of most serious breaches.

Zero trust drops the idea of a trusted network. Every request must prove who it comes from and be authorised, wherever it comes from:

• Between services, the proof is mutual TLS (mTLS). Both sides present certificates, so the payments service knows the caller really is the orders service, not just “something at 10.0.3.7”. The certificates are short-lived and issued automatically, usually by a service mesh (Istio, Linkerd) or the platform, so nobody handles keys by hand.
• Identity is followed by policy: “orders may call payments; nothing else may”. A compromised web server can no longer reach the database just because it sits on the same network.
• For people, the same idea replaces the VPN with an identity-aware proxy: every internal app checks the user and the device on every request (Google runs its own staff access this way).

Firewalls and network segmentation still matter as extra layers; zero trust only stops treating the network location as proof of anything. Identities, certificates, tokens and access policies get their full treatment in chapter 33, Identity and Access.

#How these appear in system design

A typical production request path combines all three ideas:

User ─► DNS ─► CDN / WAF / DDoS protection ─► load balancer (reverse proxy, TLS termination)
     ─► API gateway ─► services (in private subnets, security groups)
     ─► database (reachable only from the services)

Engineers ─► VPN or zero-trust access ─► private admin tools (never SSH open to the internet)
Services  ─► NAT gateway / egress proxy ─► third-party APIs (outbound allow list)

Design points interviewers and incidents ask about:

• The reverse proxy is a single point of failure unless it is redundant: run at least two load balancer nodes (or use a managed, multi-zone one) behind one DNS name or a floating IP.
• Health checks must test something real. A /healthz that returns 200 while the database is unreachable sends users to a broken server; a check that is too strict can take every server out at once.
• Keep servers private. Only the load balancer has a public address; security groups allow the app port only from the load balancer’s group, and the database port only from the app’s group.
• Admin access through a VPN, a bastion host or a zero-trust access service, never port 22 open to the world.
• Egress control limits what a compromised service can reach and gives a stable outbound IP that partners can allow-list.
• Preserve the client IP through every proxy (X-Forwarded-For, or HAProxy’s proxy protocol for plain TCP) and trust it only from your own proxies.
• Automate certificate renewal at the TLS termination point; expiry is one of the most common self-inflicted outages.
• Layer the defences: DDoS scrubbing and the edge firewall for layers 3–4, a WAF and rate limits for layer 7, and mTLS with per-service policy inside, so one breached machine is not a breached system.

#Try it yourself

# Linux (Ubuntu): a sensible host firewall in five lines
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 443/tcp
sudo ufw allow from 192.0.2.50 to any port 22 proto tcp   # SSH only from one address
sudo ufw enable && sudo ufw status numbered               # rules in order

# Windows (PowerShell): firewall profiles and a rule
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction
New-NetFirewallRule -DisplayName "Block 3306 in" -Direction Inbound -Protocol TCP -LocalPort 3306 -Action Block

# Watch a forward proxy's CONNECT tunnel (any proxy you have access to)
curl -v -x http://proxy.example.com:3128 https://example.com/ 2>&1 | grep -i connect

# Look for reverse proxies and caches in response headers
curl -sI https://www.cloudflare.com | grep -iE "server|cf-cache-status|age"

# Your public IP, with and without the VPN connected
curl https://ifconfig.me

A minimal Nginx reverse proxy with load balancing and the usual headers:

upstream web_pool {
    server 10.0.0.11:8080 max_fails=3 fail_timeout=10s;
    server 10.0.0.12:8080 max_fails=3 fail_timeout=10s;
}
server {
    listen 443 ssl;
    server_name shop.example.com;
    ssl_certificate     /etc/ssl/shop.crt;   # TLS terminates here
    ssl_certificate_key /etc/ssl/shop.key;

    location /api/orders/ { proxy_pass http://10.0.0.21:8080; }   # path-based routing
    location / {
        proxy_pass http://web_pool;
        proxy_set_header X-Forwarded-For   $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host              $host;
    }
}

#Summary

Key takeaways

• A firewall allows or blocks traffic using rules on IPs, ports, protocol and direction. Rules are checked top to bottom, first match wins, ending in default deny. Inbound rules guard services (close port 22 to the world); outbound rules stop data and malware getting out.
• Stateful firewalls track connections, so replies come back without broad inbound rules. Stateless filters (router ACLs, cloud NACLs) need explicit rules for return traffic on ephemeral ports. Idle state expires: use keepalives.
• Hardware firewalls protect networks, software firewalls protect hosts; use both. NAT is not a firewall. A WAF reads HTTP, an IDS alerts, an IPS blocks inline, a DMZ isolates public servers. In the cloud, security groups are stateful, NACLs stateless.
• A forward proxy acts for clients: anonymity, geo-bypass, filtering, caching. HTTPS passes through it with CONNECT, end to end, unless the company intercepts TLS.
• A reverse proxy acts for servers: load balancing with health checks, hiding the origin and absorbing DDoS, TLS termination, caching, routing, rate limiting, X-Forwarded-For. An API gateway is a reverse proxy specialised for APIs.
• A VPN wraps encrypted packets inside packets to a VPN server (WireGuard, OpenVPN, IPsec): the local network and ISP see only the tunnel, and websites see the VPN’s IP. It does not hide you from the VPN provider or from sites you log in to. Watch for DNS leaks; use a kill switch.
• Every layer has its own attacks and defences: tapping (physical security, encryption), ARP spoofing (Dynamic ARP Inspection), IP spoofing and floods (ingress filtering, scrubbing), SYN floods and scans (SYN cookies, default deny), SQL injection and HTTP floods (WAF, safe code, rate limits). Zero trust adds mTLS and per-service policy so being inside the network proves nothing.

Self-check: firewalls, proxies, VPNs and layered defence30 questions