The scenario
Four services form a chain: Frontend (10.0.1.10) calls API (10.0.2.10) on TCP 8080, API calls Auth (10.0.3.10) on TCP 443, and Auth queries Database (10.0.4.10) on TCP 5432. Each service sits behind its own firewall. FW-API allows Frontend to reach API on TCP 8080 and to ping it. FW-Auth allows API to reach Auth on TCP 443. FW-DB allows Auth to reach Database on TCP 5432. No other traffic is allowed through any of the firewalls; replies to the allowed connections return automatically. Routes send each flow through the firewall that guards its destination: API reaches both the Auth and Database subnets through FW-Auth, and Auth reaches the Database subnet through FW-DB. So when API tries to reach Database directly, it is FW-Auth that stops it, not a missing route.
What you will work out
Learn microsegmentation: a firewall at every service boundary, rules that name exact sources, and routing that sends each flow through the gate meant to judge it.
Why this matters
A design with a firewall only at the perimeter trusts everything inside it, so one compromised machine can reach everything else. Segmenting at every service boundary limits how far an attacker can move. It also makes the policy readable: each rule is a statement that one named service may call another on one port, which is easy to review and easy to spot when it is missing. Compliance frameworks such as PCI DSS also use segmentation to limit which systems are in scope.
Running it
Zero Trust: Microsegmentation 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 Zero Trust: Microsegmentation
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →