A VPN only creates the tunnel. Teams still need explicit routes so each side knows where to send traffic, and they need policy rules that allow the right ports and protocols between the two networks. Without that layer, the tunnel may establish successfully while workloads remain unreachable. Proper network segmentation also reduces accidental exposure across cloud boundaries.
Why the tunnel is only one part of connectivity
A VPN gives you encrypted transport and authenticated session establishment, but it does not automatically make two cloud networks routable to each other in the way the workloads expect. The packet still needs a valid path through routing tables, and the destination side still needs to know which source ranges are permitted. A tunnel can be up while the application path remains broken.
That is why cloud-to-cloud VPN design has to treat connectivity as a full network-path problem, not just a tunnel problem. Route advertisement, static routes, return routing, and address overlap all affect whether traffic actually reaches the target subnet and comes back successfully.
When teams assume “VPN up” means “network connected,” they often miss asymmetric routing, missing return routes, or overlapping CIDRs that make traffic disappear into the wrong boundary. In practice, the most useful test is whether a specific workload-to-workload flow can traverse both directions, not whether the tunnel interface reports established.
Why firewall policy still matters after encryption
VPN encryption protects the transport, but firewalls decide which ports, protocols, and source and destination ranges are allowed to talk. Without explicit policy, a tunnel may create a broad trust path that is either too open or too closed. Good design keeps the tunnel narrow while allowing only the business flows that are actually required.
This is where segmentation becomes important. A cloud VPN should not collapse the boundary between environments; it should preserve it. Security teams usually want the route to exist, but the firewall to enforce least privilege across that route, so databases, management planes, and application tiers are not unintentionally exposed just because the networks are connected.
For a practical reference point on that design principle, NIST SP 800-207 Zero Trust Architecture reinforces the idea that connectivity and trust are separate decisions, and that network location alone should not grant broad access.
What usually breaks in multi-cloud VPN deployments
The common failure modes are not the tunnel itself, but the assumptions around it. Missing routes, one-way return paths, blocked ephemeral ports, and inconsistent firewall rules across cloud providers are the usual reasons a connection appears healthy while applications still fail. Address plan mistakes are especially painful because overlapping subnets can make the path ambiguous from day one.
Operationally, the problem is often compounded by change control. One team updates a route table, another tightens a security rule, and the result is an outage that looks like a VPN issue even though the root cause is policy inconsistency. Cloud routing and firewall design have to be managed together because either control can silently override the other.
From a hardening perspective, this is also the point where NIST Cybersecurity Framework 2.0 is useful as a governance lens for protecting network pathways, and NIST SP 800-53 Rev 5 Security and Privacy Controls aligns well to access control, boundary protection, and configuration management decisions that keep the path predictable.
Risk and Threat Considerations
A VPN can create a false sense of trust if routing and firewall rules are broader than intended. The main risk is not just outage, but unintended lateral reach across cloud boundaries, especially when a connected network inherits access to internal services that were never meant to be exposed over the tunnel.
Failure mechanism: A route exists, the tunnel is live, but firewall policy, return routing, or subnet planning is wrong, so traffic is either dropped or allowed far more broadly than intended.
Impact: Workloads become unreachable, segmentation breaks down, and a compromised system on one side of the tunnel can gain an easier path to sensitive services on the other side.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AA-05 — Network Segmentation | Segmentation is central to limiting cloud-to-cloud reach over VPN paths. |
| Recommendation — Define and enforce segmented network paths so only intended flows can traverse the VPN. | ||
| NIST SP 800-53 Rev 5 | AC-4 — Information Flow Enforcement | Firewall rules and allowed flows govern which traffic can cross the connected boundary. |
| CM-2 — Baseline Configuration | Routing and firewall consistency depend on controlled, documented network baselines. | |
| Recommendation — Enforce flow restrictions at the boundary so only approved ports and protocols pass. Baseline and review routing and firewall settings to prevent drift between environments. | ||
| NIST Zero Trust (SP 800-207) | SC-7 — Boundary Protection | A VPN boundary still needs explicit path control and internal segmentation. |
| Recommendation — Apply boundary protection controls to keep tunnel access narrow and verified. | ||
Practitioner Guidance
What to verify: Test the exact source, destination, port, and protocol combination for every critical workload flow, then confirm both forward and return routing. A tunnel health check is not enough evidence that the application path works.
Common mistake: Treating the VPN as the control plane for access decisions. The tunnel establishes transport, but the firewall and route tables determine whether the path is usable, constrained, and segmented the way you intended.
What good looks like: Each allowed flow is explicitly documented, route symmetry is confirmed, overlapping CIDRs are avoided, and firewall policy is narrow enough that a connected cloud does not inherit blanket trust.
Practitioner takeaway: Design VPN connectivity as a layered network path, not a binary connection state, because the security and reliability outcome is determined by routing plus policy, not the tunnel alone.
