The scenario
A small office has three networks, each on its own interface of Office-FW. Guest WiFi (10.10.0.0/24) is where Guest-Laptop joins through Guest-AP. The staff network (10.20.0.0/24) holds Employee-PC and Printer on Emp-Switch. The server network (10.30.0.0/24) holds App-Server (10.30.0.50), which runs the company web app on HTTP and SSH for admins. Office-FW has one rule: allow anything from the staff network to the server network (priority 10). Nothing mentions the guest network, so the default deny keeps guests away from both staff and servers. Employee-PC and Printer share a subnet, so they talk directly through Emp-Switch and never pass Office-FW at all.
What you will work out
Build office segmentation that really separates guests from servers: understand which traffic crosses the firewall, which never does, and how to open one service without opening the rest.
Why this matters
Guest networks exist so that visitors' devices, which nobody in the office manages, cannot reach company machines. That only works if the thing you want to protect sits behind the firewall on its own subnet; a server on the staff switch is protected from guests but not from anything else plugged into that switch. Cloud networks follow the same pattern with separate subnets for public, private and data resources, controlled by security groups and network ACLs.
Running it
Startup Office: WiFi + Servers + Firewall 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 Startup Office: WiFi + Servers + Firewall
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →