Start here: a quick sanity checklist
If your WAN connection is acting up, run a short checklist before deep troubleshooting. That saves time and avoids chasing the wrong problem.
- Confirm the outage affects more than one device or application.
- Check physical status lights on routers, modems and switches.
- Look for recent config changes or firmware upgrades on edge devices.
- Check your monitoring/alerts for correlated events (CPU, interface errors, bandwidth spikes).
- Note the time window and affected destinations (single site, cloud service, or global).
Common WAN issues and how to fix them
1) High latency
Why it happens: Long paths, overloaded links, or ISP routing can add delay. WAN links to distant regions naturally have higher RTT, but unexpected spikes indicate trouble.
How to diagnose:
- Run ping and traceroute to the destination. Compare results from inside and outside the network.
- Use MTR (linux) or pathping (Windows) to see where latency increases along the path.
- Check interface utilization and queue drops on routers and WAN links.
Fixes:
- Reduce link congestion: increase bandwidth, move traffic to off-peak hours, or re-balance across links.
- Work with your ISP to improve routing or provision a direct path to the target network.
- Apply QoS to prioritize time-sensitive traffic like VoIP and video.
- Consider SD-WAN for dynamic path steering to lower-latency routes.
2) Packet loss
Why it happens: Physical errors, overloaded devices, buffer drops, or routing problems can cause packets to be dropped.
How to diagnose:
- Use ping with a large number of packets: ping -c 100 <host> to see loss percentage.
- Run MTR to pinpoint the hop where loss begins.
- Check interface error counters (CRC, frame errors, drops) on routers and switches.
Fixes:
- Replace faulty cables, SFPs or transceivers. Verify correct SFP types and optics power levels.
- Fix duplex/MTU mismatches and incorrect speed negotiation.
- Increase buffering or reduce bursty traffic. Implement QoS to protect critical flows.
- If loss is on ISP side, open a ticket with test data (traceroutes, packet loss graphs).
3) Jitter affecting VoIP or video
Why it happens: Variable delay caused by queuing, congestion, or asymmetric routing.
How to diagnose:
- Monitor jitter metrics from your SBC, PBX, or VoIP clients.
- Look for correlated spikes in interface utilization or CPU on routers.
Fixes:
- Apply strict QoS to prioritize voice packets and allocate minimum bandwidth.
- Reduce queuing delays by tuning buffers or using low-latency queuing (LLQ).
- Use dedicated links or circuits for voice when possible.
4) Intermittent connectivity / link flapping
Why it happens: Physical port problems, flaky SFPs, intermittent ISP issues, or software bugs can cause links to go up and down.
How to diagnose:
- Check syslogs for link up/down messages with timestamps.
- inspect interface counters for errors that coincide with flaps.
- Swap ports, cables, or transceivers temporarily to isolate the component.
Fixes:
- Replace failing hardware (cable/SFP/port) and ensure clean power to devices.
- Update firmware or apply vendor bug fixes if a known issue exists.
- Configure interface dampening if appropriate to avoid routing churn.
5) Routing problems and BGP issues
Why it happens: Misconfigured routes, flapping neighbors, incorrect AS paths, or prefix filtering can cause reachability issues.
How to diagnose:
- Check routing tables and BGP/OSPF neighbor states (show ip route, show bgp summary).
- Look for route changes during the problem window and check BGP update logs.
- Use route analytics or Looking Glass tools for external viewpoints.
Fixes:
- Correct route filters, prefix-lists and next-hop configurations.
- Stabilize BGP by tuning timers or using BFD for fast detection paired with careful dampening settings.
- Coordinate with upstream ISPs for proper announcements and de-aggregation issues.
6) MTU and fragmentation issues
Why it happens: Mismatched MTUs between devices can cause tcp stalls, web PAGE LOAD failures, and VPN issues.
How to diagnose:
- Use ping with the don’t-fragment flag: ping -M do -s
<host> to find the largest workable packet size. - Check VPN and tunnel overhead (IPsec, GRE) which reduce effective MTU.
Fixes:
- Set proper MTU on interfaces and adjust MSS clamping on the firewall/router for TCP flows.
- Reduce MTU on endpoints behind tunnels or enable path MTU discovery if supported.
7) VPN tunnel problems
Why it happens: Misconfigured phase1/phase2 settings, expired certificates, or NAT traversal issues.
How to diagnose:
- Check VPN logs for phase negotiation errors and rekey failures.
- Verify cryptographic parameters and authentication credentials are current.
Fixes:
- Correct phase settings, update certs, and ensure NAT-T is enabled if NAT devices sit between peers.
- If using dynamic IPs, use dynamic DNS or reconfigure peer endpoints.
- Consider redundant tunnels with failover and health checks.
8) dns resolution failures
Why it happens: dns caching issues, misconfigured resolvers, or upstream DNS outages can make services unreachable even if the WAN link is OK.
How to diagnose:
- Use dig or nslookup to query authoritative DNS and recursive resolvers.
- Compare responses from public DNS (8.8.8.8) and your local resolvers.
Fixes:
- Fix resolver configuration and ensure forwarders are reachable.
- Clear caches where appropriate and plan TTLs to reduce impact of changes.
- Implement redundant DNS providers and monitoring.
9) Firewall or NAT blocking traffic
Why it happens: Overly strict rules, stale state tables, or asymmetric paths can block legitimate flows.
How to diagnose:
- Check firewall logs for dropped traffic correlated to the problem time.
- Use packet capture (tcpdump) at the firewall to see if traffic is received and forwarded.
Fixes:
- Tweak rules to allow required ports and correct NAT translations.
- Increase state table sizes or tune timeouts to prevent premature state removal.
- Document and test firewall changes in a staging environment when possible.
10) Hardware resources and CPU overload
Why it happens: Routers or firewalls hitting CPU or memory limits can drop packets, slow routing updates, or delay encryption.
How to diagnose:
- Monitor CPU, memory, and process lists on network devices.
- Look for spikes that align with issues and check which process is consuming resources.
Fixes:
- Move CPU-heavy features (like inspection or logging) off critical path or upgrade hardware.
- Offload crypto to hardware if supported, or distribute load across devices.
- Tune logging levels and remove unnecessary features that consume resources.
Tools to keep in your troubleshooting toolbox
- ping, traceroute, MTR , basic reachability and path analysis
- iperf3 , bandwidth testing
- tcpdump or Wireshark , packet-level diagnosis
- SNMP and monitoring systems , historical trends for bandwidth, errors, and latency
- Router logs, interface counters, and vendor diagnostic commands
When to call your ISP or vendor
Open a support ticket when you have clear evidence that the problem is outside your network, such as:
- Repeated traceroutes that stop within the ISP network
- Link errors on the ISP-facing interface with no local hardware faults
- Service degradation across multiple customer sites supplied by the same ISP
Provide the ISP with timestamps, traceroutes, packet loss graphs and any syslog messages. That speeds up resolution.
Best practices to reduce future WAN problems
- Implement redundant paths and automated failover (BGP, VRRP, SD-WAN).
- Use monitoring and alerting that measures latency, jitter, and packet loss over time.
- Apply QoS for critical applications and test regularly under load.
- Document network designs, change windows and rollback plans for all WAN changes.
Summary
WAN problems usually show predictable symptoms: latency, loss, jitter, intermittent links, routing errors, or DNS/VPN failures. Start with simple checks, gather evidence with pings, traceroutes and interface counters, then isolate whether the issue is physical, local configuration, or with the ISP. Fixes range from replacing bad hardware and tuning MTU/MSS to applying QoS, adjusting routing policies, or engaging the service provider with concrete diagnostics. With good monitoring, redundancy and clear procedures, most WAN problems become easier to identify and resolve.
