ADAM PULSE Knowledge Base
Network Operations · Outages · Carrier Escalation

Is it the ISP or the firewall? How to find the real cause of an internet outage

By Michael Obraitis, Managing Partner, and Michael Dale, CEO·Published August 12, 2026·Last reviewed August 2026·ADAM Pulse Knowledge Base

"The internet is down."

Those four words can start an expensive troubleshooting process.

But an internet outage does not necessarily mean the Internet Service Provider is down.

The problem could be the ISP circuit, modem or ONT, firewall, router, SD WAN appliance, DNS service, VPN, switch, local network, WiFi environment, cabling, or even the application users are trying to reach.

The real question is:

Where does the failure actually begin?

This guide explains how IT teams can systematically determine whether an internet outage is being caused by the ISP, firewall, gateway, or internal network and how continuous network monitoring can provide the historical evidence needed to resolve intermittent problems faster.

How Do You Tell if the ISP or Firewall Is Causing an Internet Outage?

The fastest approach is to divide the connection into logical test points and determine where connectivity stops.

Think of the network path as:

User → LAN → Firewall → ISP Gateway → Internet → Application

Then test each layer independently.

If the local network and firewall remain reachable but connectivity fails beyond the ISP handoff, the carrier circuit or upstream network becomes a stronger suspect.

If the ISP connection remains available but traffic cannot successfully pass through the firewall, investigate the firewall configuration, interfaces, resources, policies, routing, NAT, VPN, and SD WAN behavior.

The objective is to replace:

"We think the ISP is down."

with:

"Here is exactly where the failure begins."

What Should You Check First When the Internet Goes Down?

Before rebooting anything, determine the scope of the problem.

Ask:

  1. Is one user affected?
  2. Are multiple users affected?
  3. Is the entire location affected?
  4. Are wired and wireless users affected?
  5. Is one application failing or everything?
  6. Can users reach local resources?
  7. Can the local gateway be reached?
  8. Can the firewall be reached?
  9. Can an external IP address be reached?
  10. Does DNS resolution work?
  11. Are other company locations experiencing the same problem?

These answers immediately narrow the investigation.

If one laptop cannot connect but everyone else can, calling the ISP probably isn't the best first step.

If every device at a location simultaneously loses external connectivity, the investigation changes considerably.

Step 1: Can You Reach the Local Gateway?

Start inside the network.

Test connectivity to the local gateway.

If the gateway cannot be reached, investigate the local environment before blaming the ISP.

Possible causes include:

If the gateway responds normally, move outward.

Step 2: Can You Reach the Firewall?

Determine whether the firewall is operational and reachable from the appropriate management or network location.

Check:

A firewall can remain powered on while still experiencing a WAN, routing, policy, resource, or interface problem.

Therefore:

Firewall reachable does not automatically mean firewall healthy.

Step 3: Is the Firewall WAN Interface Up?

Next, examine the WAN side of the firewall.

Verify:

If the firewall has lost its WAN address or gateway connectivity, determine why.

The problem may involve the firewall configuration, modem or ONT, physical connection, or ISP.

Step 4: Can You Reach the ISP Gateway?

This is an extremely important test.

If:

LAN → Firewall works

but:

Firewall → ISP Gateway fails

the fault has been narrowed significantly.

Investigate:

This does not automatically prove that the ISP is responsible, but it gives the troubleshooting team a much smaller area to investigate.

Step 5: Can You Reach an External IP Address?

Test a known external IP address.

This helps separate basic internet connectivity from DNS.

If an external IP responds but hostnames do not resolve, DNS becomes a much stronger suspect.

If neither works, continue investigating connectivity and routing.

Step 6: Is DNS Actually the Problem?

DNS failures frequently look like internet outages.

A user may say:

"The internet isn't working."

when the network is perfectly capable of reaching external IP addresses.

What is actually failing is hostname resolution.

Test:

If IP connectivity succeeds while hostname resolution fails, investigate DNS before changing unrelated network equipment.

Step 7: Run Ping Tests

Ping helps determine whether a destination can be reached and provides round trip response information.

Useful targets can include:

Test A: Local gateway

Test B: Firewall

Test C: ISP gateway

Test D: External internet destination

Compare the results.

For example:

| Test | Result | Initial Interpretation | | —- | —- | —- | | Local gateway | Healthy | LAN likely operational | | Firewall | Healthy | Firewall reachable | | ISP gateway | Packet loss | WAN or provider path needs investigation | | Internet destination | Packet loss | Upstream degradation likely | | DNS lookup | Healthy | DNS less likely |

Do not rely on one or two packets.

Intermittent problems require measurements over time.

Step 8: Run Traceroute

Ping answers:

