Site-to-Site Tunnel in Private Cloud: Architecture, Configuration, Security, and Use Cases
A Site-to-Site VPN tunnel in a private cloud creates an encrypted connection between an organization’s on-premises network and its private cloud infrastructure. Instead of exposing internal applications, databases, servers, or management interfaces directly to the public internet, the VPN establishes a secure network path between two private environments. For businesses running applications across offices, data centers, branch locations, and private cloud environments, site-to-site connectivity is an important part of the network architecture. It allows users and systems in one network to communicate with resources in another network using private IP addressing while encryption protects traffic while it travels across an untrusted network. A typical implementation connects an office firewall or router to a VPN gateway in the private cloud. Once the tunnel is established, authorized traffic can travel between the two networks. For example: Office Network → Internet → Encrypted VPN Tunnel → Private Cloud Network This architecture is commonly used for ERP applications, databases, file servers, business applications, backup systems, monitoring platforms, Active Directory, and hybrid infrastructure. What Is a Site-to-Site Tunnel? A site-to-site tunnel is a persistent or on-demand encrypted connection between two networks. Unlike a remote-access VPN, where an individual user connects to a corporate network, a site-to-site VPN connects entire networks. For example: In this example, a server at: 10.10.0.50 could communicate with a private cloud server at: 10.20.10.25 through the VPN tunnel. The application does not necessarily need to know that the traffic is crossing the public internet. Routing determines that traffic destined for the private cloud subnet should be sent through the VPN gateway. Why Use Site-to-Site VPN in a Private Cloud? Private cloud environments are generally designed to isolate workloads and restrict unnecessary network exposure. However, organizations still need connectivity between their existing infrastructure and cloud workloads. Consider a company that already has: The company may want to move selected workloads to a private cloud without completely replacing its existing infrastructure. A site-to-site VPN can provide the network connectivity required for this hybrid architecture. Example Suppose an organization has: Office 192.168.10.0/24 Private Cloud 10.50.0.0/16 The company can establish a VPN tunnel between the office firewall and the private cloud VPN gateway. After routing is configured: Users in the office can access permitted private cloud resources without exposing those resources directly to the internet. How Site-to-Site VPN Works A site-to-site VPN normally uses a VPN protocol such as IPsec. IPsec provides mechanisms for: The two VPN endpoints establish security parameters and authenticate each other. A simplified process looks like this: The exact negotiation depends on the VPN implementation. For modern IPsec deployments, IKEv2 is commonly used for negotiating the security association. Site-to-Site VPN Architecture in Private Cloud A basic private cloud architecture may look like this: Internet | ——————— | | Office ISP Private Cloud ISP | | Firewall/VPN VPN Gateway | | | IPsec | |===================| | Private Network | ——————— | | | Web App Database Server Server Server The VPN gateway acts as the secure entry point into the private cloud network. The private cloud workloads should normally remain on private IP addresses unless there is a specific requirement for public exposure. Components Required for a Site-to-Site Tunnel A successful deployment typically requires several components. 1. On-Premises Firewall or Router The organization’s existing firewall or router acts as one VPN endpoint. Examples include enterprise firewall platforms, router-based VPN gateways, or dedicated security appliances. The device should support the required VPN protocol and encryption configuration. 2. Private Cloud VPN Gateway The second VPN endpoint resides in the private cloud environment. This could be: The gateway receives VPN traffic and routes authorized packets toward private cloud workloads. 3. Private IP Addressing Both networks require defined IP ranges. For example: The networks should not overlap. Overlapping subnets can create routing ambiguity. For example, if both locations use: 192.168.1.0/24 the VPN cannot reliably determine whether: 192.168.1.50 belongs to the office or the cloud. Therefore, address planning should be completed before configuring the tunnel. 4. Routing VPN encryption alone does not automatically make every network reachable. Routes must tell each network where the remote subnet exists. For example, the office router could contain: The private cloud network could contain: This creates bidirectional routing. IPsec Site-to-Site VPN IPsec is one of the most widely used technologies for site-to-site VPN connections. It operates at the network layer and can protect IP traffic between network endpoints. An IPsec deployment generally involves two important phases. Phase 1 Phase 1 establishes the secure management channel used to negotiate the VPN. With IKEv2, peers authenticate and establish cryptographic parameters. Typical configuration parameters can include: Phase 2 Phase 2 establishes the parameters for protecting actual application traffic. This includes: The exact terminology varies between implementations. Example IPsec Configuration Suppose: Office Private Cloud The VPN tunnel could conceptually be configured as: The VPN gateways then negotiate the cryptographic parameters. Once the tunnel is established, traffic between the defined networks can be encrypted. Route-Based vs Policy-Based VPN One important architectural decision is whether to use a route-based VPN or a policy-based VPN. Policy-Based VPN A policy-based VPN defines which traffic should enter the tunnel. For example: Traffic matching the policy is encrypted. This approach can be relatively straightforward for simple network environments. However, it can become difficult to manage when the number of networks grows. Route-Based VPN A route-based VPN uses a tunnel interface. Routing determines which traffic should use the VPN. Conceptually: This architecture can be more flexible for larger environments. It can also work well with dynamic routing protocols and more complex cloud network architectures. Site-to-Site VPN vs Remote-Access VPN These two VPN types solve different problems. Feature Site-to-Site VPN Remote-Access VPN Connection Network to network User to network Users Multiple users/devices Individual users Typical endpoint Firewall/router VPN client Common use Office to cloud Employee remote access Persistent connectivity Usually yes Often on demand Centralized routing Yes Usually client-based For example, if ten employees need to access a private cloud application from home, a remote-access VPN may be appropriate. If an entire
