Firewall + NAT: Defense in Depth

The scenario

Office PC (192.168.1.10) sends everything off its LAN to the Firewall (192.168.1.1). The Firewall forwards what its rules allow to the NAT Gateway (10.0.0.2) over a transit network, 10.0.0.0/24, and the NAT Gateway translates the source to its public address 203.0.113.1 on the way to the Web Server (203.0.113.50). The Web Server runs HTTP (TCP 80), HTTPS (TCP 443) and SSH (TCP 22). The Firewall drops anything it forwards that no rule allows, and its rules allow TCP 80 (priority 10), TCP 443 (priority 11) and ICMP (priority 20). Both devices use static routes only: the Firewall's default route points at 10.0.0.2, and the NAT Gateway's route to 192.168.1.0/24 points back at 10.0.0.1.

What you will work out

See how a firewall and a NAT gateway work together, and why filtering and address translation are separate jobs.

Why this matters

Cloud networks split these jobs the same way. In AWS, security groups filter traffic for each instance and are stateful, while a NAT Gateway gives instances in private subnets outbound internet access and does not accept connections started from the internet. Knowing which device filters and which translates tells you where to look: a connection that is blocked needs a rule, a connection that leaves with the wrong address needs NAT.

Running it

Firewall + NAT: Defense in Depth opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.