Common failure signs are that the tunnel comes up but hosts cannot ping each other, routes do not appear in the expected tables, or packets never pass because firewall rules and security groups were not aligned. Another signal is mismatched addressing between the clouds. These issues usually point to configuration gaps rather than a broken VPN product.
How to spot a cross-cloud VPN that is up but not actually working
A cross-cloud VPN can appear healthy at the tunnel layer while still failing to carry usable traffic. The most useful signal is not whether the VPN endpoint reports “up,” but whether return paths, routing tables, and security controls all agree across both clouds. When those layers diverge, the tunnel is only nominally established.
Common operational signs include an established tunnel with no host-to-host reachability, missing or incomplete routes in one cloud’s tables, and traffic that dies silently because firewall rules, security groups, or network policies were never aligned. Mismatched CIDR ranges or overlapping addressing between clouds is another strong indicator that the design, not the VPN appliance itself, is the real problem.
Why tunnel status is a weak health check
A VPN tunnel coming up only proves that two peers can negotiate a secure session. It does not prove that packets can traverse the full path, that the right prefixes are being advertised or accepted, or that return traffic can make it back. In cross-cloud setups, the real dependency is end-to-end routing plus policy symmetry, not the tunnel state alone.
That is why “up” but unusable VPNs often show a split between control-plane success and data-plane failure. If the tunnel exists but no traffic flows, the likely causes are route propagation failure, asymmetric routing, missing allow rules, or address overlap that causes one cloud to send packets to the wrong destination entirely.
Another practical clue is inconsistency across layers: one cloud may show a route, but the peer cloud does not; one side may allow the subnet, while the other side blocks it; or the tunnel may carry some traffic while specific applications or subnets fail. That pattern usually points to partial configuration, not a random transport defect.
Where the breakdown usually sits
The most common failure point is the interface between routing and policy. A cloud VPN can be configured correctly at the gateway level while still failing because the relevant route tables were never updated, the propagated prefixes were suppressed, or the security posture on one side does not match the source and destination ranges.
Addressing errors are especially common in multi-cloud deployments. If the two environments use overlapping or inconsistent CIDR blocks, the VPN may come up cleanly but traffic will be misdirected, blackholed, or delivered to the wrong network segment. In practice, that produces symptoms that look like packet loss, but the root cause is usually design and configuration drift.
For teams operating across shared cloud infrastructure, the control expectation is to align routing, segmentation, and identity-aware policy together rather than treating the VPN as a standalone fix. Authoritative cloud control guidance such as the CSA Cloud Controls Matrix and the NIST SP 800-207 Zero Trust Architecture both reinforce that connectivity must be evaluated together with access policy and trust boundaries.
Risk and Threat Considerations
A cross-cloud VPN that is partially working can create a false sense of connectivity while silently exposing data paths, operational dependencies, or unreachable recovery links. The risk is not only outage, but also hidden segmentation failure, because teams may assume protected communication exists when the route or policy chain is actually broken.
Failure mechanism: The tunnel establishes successfully, but route advertisement, security group alignment, or subnet design prevents end-to-end packet delivery, often with asymmetric or blackholed traffic.
Impact: Applications fail in ways that are hard to diagnose, failover and backup paths do not behave as expected, and operators may keep relying on a connection that is not carrying the traffic they think it is.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Cross-cloud VPN failure often reflects broken traffic paths and policy boundaries. |
| AC-4 — Information Flow Enforcement | Route and firewall mismatches prevent intended flows between cloud networks. | |
| CM-2 — Baseline Configuration | Address-plan drift and misaligned settings are common causes of working-tunnel failures. | |
| Recommendation — Enforce boundary policies and verify traffic can traverse approved paths end to end. Define and test information flow rules for each cross-cloud subnet pair. Maintain a tested network configuration baseline for both cloud environments. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Cross-cloud VPN health depends on routing, firewall, and segmentation management. |
| Recommendation — Inventory and review network rules, routes, and segmentation changes continuously. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Network Segmentation | VPNs must still enforce segmented, verifiable paths across trust boundaries. |
| Recommendation — Apply segmentation and validate each cross-cloud path independently. | ||
Practitioner Guidance
What to verify: Confirm the tunnel state, then verify route tables, prefix advertisements, security groups, network ACLs, and source and destination CIDR compatibility as separate checks. If the tunnel is up but host reachability fails, treat routing and policy as the primary suspects before changing the VPN product or preshared key.
What practitioners underestimate: The most common mistake is diagnosing a “VPN failure” when the actual fault is a cross-cloud design mismatch. In multi-cloud environments, packet flow depends on both sides agreeing on address space and policy, so a tunnel that is technically established may still be operationally useless.
Practitioner takeaway: Judge cross-cloud VPN health by verified bidirectional traffic, not by tunnel status, and treat route symmetry plus address-plan hygiene as first-class controls rather than cleanup tasks.
Related resources from NHI Mgmt Group
- What are the signs that an OTel Collector setup is failing in practice?
- What are the signs that cloud privilege controls are failing in practice?
- What are the signs that a cloud exposure management programme is failing in practice?
- What are the signs that a VPN model is failing security teams in practice?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
