The scenario
The WiFi-AP connects the Laptop, the shop's DHCP-Server (10.10.0.2) and the Shop-Router (10.10.0.1) on 10.10.0.0/24. The DHCP-Server's pool offers addresses from 10.10.0.100 to 10.10.0.200 with gateway 10.10.0.1, and its DNS server option is empty. The Laptop has no address configured. When it joins, the lab gives it a free address from the pool and a default route marked 'via DHCP'; in a live lab the Laptop runs a real DHCP client and gets its lease from the DHCP-Server, so the exact address can differ. Either way the lease contains no DNS server. The Shop-Router translates every WiFi client to its public address, 203.0.113.10. On the other side are a Website (203.0.113.80) and a Public-DNS server (203.0.113.53) that knows www.example.com is 203.0.113.80.
What you will work out
Understand what a DHCP lease gives a device, how the shop's router shares one public address through NAT, and why a device with an address and a gateway still cannot use names without a DNS server.
Why this matters
'Connected to WiFi but nothing loads' has a handful of causes, and this lab separates two of them: no address at all (DHCP failed) and an address with no working DNS (the lease left it out, or the DNS server is unreachable). Trying an IP address directly is the quickest way to tell a DNS problem from a connectivity problem. Remember too that on shared WiFi the network's operator can see anything you send unencrypted; HTTPS keeps the content private.
Running it
Coffee Shop WiFi: DHCP + NAT 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 Coffee Shop WiFi: DHCP + NAT
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →