The scenario
PC-A (192.168.1.10/24) is cabled to the Firewall's ge0 (192.168.1.1/24). Server (192.168.1.50/24, a web server on TCP port 80) is cabled to the Firewall's ge1 (192.168.1.2/24). The Firewall allows ICMP and TCP port 80. It looks right, but both sides use the same network. PC-A's mask says 192.168.1.50 is on its own network, so PC-A does not send to its gateway: it asks 'who has 192.168.1.50?' on its own cable, where only the Firewall's ge0 is, and nobody answers. The Firewall never sees the packet, so its rules never get a say. The fix is to give the Server's side its own network.
What you will work out
Understand why each side of a firewall or router needs its own subnet, and why the failure shows up at the hosts before the firewall is ever involved.
Why this matters
Putting the same subnet on both sides of a router or firewall is an easy mistake when a network is extended or a firewall is dropped into an existing segment. It produces a confusing symptom: the firewall's rules look correct, its logs show nothing, and traffic still fails, because the hosts never send anything to it. When a firewall seems to ignore traffic, first check that the source and destination are on different subnets and that the traffic is really routed through it.
Running it
Why My Firewall Doesn't Forward 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.
Open Why My Firewall Doesn't Forward
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →