What is a Site-to-Site Tunnel?

A site-to-site tunnel (S2S) is an encrypted IPsec or GRE connection between a Versa SASE gateway or VOS device and a peer network – an enterprise data center, a cloud VPC or VNet gateway, or a third-party device. It carries private-application and integration traffic between two networks as if they were directly wired together.

Key takeaways

• S2S tunnels use IPsec or GRE to connect a Versa gateway to a peer.
• Peers include data centers, cloud VPCs/VNets, and third-party devices.
• BGP with redundant tunnels is recommended over static routes for HA.
• Concerto supports IPsec, GRE, EoGRE, and Geneve tunnel interfaces.
• VOS cloud gateways stay passive; the branch always initiates the tunnel.

On this page: Why it matters · How it works · Types · Site-to-site tunnels & Versa · FAQ

Why are site-to-site tunnels important?

Most enterprise traffic still needs to reach somewhere that isn’t the SD-WAN fabric itself: a data center hosting legacy applications, a cloud VPC running production workloads, or a security partner’s cloud like Zscaler. Private circuits to every one of those destinations don’t scale; site-to-site tunnels give the same private, encrypted reachability over ordinary internet transport, without requiring a dedicated client on every user’s device the way remote-access VPN does.

Because a site-to-site tunnel is often the only path to a critical resource, how it fails matters as much as how it connects. A single static route has no way to detect a silent failure quickly; pairing redundant tunnels with BGP and BFD reroutes around a dead path in seconds, and a second tunnel to a geographically separate gateway protects against a regional outage on the peer side, not just the link.

What is a site-to-site tunnel?

A site-to-site tunnel is configured as a virtual tunnel interface that encapsulates traffic using a point-to-point protocol – most commonly IPsec, which authenticates and encrypts the traffic, or GRE, which encapsulates it without encryption of its own. The tunnel connects a VOS CPE device (physical or cloud-based) to a peer: a cloud-managed service or a third-party device that supports the same protocol.

Two configuration models exist depending on the platform. In Versa Director, tunnels are defined in a Workflows template’s Tunnels tab and then associated with a device. In Concerto, a site-to-site tunnel is added directly as a network interface, under a category of Site-to-Site Tunnel or Subtenant Site-to-Site Tunnel. Tunnels can also be route-based, where the routing table (static or BGP) selects which tunnel carries traffic, or policy-based, where explicit source/destination/port rules select the tunnel – the latter needed for some third-party peers that don’t support route-based configuration.

Types of site-to-site tunnels

Concerto’s tunnel interfaces support four encapsulation sub-categories: IPsec (encrypted, the default), GRE, EoGRE (Ethernet over GRE, for residential-gateway mobility services), and Geneve (Layer 2 frames encapsulated in UDP). Director’s Workflows model instead organizes tunnels by named peer type: AWS Transit Gateway (IPsec or GRE, Director-automated on the AWS side), Azure Virtual WAN (IPsec), Zscaler (IPsec or GRE, two tunnels required for redundancy), a Director-managed tunnel between a provider and a tenant Versa Director (extending SaaS on-ramps, Cloud Service Gateways, and Titan hubs to a tenant), and Others, for generic third-party IPsec peers such as Cisco, Juniper, or Palo Alto devices.

Site-to-site tunnels & Versa

Configuring a site-to-site tunnel in Director means building it into a Workflows template’s Tunnels tab, choosing a peer type, tunnel protocol, WAN/LAN network, and LAN VRF, then associating the template with a device; peer-specific fields cover BGP AS numbers, PSKs, and NAT addressing. In Concerto, the same result comes from adding a Site-to-Site Tunnel interface directly under Network Interfaces, configuring IKE/IPsec parameters, and choosing route-based or policy-based tunnel type.

Versa’s SD-WAN and SSE integration guidance walks through deploying site-to-site tunnels from a VOS branch to a VOS Cloud Gateway (VCG) – the SSE enforcement point – across single- and dual-CPE, single- and dual-WAN topologies. VOS VCGs run IKE in passive mode by design, so the branch always initiates the tunnel. BGP combined with BFD is the recommended failover mechanism over redundant tunnels, and a second tunnel to a geographically separate VCG adds resilience against a regional outage.

Frequently asked questions

What is the difference between an IPsec and a GRE site-to-site tunnel?

IPsec authenticates and encrypts the tunnel’s traffic; GRE only encapsulates it, with no encryption of its own. Some peer types, like AWS Transit Gateway and Zscaler, support either protocol, and GRE is sometimes paired with a separate IPsec tunnel for protected transport.

Should a site-to-site tunnel use static routing or BGP?

BGP, combined with BFD, is recommended whenever redundant tunnels exist, because it detects a failed path and reroutes automatically, typically within 15–18 seconds by default. Static routing works for a single tunnel but cannot fail over as gracefully across multiple paths.

What peer types does Versa support for site-to-site tunnels?

Director’s Workflows model supports AWS Transit Gateway, Azure Virtual WAN, Zscaler, a Director-managed peer (provider Director to tenant Director), and a generic Others type for third-party IPsec devices like Cisco, Juniper, or Palo Alto. Concerto instead organizes tunnels by IPsec, GRE, EoGRE, or Geneve.

What is the difference between a route-based and a policy-based tunnel?

A route-based tunnel lets the routing table – static or BGP – decide which tunnel carries traffic. A policy-based tunnel instead matches traffic against explicit source, destination, and port rules. Policy-based configuration is required for some legacy third-party peers, such as older Cisco ASA devices.

Why doesn’t a VOS Cloud Gateway ever initiate a site-to-site tunnel?

VOS Cloud Gateways operate in IKE passive mode by design, so they wait for the branch to start the IPsec negotiation rather than initiating it themselves. The VOS branch must not be configured in passive mode too, or neither side will ever bring the tunnel up.

More on site-to-site tunnels

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about site-to-site tunnels, these are worth looking at next.