LAN or WAN? Telling Outages Apart in Two Minutes

Few phone calls create panic faster than "The network is down." In a manufacturing plant, that sentence can mean production lines waiting. At an internet service provider, it can mean dozens of customers calling at once.

I've taken those calls in both environments: as a Network Support Engineer at an ISP and as an IT Support Specialist at a plant with more than 1,200 users. Over time, I learned that the most valuable first step isn't fixing anything. It's working out where the problem is.

Is it inside the local network, the LAN? Or is it outside, in the wide area network, the WAN, which includes the internet connection, links to other sites and cloud services? The answer decides who needs to act, what to check next and what to tell users. And with a simple routine, you can usually work it out in about two minutes.

A quick definition

• LAN (local area network): everything inside your site. Computers, Wi-Fi access points, switches, local servers, printers and the internal side of your router or firewall.
• WAN (wide area network): everything that connects your site to the outside world. Your internet service, links between branches, connections to data centres and cloud services, and the provider's network beyond your building.

The boundary is usually the edge device: the router or firewall where your internet connection or site links terminate.

Minute one: ask three questions

Before running any command, ask a few questions. The answers often point straight at the problem.

1. Who is affected?

• One user? It's almost certainly local to that device, cable, port or account.
• One area, floor or department? Look at the switch, access point or network segment serving that area.
• Everyone at the site? It could be a core switch, the firewall, DNS, DHCP or the internet connection.
• Multiple sites? Look at shared WAN links, the provider, a central data centre or a cloud service.

2. What exactly isn't working?

• Everything, including local resources like printers and file shares? That points to the LAN.
• Only internet and cloud services, while local resources work? That points to the WAN or internet edge.
• Only one application? It may be the application or its provider, not the network at all.

3. What changed?

New equipment, configuration changes, power cuts, construction work, provider maintenance windows or recent updates. A surprising number of outages follow a change that happened shortly before.

Minute two: test from the inside out

Now confirm with a few quick tests from an affected device. I move outward, one layer at a time.

Step 1: Does the device have a valid address?

Run ipconfig on Windows or ip addr on Linux and macOS. If the device has an address starting with 169.254 on Windows, it couldn't get one from DHCP. That's a LAN problem: the cable, Wi-Fi, switch port, VLAN or the DHCP server itself.

Step 2: Can it reach the default gateway?

Ping the gateway address shown in the network settings. If the gateway doesn't respond, the problem is between the device and the edge of the network. That's LAN territory.

Step 3: Can it reach something local beyond the gateway?

Ping an internal server, such as a file server or domain controller. Success means the internal network is working.

Step 4: Can it reach the internet by IP address?

Ping a well-known public IP, such as 1.1.1.1 or 8.8.8.8. If internal resources work but this fails, the problem is likely at the internet edge or with the provider: WAN territory.

Step 5: Can it reach the internet by name?

Ping a website by name, or use nslookup. If IP addresses work but names fail, the issue is DNS, which can sit on either side depending on where your DNS servers are.

Step 6: Where does the path stop?

Run tracert on Windows or traceroute on Linux and macOS to a public address. If the trace stops at your own firewall, the problem is at the edge. If it passes your firewall and stops in the provider's network, it's on their side.

Reading the results

Put together, the results usually tell a clear story:

• No address, no gateway: local LAN problem. Check the physical connection, Wi-Fi, switch port, VLAN and DHCP.
• Gateway works, internal servers work, internet fails: WAN or internet edge. Check the firewall, the router's WAN interface and the provider's status.
• Internet works by IP but not by name: DNS. Check your DNS servers and forwarders.
• Everything works except one application: likely the application or its hosting provider. Check its status page.
• Some areas fine, others not: look at what's shared by the affected areas, such as a particular switch, access point, VLAN or uplink.

A worked example

Here's how the routine plays out in a typical scenario.

At 8:05 a.m., three calls arrive within minutes: email isn't loading, a cloud-based ordering system won't open and "the internet is down." Meanwhile, nobody has complained about printing or the internal file server.

Minute one. Many users across the whole site are affected, but only for internet and cloud services. Local resources are working. Nothing changed internally overnight. That already points away from the LAN.

Minute two. From an affected laptop: valid IP address, gateway responds, the internal file server responds. Pinging 1.1.1.1 fails. Traceroute stops right after the firewall.

Conclusion. The LAN is healthy. The problem sits at the internet edge or with the provider. A quick look at the firewall shows the WAN interface is up but has no connectivity to the provider's gateway. The provider's equipment shows a warning light.

The team calls the provider with the circuit ID, the time the problem started and the traceroute results. Users are told that internet services are down, internal systems are working and an update will follow in thirty minutes. Total time to diagnosis: a few minutes.

Look at the equipment too

Device lights and dashboards add useful evidence:

• Switch port lights. No link light on a user's port suggests a cable or device problem. All ports dark on a switch suggests power or hardware failure.
• Router and firewall status. Is the WAN interface up? Does the device have a public address? Are there errors in its logs?
• Provider equipment. Modems and network termination units often have status lights that indicate whether the provider's signal is present.
• Monitoring tools. If you have network monitoring, it can show at a glance which devices or links are down. At both the ISP and the plant, monitoring was often the first place I looked.

Why the distinction matters

Telling LAN from WAN quickly matters for three reasons.

It gets the right people moving. A LAN problem means your own team needs to act. A WAN problem often means calling the provider. Every minute spent troubleshooting the wrong side delays the fix.

It gives you evidence for the provider. Providers respond faster to a clear report: "Our firewall's WAN interface is up, we can't reach the provider's gateway, and traceroute stops at your first hop. The problem started at 8:14." That's much harder to dismiss than "The internet is down."

It sets realistic expectations for users. A local problem might be fixed in minutes. A provider outage might take hours. Telling users which one it is, along with a workaround if there is one, reduces frustration and repeat calls.

Prepare before the next outage

The two-minute routine works best when you've done some homework:

• Keep an up-to-date network diagram showing your sites, key switches, firewalls and WAN links.
• Know your provider details: circuit IDs, account numbers and support phone numbers, stored somewhere available when the network is down.
• Have a backup connection for critical sites if the business depends on internet access, such as a secondary provider or a cellular failover link.
• Set up basic monitoring for key devices and links, so you know about outages before users call.
• Write the routine down so anyone on the team can follow it under pressure.

The security angle

Outages aren't always accidents. A sudden loss of connectivity can be caused by a misconfiguration, but it can also result from a denial-of-service attack, a compromised network device or someone tampering with equipment. Unexpected configuration changes, unfamiliar devices on the network or unusual traffic before an outage are all worth investigating, not just fixing.

Good troubleshooting habits, such as checking what changed and recording evidence, serve both purposes.

The takeaway

When the network goes down, the fastest way to fix it is to find it. Ask who's affected, what doesn't work and what changed. Then test from the device outward: address, gateway, internal servers, internet by IP, internet by name and the path beyond. In about two minutes, you'll usually know whether the problem is inside the building or beyond it, and exactly who needs to act.

What's the strangest cause of a network outage you've ever tracked down?