A site-to-site VPN is an encrypted network tunnel that connects two private networks so approved systems can communicate across the public internet through a routed private path.
For small teams, the hard part is not creating the tunnel. It is making sure the two networks have non-overlapping address space, correct routes in both directions, narrow firewall policy, clear gateway ownership, working DNS, and a tested failure path.
Raff Technologies supports site-to-site connectivity for office-to-cloud, data-center-to-cloud, customer-network-to-cloud, and cloud-to-cloud designs. The current Raff model combines a private VPC with a Site-to-Site VPN gateway so internal services do not need to be exposed publicly just to communicate with another trusted network.
For the broader network model, start with the Cloud Networking Guide. For private multi-VM design inside one Raff VPC, use VPC Architecture for Multi-VM Applications.
Site-to-site VPN architecture: quick answer
A site-to-site VPN normally connects network gateways, not individual user devices.
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
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.
A good design should answer these questions before production:
- Which CIDRs exist on each side?
- Do any of them overlap?
- Which prefixes should cross the tunnel?
- Which services are allowed to use those routes?
- How will DNS work across the connection?
- What happens when the tunnel or one gateway fails?
- Who owns each side of the configuration?
When should you use a site-to-site VPN?
Use a site-to-site VPN when two private networks need persistent routed communication.
Common use cases include:
- office systems reaching cloud applications privately;
- a data center connecting to cloud workloads during migration;
- an MSP connecting a customer office to an isolated client VPC;
- two clouds exchanging internal service traffic;
- on-premises directory, monitoring, backup, or management systems reaching cloud workloads;
- administrators reaching Windows or Linux infrastructure from a controlled corporate network.
A site-to-site VPN is usually not the right tool when only one administrator needs access. In that case, remote-access VPN, bastion, or another restricted admin path is often simpler.
Likewise, if only one public API needs to communicate, application-layer authentication may be narrower than extending network-level reachability.
Site-to-site VPN vs remote-access VPN
The two models solve different problems.
| Model | Connects | Typical use |
|---|---|---|
| Site-to-site VPN | Network ↔ network | Office, data center, customer LAN, another cloud |
| Remote-access VPN | User/device ↔ network | Administrator laptop, support technician, developer |
A site-to-site tunnel should not be used simply because several people need admin access. If the real requirement is named user access, remote-access VPN provides a cleaner identity and offboarding boundary.
Site-to-site VPN vs VPC peering
VPC peering and site-to-site VPN can both connect private address spaces, but they are not the same architecture.
VPC peering is appropriate when compatible private networks can connect directly inside the cloud environment.
Site-to-site VPN is appropriate when one side is an office, customer firewall, data center, another cloud, or another network that must traverse an encrypted tunnel.
Use the narrowest connectivity model that matches the actual network boundary.
CIDR overlap should be solved before tunnel configuration
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 networks believe the same addresses are local.
Translation can sometimes work around overlap, but it increases complexity in:
- routing;
- logging;
- firewall rules;
- DNS;
- troubleshooting;
- application configuration;
- incident response.
Before production, document:
- local CIDRs;
- remote CIDRs;
- VPN address ranges where applicable;
- routed prefixes;
- excluded networks;
- NAT or translation rules;
- DNS zones that must resolve across the tunnel.
For new environments, reserving non-overlapping private address space is usually much easier than renumbering later.
WireGuard vs IPsec for site-to-site VPN
Raff currently supports site-to-site tunnels using WireGuard or IPsec with IKEv2 and a pre-shared key.
Both can create encrypted network-to-network paths, but the operating model differs.
| Area | WireGuard | IPsec / IKEv2 |
|---|---|---|
| Configuration model | Compact key-based setup | Broader standards-based negotiation |
| Common fit | Linux/cloud-native gateways, modern routers | Firewalls, routers, enterprise appliances |
| Interoperability | Requires WireGuard support | Widely supported by network appliances |
| Identity | Public/private keys and peer configuration | Commonly PSK or certificate-based designs depending platform |
| Troubleshooting | Smaller configuration surface | More proposals and negotiation parameters |
| Good default when | Both endpoints support it cleanly | Remote appliance already standardizes on IPsec |
Choose WireGuard when both gateways support it and the team wants a compact configuration model.
Choose IPsec/IKEv2 when compatibility with existing firewalls, routers, customer appliances, or enterprise network standards is the priority.
Protocol choice comes after addressing and routing design. A perfectly negotiated tunnel still fails if the route or firewall policy is wrong.
Routes must exist in both directions
A tunnel being “up” does not mean the application path works.
For a successful connection, both sides need a valid return path.
Office → Raff VPC Route 10.20.0.0/16 → VPN Raff VPC → Office Route 10.10.0.0/16 → VPN
A common failure is asymmetric routing: traffic enters through the VPN but the response leaves through another gateway or default route.
A useful troubleshooting order is:
1. Tunnel state 2. Local route to remote CIDR 3. Remote route back to local CIDR 4. Firewall/security policy on both sides 5. NAT or translation behavior 6. DNS resolution 7. Application listener and service health
This separates network reachability from application behavior.
Routing creates reachability; firewall policy creates permission
A route should not automatically imply that every host on one network may reach every service on the other.
Suppose an office network needs to reach only an internal web application and a database administration endpoint:
| Source | Destination | Allowed traffic |
|---|---|---|
| Office admin subnet | Internal app admin endpoint | HTTPS |
| Office DBA subnet | Database service | Required DB/admin port |
| Cloud app tier | Office directory service | Required directory traffic |
That does not justify routing every office VLAN to every cloud service with unrestricted firewall policy.
Treat the VPN as a transport path. Authentication, authorization, firewall rules, and least privilege remain separate controls.
NAT can be useful, but it complicates the design
NAT may be necessary when:
- private CIDRs overlap;
- a partner requires a translated address range;
- the remote side allows only specific source ranges;
- legacy systems cannot be renumbered.
But translation changes what operators see in:
- logs;
- firewall rules;
- application allowlists;
- troubleshooting;
- monitoring.
If NAT is used, document both the original and translated address ranges and make sure the return path follows the same design.
Do not use NAT as a substitute for fixing avoidable address overlap in a new environment.
DNS must be designed as part of the VPN
Private connectivity often fails at the application layer because routing works but names do not resolve.
Decide:
- whether office systems need to resolve cloud-private names;
- whether cloud workloads need to resolve office/internal names;
- which resolver is authoritative;
- whether conditional forwarding or split DNS is required;
- what happens when the remote DNS service is unavailable.
Avoid hard-coding private IP addresses into applications when stable internal DNS names can provide a cleaner replacement and recovery path.
MTU and MSS problems can look like application failures
VPN encapsulation adds overhead. In some paths, large packets may fragment or be dropped when the effective MTU is lower than expected.
Symptoms can include:
- small pings succeed while large transfers fail;
- SSH works but file copies stall;
- HTTPS connections establish but hang during larger responses;
- database connections are unstable under real traffic;
- only certain applications or packet sizes fail.
When the tunnel is up and routes are correct but larger transfers behave strangely, check MTU, path MTU discovery, and TCP MSS handling on the gateways.
Do not change MTU values blindly. Confirm the failing packet path first.
High availability requires more than two tunnels
One VPN connection can become a single failure boundary if the gateway, ISP, remote firewall, or route disappears.
For stricter availability requirements, consider:
- redundant gateways where supported;
- multiple internet circuits at the office or data center;
- two tunnel paths;
- monitored failover;
- route priority or dynamic routing where appropriate;
- application behavior when the remote network disappears.
Do not assume that two tunnels equal high availability.
Two active paths can create:
- asymmetric routing;
- route ambiguity;
- loops;
- unexpected failback;
- duplicate or unstable paths.
Failover should be tested under representative application traffic, not only with a tunnel-status indicator.
Monitoring should test the application path, not only tunnel state
A VPN can report “up” while production traffic is still broken.
Monitor:
- tunnel state;
- packet loss and latency to known remote endpoints;
- route presence;
- gateway health;
- negotiation/authentication failures;
- DNS resolution;
- application-level checks through the tunnel.
A useful hierarchy is:
Tunnel established ↓ Route available ↓ Remote host reachable ↓ Required port reachable ↓ Application request succeeds
The last check is the one users actually care about.
Windows and RDP workloads fit site-to-site VPN well
A site-to-site VPN is useful when administrators or office users need private access to Windows workloads without exposing RDP directly to the internet.
Office network ↓ encrypted site-to-site VPN Raff VPC ↓ private IP Windows VM
Keep named Windows identities, Network Level Authentication where supported, least-privilege Administrator membership, patching, and target-system firewall rules as separate controls.
For Raff workloads, Windows VM can participate in the same VPC and VPN design as Linux infrastructure.
Databases should remain private behind the tunnel
A site-to-site VPN can give office tools, administrators, or application systems private access to databases without publishing the database port to the internet.
A cleaner design is:
Office admin / application ↓ Site-to-Site VPN Raff VPC ↓ private path Database
Restrict database access to the specific office/admin/application ranges that need it.
If the team does not want to operate the database host itself, Raff Managed Databases can be part of the private application architecture.
MSP customer networks need one tunnel boundary per trust model
For MSPs, a site-to-site VPN can connect a customer office to that customer's isolated cloud environment.
Avoid creating a shared tunnel topology where one customer network can accidentally route into another.
A cleaner model is:
Customer A office ↓ tunnel Customer A VPC Customer B office ↓ tunnel Customer B VPC
The tunnel, VPC, firewall rules, credentials, monitoring, and recovery ownership should map to the same customer boundary.
Use Private Cloud Networking for MSPs for the full client-isolation model.
Raff Site-to-Site VPN: current architecture and pricing
Raff Site-to-Site VPN connects an office, data center, customer network, or another cloud to a Raff VPC using WireGuard or IPsec/IKEv2.
Current Raff facts relevant to this architecture are:
- VPC traffic is private and unmetered;
- Raff VPC has no separate VPC charge;
- Site-to-Site VPN supports WireGuard and IPsec/IKEv2;
- each VPN gateway can support up to 10 site tunnels;
- multiple remote subnets can be associated with a tunnel;
- tunnel traffic is unmetered in both directions;
- the VPN gateway is approximately $15/month and is billed hourly;
- each site-to-site tunnel is $20/month and is billed hourly;
- the same gateway can also serve up to 10 WireGuard remote-access peers.
A typical Raff architecture is:
Office / data center / another cloud | WireGuard or IPsec | Raff VPN gateway | Raff VPC ├─ App VMs ├─ Windows VMs ├─ Database / managed database path └─ Workers / internal services
Keep the VPC CIDR non-overlapping with the remote network, route only the prefixes that need connectivity, and restrict target workloads with firewall/security policy after the tunnel is established.