Lab 5: Switch, Router, and Service Boundaries

Scenario: Someone Added a Router

An office reports intermittent access after an employee plugged in a spare home router to 'add ports and better Wi-Fi.' Some users get 192.168.0.x, others get 10.10.5.x, and a few reach the Internet but cannot see the office printer. This is a role-boundary problem: the added device may simultaneously act as switch, router, AP, DHCP server, DNS forwarder, firewall, and NAT gateway.

Step 1: Know the Approved Design

The office firewall is the router and default gateway 10.10.5.1. The access switch provides Layer 2. The approved AP bridges employee Wi-Fi into the employee VLAN with a separated guest SSID. DHCP comes from the firewall. So employee clients should show 10.10.5.x, gateway 10.10.5.1, approved DNS. Any 192.168.0.x address is a flag that a second DHCP server or private network exists.

Step 2: Map Symptoms to Roles

Step 3: Inspect How the Box Is Wired

If the home router's WAN port connects to the office LAN and users sit behind its LAN ports/Wi-Fi, those users are behind a second NAT boundary. They reach the Internet because the box translates their private addresses, but they cannot reach office printers or shares, because they are on a different subnet (192.168.0.x) and the box's NAT and stateful firewall block unsolicited inbound traffic from the office side. This is double NAT: two translation layers stacked, which also breaks port forwarding, some VPNs, and any service that expects inbound connections.

The give-away is users who can browse the web fine yet cannot see a printer that sits one cable away.

If the home router's LAN side connects to the office LAN while its DHCP server stays active, it leases wrong addresses to random office clients. DHCP Discover messages are broadcasts, and the client accepts the first Offer it receives, so whichever server replies fastest wins. Results are intermittent because the winner varies per client and per boot - the classic rogue-DHCP race. The fix is to disable the consumer box's DHCP server, or remove it, so only the authorized firewall answers.

Step 4: Act Within Authority

Unauthorized consumer gear is a valid escalation item, but consider business impact before unplugging - the device may be the only path for several users at that moment, and pulling it could create a bigger outage than the one you are fixing. Document the device model, where it is patched, which SSID it broadcasts, whether its DHCP appears active, and example IP settings from affected and unaffected clients. If local policy permits removing unauthorized devices, follow it and retest; otherwise escalate to the network owner with evidence.

Never reconfigure someone's personal router on the office network on your own authority; that mixes ownership and access boundaries.

The Core Lesson

Device labels mislead. A 'router' often contains a switch and AP. A firewall may also do routing, NAT, DHCP, and DNS forwarding. An AP may bridge into a VLAN or route into a separate network depending on mode (bridge vs router/NAT mode). Use the diagram, port labels, IP settings, and symptoms to determine the active role before touching cables.

Service Roles Inside One Box

The reason small networks confuse technicians is that a single physical device usually plays many logical roles at once. A typical office firewall is simultaneously the router (it forwards between subnets), the NAT gateway (it translates private addresses to one public address), the DHCP server (it leases addresses), and a DNS forwarder (it relays name queries upstream). When that one box has a problem, the symptom you see depends on which role is affected.

A NAT or routing fault breaks Internet access while local switching still works; a DHCP fault breaks new leases; a DNS-forwarder fault breaks name resolution while raw IP connectivity survives. Naming the role, not the box, is what lets you predict and isolate the symptom.

The same logic applies in reverse to the rogue home router, which collapses all of those roles into one uncontrolled device dropped into the middle of the network. Because it answers DHCP, hands out a gateway, NATs, and forwards DNS, it can produce almost any symptom in this chapter depending on how it is wired. That is precisely why the fix is to identify and remove or neutralize the unauthorized role rather than to chase each downstream symptom separately. Map the roles, find the box performing one it should not, and the scattered complaints usually collapse to a single cause.

Common Traps

• Assuming a box does only what its label says.
• Missing rogue DHCP because the symptom is intermittent.
• Yanking unauthorized gear without considering who depends on it.
• Chasing each symptom separately instead of naming the rogue role.