A site-to-site VPN is an encrypted network tunnel that connects two private networks so approved systems can communicate across the public internet as if a routed private path existed between them.
For small teams, the architecture decision is not simply whether a tunnel can be established. It is whether the two networks have non-overlapping address space, the right routes, narrow firewall policy, a clear gateway owner, and a failure plan that does not accidentally expose or black-hole production traffic.
Raff Technologies supports more than 3,000 customers and 15,000 deployed VMs across cloud workloads. In network design reviews, the failure pattern we see most often is planning the VPN last: both sides already use overlapping CIDRs, application configuration contains hard-coded addresses, and nobody has documented which routes should cross the tunnel.
This guide explains site-to-site VPN architecture for office-to-cloud, data-center-to-cloud, and cloud-to-cloud connectivity. For the broader network model, start with Cloud Networking Guide. For private multi-VM design inside one VPC, use VPC Architecture for Multi-VM Applications.
Site-to-site VPN architecture connects network gateways
A site-to-site VPN normally connects gateways rather than individual users.
Office / Data Center 10.10.0.0/16 | VPN gateway | ====== encrypted tunnel ====== | Cloud VPN gateway | Raff VPC 10.20.0.0/16 | App / DB / internal services
The application VMs do not each establish their own tunnel. Routing sends traffic for the remote network toward the VPN gateway, the gateway encrypts it, and the remote gateway delivers it into the destination private network.
Typical use cases include:
- office systems reaching cloud applications privately;
- a data center connecting to cloud workloads during migration;
- two cloud environments exchanging internal service traffic;
- MSP or customer networks reaching a dedicated private application environment;
- backup, monitoring, directory, or management systems that must remain on private paths.
A site-to-site VPN should not be used merely to avoid proper authentication or firewall policy. The tunnel expands network reachability; it does not make every system on either side equally trusted.
The decision framework starts with routing and trust boundaries
Before choosing a VPN protocol, answer the architecture questions that determine whether the tunnel can be operated safely.
| Decision | Question | Recommended outcome |
|---|---|---|
| Addressing | Do the two networks overlap? | Non-overlapping CIDRs |
| Reachability | Which subnets need to cross the tunnel? | Only required routes |
| Security | Which services may use those routes? | Explicit firewall policy |
| Gateway ownership | Who operates each tunnel endpoint? | Named owner on both sides |
| Availability | What happens if one gateway or ISP fails? | Documented failure behavior |
| DNS | How will each side resolve remote services? | Intentional DNS strategy |
| Recovery | How is the tunnel recreated after a failure? | Stored configuration and validation steps |
Choose a site-to-site VPN when two private networks need persistent routed communication.
Choose client VPN or device-level access when the real requirement is individual administrator access rather than network-to-network connectivity.
Choose VPC peering when both private networks are under compatible cloud control and direct private routing is available without an internet VPN tunnel.
Choose a public API with application-layer authentication when only one service needs to communicate and extending network-level reachability would be unnecessary.
The key decision is to use the narrowest connectivity model that solves the actual dependency.
CIDR overlap should be solved before the tunnel is built
Site-to-site routing depends on each side being able to distinguish local and remote destinations.
A clean example is:
Office: 10.10.0.0/16 Raff VPC: 10.20.0.0/16
Traffic from 10.10.0.0/16 to 10.20.0.0/16 can be routed into the tunnel without ambiguity.
A problematic design is:
Office: 192.168.1.0/24 Cloud VPC: 192.168.1.0/24
Both sides believe the same addresses are local. Translation can sometimes work around overlap, but it adds complexity to routing, logs, troubleshooting, and application configuration.
Before production, document:
- local CIDR ranges;
- remote CIDR ranges;
- VPN tunnel addresses where applicable;
- routed prefixes;
- excluded networks;
- NAT or translation rules if unavoidable;
- DNS zones that must resolve across the connection.
For new environments, reserving non-overlapping private space is usually much cheaper than renumbering later.
WireGuard and IPsec fit different operating environments
Raff VPC currently supports site-to-site VPN connectivity using WireGuard or IPsec with IKEv2/PSK.
Both can create encrypted network-to-network paths, but operational fit differs.
| Area | WireGuard | IPsec / IKEv2 |
|---|---|---|
| Configuration model | Small key-based configuration | Broader standards-based parameter set |
| Common fit | Linux/cloud-native gateways, simple controlled environments | Firewalls, routers, enterprise and vendor appliances |
| Interoperability | Requires WireGuard support on both sides | Widely supported by network appliances |
| Identity | Public/private keys | Commonly PSK or certificate-based designs depending platform |
| Troubleshooting | Often simpler configuration surface | More negotiation parameters to inspect |
| Architecture priority | Endpoint compatibility and routing | Endpoint compatibility, proposals, routing, and policy |
Choose WireGuard when both gateways support it and the team prefers a compact configuration model.
Choose IPsec when the remote firewall, router, data center, or third-party network already standardizes on IPsec/IKE.
Protocol choice should come after addressing and routing design. A perfectly negotiated tunnel still fails the application if routes or firewall policy are wrong.
Routes and firewall rules should remain narrowly scoped
A tunnel creates a path. Routing and firewall policy decide what that path can carry.
Suppose an office network needs to reach only an internal application and database administration endpoint:
| Source | Destination | Service |
|---|---|---|
| Office admin subnet | Internal app admin endpoint | HTTPS |
| Office database-admin subnet | Database VM | Required DB/admin port |
| Cloud app tier | Office directory service | Required directory traffic |
That does not justify routing every office VLAN to every cloud subnet.
Use narrow routes when practical and apply firewall rules on both sides. The remote firewall should not assume that traffic is safe only because it arrived through the VPN.
Also define asymmetric-routing risks. If traffic enters through the tunnel but the return path follows a different gateway, sessions can fail even when both networks appear reachable individually.
A useful troubleshooting sequence is:
1. Tunnel state 2. Local route to remote CIDR 3. Remote route back to local CIDR 4. Firewall policy on both sides 5. NAT / translation behavior 6. DNS resolution 7. Application listener and service health
This order separates network reachability from application behavior.
High availability requires more than an encrypted tunnel
One VPN connection can become a single failure boundary if the gateway, internet path, or remote appliance fails.
For workloads with stricter availability requirements, consider:
- redundant gateways where supported;
- multiple internet circuits on the remote site;
- two tunnel paths;
- monitored failover behavior;
- route priority or dynamic routing where the environment supports it;
- application behavior when the remote network disappears.
Do not add redundant tunnels without testing their failure behavior. Two tunnels can create route ambiguity, asymmetric paths, or loops if preference and ownership are unclear.
Monitoring should include:
- tunnel state;
- packet loss and latency to known remote endpoints;
- route presence;
- gateway health;
- authentication or negotiation failures;
- application-level checks across the tunnel.
The monitoring target should not be only the VPN gateway. A healthy tunnel with a broken remote route still represents an outage for the application.
Raff VPC supports office, data-center, and cloud VPN paths
Raff VPC provides the private network on the Raff side of a site-to-site VPN architecture. The current public product supports site-to-site VPN connectivity using WireGuard or IPsec/IKEv2 with a pre-shared key, allowing teams to connect an office network, data center, or another cloud environment to a Raff VPC.
A typical Raff architecture is:
Office / another cloud | VPN gateway | encrypted tunnel | Raff VPC VPN gateway | +--> App VMs +--> Database VM / managed database path +--> Worker / internal services
Raff VPC also provides NAT, DNS, DHCP, stateful per-VM security groups, VPC peering, private service connectivity, and a 25 Gbps unmetered internal network for traffic inside the VPC.
For the VPN design itself, keep the Raff VPC CIDR non-overlapping with the remote network, route only the prefixes that need connectivity, and apply security-group or firewall policy to the workloads behind the tunnel.
Do not use article copy as the source of truth for VPN pricing. Product pricing and limits can change independently; verify the live Raff VPC page and console before making a purchasing or capacity decision.