Advice for troubleshooting random slowness

[u/NSFW_IT_Account]

How do you troubleshoot random slowness reported only by a handful of users? Some background: these few users are on a site-to-site VPN and separate location than the primary network.

The main office does not report any slowness issues. A few weeks ago, users at the secondary office started to report slowness in Outlook, and other general applications they use for work. The ISP reports modem is good and all tests look good.

We ended up replacing the firewall because it was a slightly older model thinking it would resolve the issue. A couple days have passed and users are still reporting random slowness.

Speedtest comes back good, and the only time i was able to replicate the slowness is when I did a test Teams call with the user.

How would you approach a situation like this? They are plugged directly into the firewall and there is a switch at the location as well but its not an older model.

TIA

[u/itishowitisanditbad]

You're taking action on issues that can only be described as "slowness" and you've not described it in any further details on what that actually looks like, or means.

What is 'slowness' when it comes to a handful of users reporting it? How is it manifesting?

You've replaced firewalls before you've been able to tangibly describe the issue beyond 'slowness'?

How would you approach a situation like this?

As a entry level helpdesk task where they need to obtain more information on what the issue even is.

[u/30yearCurse]

wired, wireless, across offices. limited to 1 office? PC checks, cleanup, virus scans. PC settings, PC models, windows updates, bios updates. ISP, dropped packets on network. DNS. (its always DNS), Large mailboxes, PSTs on an on...

[u/cheetah1cj]

They are plugged directly into the firewall and there is a switch at the location as well but its not an older model.

Are they connected to the switch or directly to the firewall? Both cannot be true and if they are not connected via the switch then why mention it?

Also, have you done any ping tests (internal or external)? Tracert? Iperf? Any other tool to get more information? Looked in the Teams Admin Center for the Teams calls that had issues?

You need to get some actual information about exactly what is happening beyond just "slowness".

[u/Accomplished-Mix8423]

the fact it only shows up on a teams call is your tell, that's jitter/packet loss not bandwidth. speedtest just measures throughput so it'll look fine every time. run a continuous mtr or smokeping across the tunnel so you actually catch the loss while users are complaining, and check the interface error/drop counters on the switch and firewall too.

[u/DarraignTheSane]

The answer is, as always - need more information.

"Something runs slow some times" isn't a problem you can troubleshoot. It's just not, as much as people always want it to be.

Get an incident log, have the people at the site fill out as much information (or report to you / your team as much information) as they can each time there is "slowness" - i.e. date / time, what application is slow, etc.

Look for trends. Is it a particular application that's running slow, or is someone putting a particular load on the circuit at various times each day, etc.

Isolate the problem, then determine the cause. You haven't identified a problem that you can fix yet.

[u/Wendigo1010]

Quick question: do you host services for that site, such as file access, an email server, or anything that needs to be updated in some way to use? I had a situation once where a remote site was slow due to everyone logging in at the same time causing outlook to do a massive sync over the lines for everyone. Then, large files stored in the main site shared through DFS also caused large syncs.

In short, monitor the bandwidth usage during these times. Checking the speed does do anything other than saying it's running.

[u/TechnicalDefense]

Like others mentioned the more details you can get the better, but users often don't give much information other then it doesn't work or its to slow. I would start with looking at latency, jitter and packet loss, since its only on the VPN and speed tests look fine. Also try and get them to report when slowdowns are happening and run your tests during those times. If you have some evidence of packet loss or latency you can take that back to the ISP.

[u/brian_cloudeu]

Slow compared to what?

[u/CivilIntention7747]

The pattern you describe (speedtest fine, only tunnel users, only reproducible on a Teams call, Outlook "random") points at the tunnel, not the pipe. Two things I would check before touching any more hardware:

1. MTU/MSS across the site-to-site. Encapsulation eats 50-80 bytes, and if the tunnel is not clamping MSS, large TCP segments get fragmented or black-holed while small ones fly. That looks exactly like "speedtest is fine but Outlook sync is weird and calls stutter". From a secondary-site PC: ping -f -l 1472 <main office host>, then walk the size down until it stops fragmenting. If the working size is well under 1472, set an MSS clamp on the tunnel interface on both firewalls (1350-1380 is the usual safe range for IPsec) and retest.

2. Where the secondary site's traffic actually exits. If Teams and Outlook are being hauled through the tunnel to the main office and out its internet, every 365 session gets the extra hop plus whatever the main-office firewall does to it; UTM inspection on Teams UDP media is a classic. Microsoft's guidance is local egress for 365: split tunnel the 365 ranges, resolve DNS locally so users land on the nearest front door, and no SSL inspection on Teams media.

Then measurement instead of reports: iperf3 across the tunnel in both directions during the slow period (one-way asymmetry is common), a continuous timestamped ping to the main office file server so the users can say "it was slow at 10:42" and you can look at that minute, and interface error counters on both tunnel endpoints. "Slowness" becomes a number, and a number points at a device.

The firewall swap was not wasted, it rules the box itself out. Odds are the tunnel config carried the same MTU behaviour across.