Why does a VPN tunnel show “up” in the console while users on both ends stare at a spinning loading wheel? It is one of the most frustrating experiences in cloud networking, and it happens far more often than most teams expect. A cloud VPN looks simple on an architecture diagram: two gateways, one encrypted tunnel, done. In practice, that tunnel crosses the public internet, several NAT devices, two different routing domains, and a vendor’s control plane that may quietly change defaults between releases. This article walks through the problems that show up again and again, explains why they happen, and gives practical fixes that hold up in production. (RFC 4301: Security Architecture for IP (IETF))
Why cloud VPNs fail more often than people expect
A site-to-site VPN between a cloud provider and an on-premises network is really a stack of loosely coupled systems. The IPsec negotiation depends on matching proposals on both ends. The routing depends on correct prefix advertisement. The data path depends on packet sizes, firewall rules, and return routes. Any one of these can break while the others look healthy.
That is why the tunnel status indicator is such a poor diagnostic. “Up” only means the IKE security association was negotiated. It says nothing about whether packets actually traverse the tunnel, whether the far side knows how to route the reply, or whether the application can survive the latency. Experienced engineers learn to treat tunnel status as the beginning of troubleshooting, not the end.
The good news is that the failure modes are remarkably consistent across providers. Once a team learns to recognize the handful of patterns below, most outages get resolved in minutes rather than hours.
MTU and fragmentation problems: the classic “small pings work, big transfers hang”
This is the single most common cloud VPN problem, and it is also the most misdiagnosed. Encapsulation adds overhead to every packet. An IPsec tunnel wraps the original packet in new headers, so the largest packet that can cross the tunnel is smaller than the MTU of the underlying physical link. When an application sends a full-size packet, it either gets fragmented or dropped with the “don’t fragment” bit set.
The symptoms are distinctive. Small requests succeed: a ping, a DNS lookup, an SSH handshake. Then a file transfer, a database query returning a large result set, or a TLS handshake with a big certificate chain stalls or hangs. Users report that the connection “works but is slow,” which sends people chasing bandwidth problems that do not exist.
The standard fix is to clamp the TCP maximum segment size on both ends of the tunnel and set the tunnel interface MTU to a value that accounts for overhead. Path MTU discovery is supposed to handle this automatically, but it breaks whenever an intermediate firewall blocks the ICMP messages that discovery relies on. Cisco’s long-standing guidance on path MTU discovery and IP fragmentation with tunnels explains the mechanics in detail, and it is worth reading before you start guessing at numbers. (9481.org)
Practical tip: test with a large ping that has the don’t-fragment bit set, increasing the payload size until it fails. That gives you the real usable MTU on the path. Do it from both directions, because asymmetric paths are common.
NAT traversal and IKE negotiation failures
If either VPN endpoint sits behind a NAT device, the tunnel needs NAT traversal, which wraps IPsec ESP packets in UDP so that NAT devices can track the flow. Without it, negotiation may fail outright or, worse, succeed and then drop when the NAT mapping expires. The mechanism is defined in RFC 3948, the standard for UDP encapsulation of IPsec ESP packets, and both ends must support it and agree to use it.
Negotiation failures are the other half of this category. Phase 1 and phase 2 failures almost always trace back to a mismatch: different encryption algorithms, different Diffie-Hellman groups, different lifetimes, or one side running IKEv1 while the other expects IKEv2. RFC 7296 defines IKEv2 negotiation, rekeying, and dead peer detection, and it is the reference to check when a proposal is rejected.
Common mistakes worth avoiding:
- Assuming a vendor’s “default” proposal is the same across products. It is not, and it changes between firmware versions.
- Leaving aggressive mode enabled on IKEv1 for convenience. It weakens authentication and complicates troubleshooting.
- Forgetting that some cloud gateways require both tunnels of a redundant pair to be configured identically, even if only one carries traffic.
- Changing a proposal on one side and not the other during maintenance, then discovering the mismatch hours later when the tunnel rekeys.
Certificate, clock, and authentication problems
Authentication failures often look like negotiation failures but have a different root cause. Expired certificates, an untrusted certificate authority, a missing intermediate certificate, or a pre-shared key that was rotated on one side only will all produce a tunnel that refuses to come up.
The sneaky one is clock skew. Certificate validation depends on the system time being roughly correct. A cloud instance that boots without a working time source, or a firewall whose clock has drifted, will reject a perfectly valid certificate as “not yet valid” or “expired.” If a tunnel fails immediately after a maintenance window or a reboot and nothing else changed, check the time on both endpoints before touching the crypto configuration.
Cloud providers document these failure patterns in their own troubleshooting guides. The AWS Site-to-Site VPN troubleshooting documentation covers tunnel status codes, authentication errors, and BGP issues in one place, and it is a reasonable checklist even for teams running a different provider, because the underlying IPsec behavior is the same.
Overlapping CIDRs and asymmetric routing
Here is a problem that is almost unique to cloud networking. An on-premises network uses 10.0.0.0/16. Someone builds a cloud VPC with the same range because it was the default in a template. The VPN comes up. Nothing works. The tunnel is healthy, the routes exist, and packets vanish.
Overlapping CIDRs cannot be fixed with routing tricks. The only real solutions are to re-address one side or to introduce NAT between the two networks, which brings its own complications for applications that embed IP addresses in their payloads. The practical lesson is to plan address space before the migration, not after. A structured pre-migration inventory of network ranges, which is exactly the kind of groundwork described in this guide to what to inventory before a cloud migration, prevents this class of outage entirely.
Asymmetric routing is the other silent killer. Traffic enters the tunnel from on-premises, reaches the cloud workload, and the reply leaves through a different path, such as a NAT gateway or a second tunnel. Stateful firewalls and security appliances drop the reply because they never saw the original flow. The fix is to make the return path deterministic: use the same tunnel in both directions, or ensure the routing table on the cloud side points return traffic back through the VPN gateway.
BGP and route propagation issues
Dynamic routing over VPN adds resilience and adds failure modes. When BGP is in play, a tunnel can be up while the session is down, or the session can be up while the prefixes are missing.
Watch for these:
- ASN mismatches. The cloud side expects a specific autonomous system number from the customer gateway. A typo here produces a session that never establishes.
- Missing or filtered prefix advertisements. The BGP session is established, but the on-premises router is not advertising the subnets the cloud needs to reach.
- Session flaps. A flapping BGP session causes intermittent connectivity that is maddening to diagnose. Check interface errors, CPU on the customer gateway, and whether keepalive timers are too aggressive for the path latency.
- Route preference surprises. With two tunnels, the cloud may prefer one path and fail back unpredictably. Understand the provider’s route selection before you assume failover works.
Throughput, idle timeouts, and rekeying
Cloud VPN gateways have documented bandwidth ceilings, and a single IPsec tunnel often delivers less than the headline number suggests. Several factors compound:
| Factor | Effect on throughput | Practical response |
|---|---|---|
| Single tunnel limit | Caps aggregate bandwidth | Use ECMP across multiple tunnels |
| Single TCP flow | Cannot fill a high-latency tunnel | Parallelize transfers or use multiple streams |
| TCP-over-TCP behavior | Retransmission amplification | Prefer UDP-based protocols where possible |
| Encryption overhead | Reduces goodput per packet | Size instances for realistic, not theoretical, numbers |
Idle timeouts are the other quiet problem. Long-lived connections that sit idle, such as database connection pools or SSH sessions, get dropped when either side decides the tunnel is stale. Dead peer detection helps endpoints notice a dead peer quickly, but it does not prevent idle teardown. Application-level keepalives are usually the answer.
Client VPN problems: split tunneling and DNS
Remote-access VPNs fail differently from site-to-site tunnels. The most common complaint is that some resources are reachable and others are not, which usually points to split tunneling configuration. If only certain routes are pushed to the client, internal DNS resolution may go to a public resolver, or internal hostnames may resolve to addresses the client cannot reach.
A second frequent issue is DNS push itself. The client must be told which DNS servers to use for internal names, and the operating system must honor that order. When it does not, users get intermittent resolution failures that look like application bugs. The OpenVPN reference manual documents how push directives and keepalive options work, and it is a useful reference even for teams using a commercial client, because the underlying mechanisms are the same.
A troubleshooting order that actually works
Randomly toggling settings wastes time. A consistent sequence resolves most incidents faster:
- Confirm the tunnel status and check both tunnels, not just the active one.
- Verify IKE and IPsec proposals match exactly on both sides.
- Check system clocks and certificate validity on both endpoints.
- Test with a small ping, then a large don’t-fragment ping, to isolate MTU issues.
- Inspect routing tables on both sides for the specific source and destination addresses.
- Check BGP session state and advertised prefixes if dynamic routing is used.
- Review firewall and security group rules for asymmetric return paths.
- Confirm the application is not simply hitting a throughput ceiling.
Keeping a written record of the working configuration, including proposal details and MTU values, saves enormous time during the next incident. Teams that treat cloud cost and configuration reviews as engineering hygiene tend to catch these drift problems early; the approach in this piece on making cloud cost reviews useful to engineers applies equally well to network configuration reviews. For organizations running multiple environments, splitting workloads across cloud accounts also limits the blast radius when a routing mistake takes down a shared network path. (A clearer way to track cloud data transfer costs) (Virtual private network (Wikipedia))
Conclusion
Cloud VPN problems are rarely mysterious once you know where to look. The failures cluster into a small number of families: packet size and fragmentation, negotiation and NAT traversal, authentication and clocks, overlapping address space and asymmetric routing, dynamic routing errors, throughput ceilings, and client-side configuration. Each has a recognizable signature and a well-understood fix.
The teams that suffer least are not the ones with the most advanced tooling. They are the ones that document their working configuration, test the data path rather than trusting the status light, and plan address space before they build. A tunnel that says “up” is a promise, not a proof. Verify it with real traffic, and most of these problems will never surprise you twice.
Frequently asked questions
Why does my cloud VPN show as connected but no traffic passes?
Tunnel status only confirms that the security association negotiated. Traffic can still fail because of overlapping CIDRs, missing routes, asymmetric return paths, or MTU problems. Test with a small ping first, then a large don’t-fragment ping, and check routing tables on both sides for the exact source and destination addresses.
What is the most common cause of cloud VPN performance issues?
MTU and fragmentation problems top the list. Encapsulation overhead makes the usable packet size smaller than the physical link, so large transfers stall while small requests succeed. Clamping TCP MSS and setting the tunnel MTU correctly usually resolves it. Single-tunnel throughput limits are the second most common cause.
Do I need NAT traversal for a cloud VPN?
Yes, if either endpoint sits behind a NAT device. NAT traversal encapsulates IPsec ESP packets in UDP so NAT devices can track the flow. Without it, negotiation may fail or the tunnel may drop when the NAT mapping expires. Both endpoints must support it and agree to use it.
Why does my VPN fail right after a reboot or maintenance window?
Check the system clock on both endpoints before anything else. Certificate validation depends on accurate time, and a device that boots without a working time source will reject valid certificates as expired or not yet valid. Also confirm that no proposal or pre-shared key was changed on only one side.
How do I fix overlapping CIDR problems in a cloud VPN?
You cannot route around overlapping address ranges. Either re-address one of the networks or introduce NAT between them, which complicates applications that embed IP addresses in payloads. The durable fix is planning address space before deployment, so ranges never collide in the first place.
Why does my BGP session over VPN keep flapping?
Common causes include ASN mismatches, aggressive keepalive timers relative to path latency, interface errors on the customer gateway, and CPU pressure on the router. A flapping session produces intermittent connectivity that looks like random packet loss, so check session logs and interface counters before assuming the tunnel itself is at fault.
