Every time a remote worker opens a company file or a branch office syncs its servers to the cloud, data crosses the public internet. That is a lot of exposure. A cloud VPN closes that gap by building an encrypted tunnel between your private network and a cloud provider’s virtual network. This tutorial walks through what that tunnel actually is, how to build one step by step, and the mistakes that trip up even experienced engineers.
The core idea is simple: a cloud VPN connects two networks that would otherwise be strangers, and it does so over the open internet while keeping the traffic private. Get the design right and you get secure hybrid connectivity at a fraction of the cost of a dedicated private line. Get it wrong and you get a tunnel that drops every few hours or, worse, one that quietly leaks traffic.
What a Cloud VPN Actually Does
A cloud VPN is a managed service that creates an encrypted IPsec tunnel between your on-premises network (or another cloud) and a cloud provider’s virtual private cloud. Traffic enters one end, gets encrypted, travels across the internet, and is decrypted at the other end as if both networks sat in the same building.
Three major providers dominate this space, and each has its own flavor of the same concept:
| Provider | Service name | Typical design |
|---|---|---|
| Google Cloud | Cloud VPN (HA VPN and Classic VPN) | Two interfaces, two tunnels for redundancy |
| AWS | Site-to-Site VPN | Two tunnels per connection by default |
| Microsoft Azure | VPN Gateway | Active-active or active-passive gateway options |
The underlying protocol family is IPsec, usually paired with IKEv2 for key exchange. IKEv2 is the modern standard and is generally recommended over the older IKEv1 because it handles reconnection and mobility more gracefully. If you’re comparing how cloud platforms stack up before committing, this breakdown of AWS vs Azure vs Google Cloud 2026 is a useful starting point.
One thing beginners often miss: a cloud VPN is not the same as a consumer VPN app. A consumer VPN hides your browsing from your ISP. A cloud VPN links entire networks together for business purposes. The two share encryption technology but solve completely different problems. If you want to understand that distinction better, this explainer on VPN vs proxy: what is the difference covers the consumer side in plain terms.
Before You Build: Prerequisites and Planning
Jumping straight into the console is the most common mistake. A cloud VPN that works reliably starts with decisions made before a single setting is clicked.
Decide on routing first. You have two choices: static routing, where you manually list the remote subnets, or dynamic routing with BGP (Border Gateway Protocol), where the two sides automatically exchange route information. BGP is more resilient because it adapts when a path fails, but it requires both ends to support it. Static routing is simpler and fine for small, stable setups.
Check for overlapping IP ranges. If your on-premises network uses 10.0.0.0/16 and your cloud VPC also uses 10.0.0.0/16, the tunnel will come up but traffic will go nowhere useful. Map your address space carefully before you start.
Confirm your firewall can pass IPsec. You need UDP ports 500 and 4500 open, plus the ESP protocol. Many corporate firewalls block these by default, and a blocked port is the single most frequent reason a tunnel refuses to establish.
Gather your peer IP. You’ll need the public IP address of your on-premises VPN device or firewall. If that address is dynamic, get a static one first, because the cloud side needs a fixed target.
Step-by-Step: Building a Cloud VPN Tunnel
The exact menus differ between providers, but the logical sequence is nearly identical everywhere. Here is the workflow that works across Google Cloud, AWS, and Azure.
- Create or identify your VPC network. This is the cloud-side network the tunnel will attach to. Note its region and subnet ranges.
- Reserve a VPN gateway. In Google Cloud this is the HA VPN gateway; in AWS it’s the virtual private gateway or transit gateway; in Azure it’s the VPN gateway resource. This step can take several minutes to provision.
- Create the peer gateway. This represents your on-premises device. Enter its public IP address and, if you’re using BGP, its autonomous system number (ASN).
- Build the tunnels. Most providers create two tunnels automatically for redundancy. Each tunnel gets its own shared secret, which you must copy to your on-premises device exactly.
- Configure routing. Choose static routes or enable BGP. If you pick BGP, set the cloud-side ASN and the peer ASN.
- Add firewall rules. Open the ports your applications need on both sides. The tunnel being “up” does not mean traffic is allowed through.
- Configure your on-premises device. Paste in the shared secrets, peer IPs, and encryption parameters. Match the IKE version and cipher suites on both ends.
- Test the tunnel. Check status in the console, then ping a host on the far side and run a traceroute to confirm traffic takes the expected path.
A practical tip from the field: configure the on-premises side last, after the cloud side is fully provisioned. The cloud console will show you the exact parameters to enter, and copying them reduces transcription errors. Shared secrets are long and case-sensitive, and a single wrong character produces a tunnel that fails with a generic error.
Choosing Encryption and IKE Settings
Most providers offer a set of predefined cipher profiles. Unless you have a specific compliance requirement, start with the default profile, which typically pairs IKEv2 with AES-256 encryption and SHA-256 integrity checking. These are strong, widely supported settings. (Use Strong Passwords)
Where people get into trouble is mismatched settings. If your on-premises firewall insists on IKEv1 with 3DES and the cloud side expects IKEv2 with AES, the tunnel will never come up. The fix is to align both ends on the same profile, and the modern choice is IKEv2 with AES-256.
Resist the temptation to weaken encryption just to make a stubborn tunnel connect. Downgrading to older ciphers to force a handshake trades a temporary fix for a permanent security hole. If your hardware can’t support modern ciphers, that’s a signal to update the hardware, not the encryption.
For organizations handling sensitive data, NIST publishes detailed guidance on IPsec VPN architecture that’s worth reading before finalizing your cipher choices.
Common Mistakes and How to Avoid Them
After enough tunnel builds, patterns emerge. These are the errors that show up again and again.
Forgetting the return route. Traffic goes out through the tunnel but comes back the wrong way because the on-premises router doesn’t know about the cloud subnet. Always verify routes in both directions.
Ignoring the second tunnel. Providers give you two tunnels for a reason. If you only configure one and it fails, you have no redundancy. Configure both, even if one sits idle.
Skipping the keepalive. Idle tunnels sometimes drop. Enable dead peer detection so the connection re-establishes automatically instead of waiting for someone to notice.
Overlooking MTU. Encapsulation adds overhead, and packets that are too large get dropped silently. If large transfers stall but pings work, MTU is usually the culprit.
Testing only from one host. A single successful ping proves almost nothing. Test from multiple subnets and multiple directions before declaring victory.
Security Practices That Actually Matter
A tunnel encrypts traffic in transit, but it doesn’t secure everything by itself. A few habits make a real difference.
Rotate your pre-shared keys periodically. Many teams set them once and never touch them again, which means a leaked key stays valid for years. Schedule rotation like any other credential.
Restrict which subnets can traverse the tunnel. You rarely need to expose your entire on-premises network to the cloud. Narrow the route table to only the subnets that genuinely need to communicate.
Log tunnel events and review them. Failed handshakes, repeated reconnections, and unusual traffic patterns are early warnings. A tunnel that reconnects every ten minutes is telling you something.
Finally, treat the cloud VPN as one layer, not the whole security strategy. Identity controls, least-privilege access, and monitoring all matter just as much. For a broader view of how major providers handle their own infrastructure security, this piece on Apple private cloud compute and Google Cloud in 2026 shows how seriously the big platforms treat the boundary between customer data and provider systems.
Monitoring and Maintaining Your Tunnel
Once the tunnel is live, the work shifts from building to watching. Set up alerts on tunnel status so you learn about a dropped connection from a dashboard, not from an angry user.
Track a few key metrics: tunnel uptime, bytes transferred in each direction, and handshake failures. A sudden drop in throughput often precedes an outage. A spike in handshake failures usually means a credential or configuration mismatch crept in.
Document everything. The engineer who built the tunnel will not always be the one who debugs it at 2 a.m. Write down the peer IPs, ASNs, cipher profiles, and route tables in a place the whole team can find. Future you will be grateful.
Conclusion
A cloud VPN is one of the most cost-effective ways to connect private networks to the cloud securely, and the process is more approachable than it first appears. The winning formula is straightforward: plan your address space and routing before you touch a console, align encryption settings on both ends, configure both tunnels for redundancy, and test from multiple directions before calling it done. Most failures trace back to a handful of causes, a blocked port, a mismatched cipher, a missing return route, or a typo in a shared secret. Build carefully, monitor continuously, and rotate your keys on a schedule. Do those things and the tunnel fades into the background, doing its quiet job of keeping your data private as it crosses the open internet.
Frequently Asked Questions
What is the difference between a cloud VPN and a site-to-site VPN?
They’re closely related. A site-to-site VPN is the general concept of linking two networks over an encrypted tunnel. A cloud VPN is a managed service that implements site-to-site connectivity specifically between your network and a cloud provider’s virtual network. In practice, most cloud VPNs are site-to-site VPNs, just delivered as a managed cloud product.
Do I need BGP to run a cloud VPN?
No. You can use static routing, where you manually list the remote subnets. BGP is recommended when you want automatic failover and dynamic route updates, but for small, stable setups, static routing works fine and is simpler to configure.
Why does my tunnel show as “up” but no traffic passes?
This is usually a routing or firewall issue, not a tunnel issue. The tunnel being up only means the encrypted connection is established. Check that firewall rules allow the traffic, that routes exist in both directions, and that your subnet ranges don’t overlap.
How many tunnels should I configure?
Configure at least two. Most cloud providers create two tunnels by default precisely so you have redundancy. If you only set up one and it fails, connectivity drops entirely. Configure both, even if the second sits mostly idle.
Can I connect multiple branch offices to one cloud VPN?
Yes, and it’s a common design. Each branch typically gets its own tunnel or its own peer gateway. With BGP and a transit gateway or hub-and-spoke architecture, you can route traffic between branches through the cloud without building a full mesh of direct connections.
How often should I rotate VPN pre-shared keys?
There’s no universal rule, but rotating every 90 to 180 days is a reasonable practice for most organizations, and more frequently for sensitive environments. The key point is to schedule it rather than leaving keys unchanged for years. A leaked key that never rotates stays a valid entry point indefinitely.
