Is routing our VPN through head office really the problem?

Measure the path before buying a new network. Compare the same application through the office VPN and through a controlled path that bypasses it. Check latency, packet loss and retransmissions, then look at CPU, throughput and capacity on the concentrator during busy periods.

The office detour adds latency, but that alone may not explain an eight second page load. The concentrator, the application, or several slow round trips could be involved. Calls dropping also makes loss and congestion worth checking.

Try terminating a VPN in AWS, in the same region as the applications. AWS Client VPN is one option. That could remove the office hop without committing to a whole new backbone.

Test it against the existing setup rather than assuming it will be faster. You'd also need to decide where inspection and access controls happen on that new path.

Check tunnel MTU and MSS too. If packets that need fragmentation get dropped and the relevant ICMP messages don't make it back, small requests can work while larger responses stall or retransmit. That's one possible cause, not a diagnosis.

A packet capture on both sides of the tunnel and a controlled MSS clamping test could help confirm or rule it out.

For mostly web-based applications, I'd evaluate zero trust application access alongside VPN and SD-WAN. Cloudflare, Netskope, Tailscale and NetBird were all suggested as options, though their features and deployment models differ.

Start with the access and inspection requirements, then test a representative app and users in different locations. Don't assume that avoiding a VPN automatically gives you the same security coverage.

Cato and Cloudflare are worth testing if the goal is to bring routing and security together, but a backbone isn't automatically the fix for a slow concentrator or an application issue. Compare performance and the security controls you need in a pilot before replacing the current setup.