Can I reach it?

Traceroute helps answer:

What path am I taking to get there?

Traceroute can help identify where traffic travels and where a path appears to change or stop.

However, traceroute must be interpreted carefully.

Asterisks at an intermediate hop do not automatically mean that router is broken.

Network devices may deprioritize or refuse diagnostic traffic while continuing to forward production traffic.

Always examine what happens after the questionable hop and at the destination.

Step 9: Measure Packet Loss

Packet loss can cause:

Test packet loss at multiple points.

For example:

Gateway: 0%

Firewall: 0%

ISP Gateway: 0%

Internet Destination: 8%

That pattern is much more useful than simply saying:

"Internet performance is bad."

It provides evidence about where degradation may be occurring.

Step 10: Measure Latency

Latency measures how long network traffic takes to travel between points.

If normal latency for a location is 20 milliseconds and it suddenly increases to 180 milliseconds, users may experience poor application performance even though the circuit remains online.

Look for:

Historical baselines make these changes much easier to identify.

Step 11: Measure Jitter

Jitter measures variation in packet delivery timing.

This is particularly important for:

A connection can be technically "up" while still providing a terrible user experience.

That is why:

Uptime does not equal network quality.

Step 12: Check the Firewall Logs

If the ISP connection appears healthy but applications remain unavailable, inspect the firewall.

Look for:

A firewall policy can create an application failure even when basic internet connectivity remains available.

How Can You Prove the ISP Is Causing the Problem?

This is where troubleshooting becomes much more interesting.

A carrier support representative may say:

"The circuit is currently online."

That statement does not prove the circuit was healthy 30 minutes ago.

Intermittent carrier problems may include:

By the time someone calls support, the condition may have disappeared.

The best defense is historical evidence.

Collect:

Instead of telling the carrier:

"Our internet keeps going down."

you can say:

"The local gateway and firewall remained available, but external connectivity experienced repeated loss between 2:14 PM and 2:27 PM. Similar events occurred yesterday at 3:06 PM and Monday at 1:52 PM."

Now you have a troubleshooting case instead of an opinion.

How Can You Prove the Firewall Is Causing the Problem?

Use the same evidence based approach.

Look for situations where:

The objective is not to blame the firewall.

It is to determine whether the evidence points toward the firewall.

Should You Reboot the Firewall When the Internet Goes Down?

Not immediately unless circumstances require it.

Rebooting can restore service, but it may also destroy valuable evidence.

Before rebooting, when practical:

  1. Record the exact time.
  2. Check firewall availability.
  3. Check WAN status.
  4. Test the gateway.
  5. Test external connectivity.
  6. Check DNS.
  7. Record latency and packet loss.
  8. Review logs.
  9. Preserve diagnostic information.

Then make an informed decision.

A reboot that fixes the problem without identifying its cause may simply guarantee that the same problem returns later.

Why Does the ISP Say Everything Looks Fine?

Because it may look fine now.

This is one of the biggest challenges with intermittent network troubleshooting.

Imagine this sequence:

2:04 PM: Packet loss begins.

2:07 PM: Users complain.

2:12 PM: IT receives the ticket.

2:18 PM: IT begins testing.

2:23 PM: Network returns to normal.

2:35 PM: Carrier support begins testing.

The carrier sees a healthy circuit.

The users experienced a real problem.

Both observations can be correct.

The missing piece is:

What happened between 2:04 and 2:23?

Continuous network monitoring provides that historical context.

Why Isn't a Speed Test Enough?

A speed test answers an important question:

How much data can this connection transfer under the current test conditions?

It does not completely answer:

Is this network healthy?

A connection can show excellent download speed while experiencing:

Therefore:

Bandwidth is one measurement of network performance, not a complete diagnosis.

Why Isn't Ping Enough?

Ping is extremely useful.

But ping is a diagnostic test, not a complete network monitoring strategy.

A successful ping at 3:15 PM does not tell you what happened at 2:47 PM.

A five packet test does not necessarily expose a disruption that occurs every few hours.

This is why continuous historical monitoring becomes so valuable.

Why Isn't Traceroute Enough?

Traceroute provides valuable path information.

But it represents the network path at the time the test is performed.

Routes can change.

Latency can change.

Carrier conditions can change.

An intermittent problem may disappear before a technician runs traceroute.

The most useful approach combines diagnostic tools with historical monitoring.

How Do You Troubleshoot Intermittent Internet Outages?

Intermittent outages are among the most difficult network problems because the evidence often disappears.

Continuous monitoring should record network conditions before, during, and after the incident.

Useful measurements include:

The objective is to create a timeline.

Once a pattern exists, troubleshooting becomes dramatically easier.

ISP or Firewall Troubleshooting Checklist

Determine Scope

Test the LAN

Test the Firewall

Test the Carrier Connection

Test Services

Preserve Evidence

What Does ADAM Pulse Do Differently?

Traditional troubleshooting frequently starts after someone reports a problem.

ADAM Pulse is designed to create visibility before, during, and after network incidents.

Our approach begins with a simple question:

Where Is the Problem?

ADAM Pulse helps organizations monitor distributed locations and distinguish between conditions involving:

The carrier

The firewall

The gateway

The circuit

The local network

Instead of waiting for someone at a branch office to report:

"The internet seems slow."

IT teams can work from historical evidence showing when network behavior changed and what was happening around the time of the incident.

From Outage Alert to Actionable Evidence

An alert saying:

SITE DOWN

is useful.

But the next questions are more important:

What is down?

When did it start?

Is the firewall responding?

Is the gateway responding?

Is the carrier circuit responding?

Is latency increasing?

Is packet loss occurring?

Is this a recurring problem?

Who should receive the escalation?

Those answers can dramatically reduce troubleshooting time.

Stop Arguing About Whether It's the ISP or the Firewall

When connectivity problems occur, IT teams, firewall providers, and carriers can spend valuable time determining who owns the problem.

Data changes that conversation.

ADAM Pulse provides managed network monitoring designed to give organizations greater visibility into their locations, circuits, gateways, and network performance.

With historical monitoring, latency and SLA analytics, gateway first diagnostics, predictive alerting, and 24/7 visibility, ADAM Pulse helps IT teams move from:

"We think it's the carrier."

to:

"Here is what the network was doing when the incident occurred."

See What Your Network Is Actually Doing

If your organization manages multiple locations, internet circuits, firewalls, SD WAN connections, VoIP services, or cloud applications, ADAM Pulse can help you identify network problems faster and escalate them with better evidence.

Stop troubleshooting blind.

Start troubleshooting with data.

Learn more about ADAM Pulse and talk with USA Telecom about monitoring your network.

Frequently asked questions

How Do You Tell if the ISP or Firewall Is Causing an Internet Outage?

The fastest approach is to divide the connection into logical test points and determine where connectivity stops. Think of the network path as: Then test each layer independently.

What Should You Check First When the Internet Goes Down?

Before rebooting anything, determine the scope of the problem. Ask: 1. Is one user affected?

Step 1: Can You Reach the Local Gateway?

Start inside the network. Test connectivity to the local gateway. If the gateway cannot be reached, investigate the local environment before blaming the ISP.

Step 2: Can You Reach the Firewall?

Determine whether the firewall is operational and reachable from the appropriate management or network location. Check: A firewall can remain powered on while still experiencing a WAN, routing, policy, resource, or interface problem.

Step 3: Is the Firewall WAN Interface Up?

Next, examine the WAN side of the firewall. Verify: If the firewall has lost its WAN address or gateway connectivity, determine why.

Step 5: Can You Reach an External IP Address?

Test a known external IP address. This helps separate basic internet connectivity from DNS. If an external IP responds but hostnames do not resolve, DNS becomes a much stronger suspect.

Step 6: Is DNS Actually the Problem?

DNS failures frequently look like internet outages. A user may say: when the network is perfectly capable of reaching external IP addresses.

How Can You Prove the ISP Is Causing the Problem?

This is where troubleshooting becomes much more interesting. A carrier support representative may say: That statement does not prove the circuit was healthy 30 minutes ago.

How Can You Prove the Firewall Is Causing the Problem?

Use the same evidence based approach. Look for situations where: The objective is not to blame the firewall.

Should You Reboot the Firewall When the Internet Goes Down?

Not immediately unless circumstances require it. Rebooting can restore service, but it may also destroy valuable evidence. Before rebooting, when practical:

Sources

Editorial note

Network symptoms should be interpreted in context. A single test from a single location at a single moment rarely proves where a fault sits — correlate against history, test from more than one point, and preserve evidence before changing configuration.

Talk to us about your network security

USA Telecom Consulting LLC is a Service-Disabled Veteran-Owned Small Business running a 24/7 NOC. We monitor networks, circuits and firewalls for regulated and defense-supply-chain organizations.

Related articles

Why is my network slow even though the speed test is fast? · Latency vs jitter vs packet loss · Ping vs traceroute vs MTR · How to troubleshoot packet loss · How to prove your ISP is the cause · What is network fault isolation? · o · o · i · i

← More from the ADAM Pulse Knowledge Base

Prepared by ADAM Pulse (USA Telecom Consulting LLC) — managed AI governance, network, and NOC services. Support: (888) 989-4872 · support@adampulse.us