The Internet Is Down: A Triage Tree for a Small Office Network

The phone rings and it is everyone at once. Nobody can get online. The temptation is to reboot the firewall and hope, but that destroys the evidence and leaves you no wiser for next time. A triage tree gets you to the cause in a few minutes and tells you who to call.

The path from a desk to the internet is short: PC, switch, firewall, ISP modem, ISP. DNS sits alongside it and fails in a way that looks like everything is down. Test each stage from the inside out, and stop at the first one that fails.

Stage one: is it really everyone?

Confirm the scope before you touch anything. One user is a PC problem. One room or one floor is a switch problem. Everyone, wired and wireless, is the firewall or the ISP.

Then check whether it is internet or everything. Can users reach the file server or print? If the internal network works and only outside sites fail, the fault is at the firewall, the ISP or DNS. If nothing works, the core switch or the DHCP server is down.

From one PC: `ipconfig` and confirm it has a valid address, not 169.254.x.x. If it is 169.254, DHCP is unreachable and you are looking at a switch or the DHCP server.
Ping the default gateway, usually the firewall's inside address: `ping 192.168.1.1`. No answer means the path to the firewall is broken or the firewall is dead.
Ping a public IP: `ping 1.1.1.1`. Answer here with no answer to `ping google.com` means DNS, not the internet.

ipconfig
ping 192.168.1.1
ping 1.1.1.1
ping google.com
tracert 1.1.1.1

Stage two: DNS looks like an outage

If the public IP answers and names do not, every browser shows an error and users report the internet as down. The internet is fine. Name resolution is broken. On a domain network the resolver is a domain controller; in a small workgroup it is the firewall or the ISP's servers.

Run `nslookup google.com` and read which server answered. Then run `nslookup google.com 1.1.1.1`, which asks a public resolver directly. If that works, fix your resolver. If the firewall blocks that query, test from the firewall itself.

Domain network: check the DC is up and the DNS service is running, then test its forwarders.
Workgroup network: check the firewall's DNS settings and that the ISP's resolvers are reachable.
Look for a DNS filtering service that expired or changed keys. Filtered DNS that stops answering takes the whole office with it.

nslookup google.com
nslookup google.com 1.1.1.1
Restart-Service Dnscache

Stage three: the firewall and the ISP

If the gateway answers but nothing beyond it does, log in to the firewall. Every mainstream unit, whether SonicWall, MikroTik, Ubiquiti or a DrayTek, shows the WAN interface status on its dashboard. You want to know whether the WAN has an IP, whether the gateway beyond it answers, and whether the WAN has flapped recently in the logs.

A WAN interface with no address or a private 192.168.x.x address means the modem is not passing a public address through. Reboot the modem, wait two full minutes, and check again. A WAN with a public address and no gateway reply means the ISP is down beyond the modem. That is when you call them.

On the firewall, check the WAN interface: has an IP, link is up, gateway pings.
Check the firewall logs for the last few minutes. Look for WAN down, DHCP renewal failures, or a failover event if there is a second WAN.
Power-cycle the ISP modem or ONT. A red or blinking internet or PON light after two minutes is an ISP problem.
Call the ISP with the account number, the WAN IP, the modem model and the failure time. Ask them to test the line from their side.

# MikroTik: check WAN and route
/interface print
/ip route print
/ping 1.1.1.1 count=4

Stage four: the switch, and what to fix afterwards

When the gateway does not answer from a PC, walk the wiring closet. A switch that has lost power, or a loop caused by someone plugging both ends of a cable into the wall, will take the whole floor down. Look at the link lights. All ports blinking in unison at high speed is the signature of a broadcast storm from a loop. Unplug uplinks one at a time until it stops.

After the office is back online, spend fifteen minutes on prevention. A one-page map of what plugs into what, taped inside the wiring closet door, is worth more than anything else during the next outage. RackLedge builds these runbooks for the sites it manages.

Put the firewall, modem and core switch on a UPS. A brief power blip that leaves a modem hung is the most common cause of all.
Enable loop protection or STP on managed switches so a patch cable mistake does not take the office down.
Monitor the WAN gateway and the DNS resolver from inside the network so you get a head start on the next call.
Test the backup WAN failover on a quiet afternoon, not during an outage.

Frequently asked questions

Should I just reboot the firewall first?

Only after you have checked the WAN status and saved the logs. A reboot fixes a hung unit but erases the evidence, and if the ISP is the cause you have wasted five minutes of downtime.

How do I tell the ISP from the modem?

If the firewall's WAN has no public address after a modem reboot, or the modem's internet light is red, the fault is at or beyond the modem. If the WAN has a public address and the gateway does not respond, it is the ISP's network.

Takeaway

Work the path in order: scope, address, gateway, public IP, DNS, firewall WAN, ISP. Each step is one command or one screen, and the first failure tells you who owns the fix. Save the logs before rebooting anything, then put the core gear on a UPS and monitor the WAN so the next outage is a page to you instead of a call from everyone.