A handful of users at a secondary office have been reporting intermittent slowness in Outlook and other work applications for several weeks. The main office has no similar complaints. The remote users are connected through a site-to-site VPN, and the ISP says the modem and circuit tests are normal. Speed tests also look good. The firewall at the remote location was recently replaced, but the issue continues. The only time I have been able to reproduce the problem was during a Teams call with one of the affected users. The users connect through a switch and firewall at the remote site. How would you systematically investigate whether the problem is related to the VPN, network equipment, traffic patterns, or the individual applications?
4 Answers
Find out where Microsoft 365 traffic is exiting. If Teams and Outlook traffic is being routed through the VPN to the main office and then out to the internet, the extra path or security inspection could be causing trouble. Where appropriate, use local internet breakout or split tunneling for Microsoft 365 traffic, and make sure Teams media is not being subjected to problematic SSL inspection. Reviewing the affected Teams calls in the administration portal can also show packet loss, jitter, and latency.
Since the issue is limited to the remote office and was reproducible during a Teams call, I would focus on the VPN path. Check tunnel MTU and MSS clamping, since VPN encapsulation can cause fragmentation or dropped large packets while basic speed tests still look fine. Test packet sizes with ping, run iperf3 across the tunnel in both directions, and monitor latency and packet loss continuously during an incident. Also check interface errors, CPU usage, tunnel logs, and bandwidth utilization on both firewalls.
Start by defining exactly what “slow” means. Ask users to record the date and time, application, action they were performing, and what they observed. Is Outlook slow to open, sync, or send mail? Are file shares slow? Is Teams audio or video breaking up? Without that detail, replacing hardware is mostly guesswork. Look for patterns by user, computer, application, time of day, and traffic volume.
Monitor the circuit and tunnel during the actual complaints rather than relying on a one-time speed test. A remote office can test normally while users are idle but become congested when Outlook synchronizes mailboxes, shared folders, DFS data, backups, or large files. Check for scheduled jobs and simultaneous logins, and compare bandwidth usage with the timestamps from the incident log. Also test both wired paths separately if possible, verify DNS response times, and compare affected PCs for OS, driver, update, and hardware differences.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures