← All challenges
mediumsecurity~35 min

Guest Wi-Fi can reach everything

The guest network has a route straight into the services subnet, file server included. Write an extended ACL so guests get DNS and the portal, and nothing else.

Scenario

The office guest Wi-Fi (192.168.40.0/24) hangs off the same router as the services subnet (10.0.2.0/24): DNS, the guest portal, and the company file server. Both subnets are directly connected, so right now any guest can open SSH to the DNS box or browse the file server's SMB share. The pentest report was not kind.

Guests legitimately need exactly two things from the services subnet:

  • DNS on 10.0.2.53 (UDP 53)
  • the guest portal on 10.0.2.80 (TCP 80 and 443)

Topology

  • GigabitEthernet0/0: guest LAN, 192.168.40.1/24
  • GigabitEthernet0/1: services subnet, 10.0.2.1/24 (DNS .53, portal .80, files .10)

Your job

Write an extended ACL and apply it inbound on the guest interface so that, from the guest subnet:

  • UDP 53 to 10.0.2.53 is permitted,
  • TCP 80 and 443 to 10.0.2.80 are permitted,
  • everything else into 10.0.2.0/24 is denied,
  • and guest traffic that isn't headed for the services subnet is left alone.

What "done" looks like

From a guest host: dig @10.0.2.53 works, the portal loads, and SSH/SMB attempts into the services subnet time out.

Teaches: extended ACLs: matching on protocol, destination and port, rule order, and scoping a deny so it doesn't take out traffic you never meant to touch.

What gets checked

Your solution is verified against each of these:

  • Guests can resolve DNS against 10.0.2.53 (UDP 53)
  • Guests can reach the portal 10.0.2.80 on TCP 80 and 443
  • Everything else from the guest subnet into 10.0.2.0/24 is denied (SSH, SMB, ...)

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 →