← All challenges
mediumsecurity~50 min

Lock down the server subnet without locking yourself out

Write an ACL that enforces a precise access policy, in the right place and direction, respecting the implicit deny.

Scenario

Security wants the server subnet locked down. The policy:

  • The user LAN may reach server 10.0.2.10 on TCP 80 and 443 only.
  • All other user access to the server subnet is denied.
  • The admin host (10.0.9.5) keeps full access.
  • Nothing else on the network should break.

Topology

  • User LAN 10.0.1.0/24 (user host 10.0.1.10)
  • Admin LAN 10.0.9.0/24 (admin host 10.0.9.5)
  • Server subnet 10.0.2.0/24 (server 10.0.2.10, listening on 80, 443, and 22)
  • A router routes between all three; everything is reachable with no filter yet.

Your job

Write the ACL, apply it on the correct interface and direction, and get the ordering right so the policy holds and nothing unrelated breaks.

What "done" looks like

Web (80/443) from a user host to the server works; other ports to the server subnet are denied from users; the admin host is unaffected; nothing else breaks.

Teaches: ACL ordering, direction, the implicit deny, and the classic "don't lock yourself out" lesson.

Tooling

Arista cEOS (native ACL syntax matches what learners study). Free fallback: nftables on a Linux router. Validate syntax on first deploy.

What gets checked

Your solution is verified against each of these:

  • A user host can reach the server (10.0.2.10) on TCP 80
  • A user host is denied other access to the server subnet (e.g. TCP 22)
  • The admin host retains access to the server

Solve it in the browser lab

No setup, no install. Open a live lab: configure each device in the editor or its Cisco IOS terminal, run show/ping/traceroute (or test from the hosts), and watch the network react. The in-house engine grades your fix instantly and issues your proof the moment every check passes.

Open the lab →

Prefer your own lab?

  1. Build the fix locally. New to the tooling? See setting up your lab.
  2. Push your topology file, device configs, and any playbooks to a public repo (GitHub or GitLab).
  3. Submit the repo link. We review it by hand, confirm it works, and issue your proof page.
Submit your solution →