Our remote staff currently connect to a VPN concentrator at head office, where their traffic is inspected before being sent onward. That means someone in Lisbon accessing services in AWS eu-west-1 may travel to the UK office first and then back to the cloud region. The resulting symptoms include dropped calls and an internal ticketing application that can take around eight seconds to load a page.
I'm considering a platform with distributed points of presence and integrated security rather than fixing routing now and bolting on another inspection product later. Cato looks appealing because it combines SD-WAN, a private backbone, and security services. Cloudflare also seems relevant, although I'm less familiar with its enterprise networking options.
Before choosing a provider, what should I diagnose first? Could the real problem be an overloaded concentrator, deep inspection, DNS, MTU/MSS issues, or something unrelated to the route? Would split tunneling, direct termination in AWS, or a zero-trust access model be more sensible for this situation?
5 Answers
If the workload is primarily in one AWS region, terminating remote access close to that region may be the simplest fix. A managed client VPN or a regional access service could remove the detour without introducing a full private-backbone platform. If you need to connect multiple offices, control general egress, and apply consistent security policies across sites, an integrated SD-WAN and security product is a stronger fit. Cloudflare may be sufficient for distributed application access, while Cato is the more complete network replacement.
Diagnose the existing path before buying a backbone. Reading to eu-west-1 should not add a huge amount of latency by itself, so the concentrator may be saturated or the inspection layer may be struggling. Compare the application from the office LAN, through the VPN, and directly from an external connection. Packet captures and browser timing data should show whether this is latency, retransmissions, or a slow application response.
I’m testing the page with the tunnel out of the path first. I hadn’t considered MSS clamping, so I’ll check that too.
The immediate architectural issue is the hairpin: all remote traffic is being dragged through one central site. Split tunneling can send ordinary internet and cloud traffic directly while retaining the VPN only for genuinely internal services. If nearly everything is web-based, zero-trust access may be more appropriate than replacing the concentrator with a larger SD-WAN design.
Moving to a modern zero-trust design can remove the need to put every user on the corporate network. Use regional access points, device and user authentication, conditional access, and application-specific policies. Keep private connectivity for systems that truly need it, but avoid sending all traffic through headquarters just to centralize security. The right choice depends on whether the main requirement is private site connectivity, access to a few applications, or secure internet egress.
Eight seconds with a roughly low-millisecond round-trip time often points to repeated retransmissions or a stalled connection rather than distance. Check tunnel MTU and MSS clamping, and verify that ICMP fragmentation-needed messages are not being blocked. DNS is another common source of long delays: confirm which DNS servers the VPN pushes, whether split DNS is configured correctly, and whether internal reverse lookups or registration failures are timing out.
Deep inspection could still be the bottleneck, so I’d measure CPU, memory, session counts, throughput, and inspection latency on the current concentrator before assuming the route is the whole problem.