Why outbound-only beats site-to-site VPN

Site-to-site VPN is the default answer when a vendor needs to reach a customer’s internal services. It has been the default since the late 1990s. There are good reasons it became the default and there are good reasons it is the wrong default for operator-to-customer connectivity in 2026.

This essay is the architectural case for replacing the default with outbound-only connectivity. Not “consider replacing.” Replace.

What S2S VPN actually does

A site-to-site VPN establishes an authenticated, encrypted tunnel between two networks. Each side typically runs a VPN concentrator (a hardware or virtual appliance) that terminates the tunnel. Traffic on either side addressed to the other network’s subnet is routed through the tunnel and delivered as if it had originated locally.

The model has a beautiful symmetry. Both networks see the other as if it were a different subnet of the same internal network. Most existing applications work without modification because they think they are talking to a local IP.

That symmetry is also the source of the problems.

The inbound problem

Both ends of a S2S VPN listen for inbound connections. The IKE negotiation, the IPSec ESP packets, the rekeying — all of it requires inbound listeners on the concentrators. The concentrators are exposed to the public internet on UDP/500 and UDP/4500 (or whatever your specific stack uses).

This means every S2S VPN deployment adds inbound attack surface to both networks. The attack surface is small, the protocols are well-tested, and in practice exploits against modern IKE/IPSec stacks are rare. But the exposure is real, and the customer’s security team has to account for it in their risk register, their threat model, and their continuous-monitoring configuration.

When the vendor says “we need a S2S VPN” the customer’s network team hears “we need to add an attack surface to our perimeter for one specific vendor.” That is what they are agreeing to. The decision to do so is appropriately slow and political.

The lateral-movement problem

Once a S2S VPN is up, the vendor’s network is one IP-routing decision away from the customer’s network. The vendor’s servers can reach the customer’s servers. By default, this reachability is broad — every IP in the vendor subnet can talk to every IP in the customer subnet. ACLs narrow this, but ACLs are configuration, and configuration drifts.

In practice, every S2S VPN deployment between vendor and customer is accompanied by a long ACL discussion. The result is usually overly broad in the first iteration (because the operational cost of being too narrow is concrete and the security cost of being too broad is hypothetical). Drift compounds over time.

This is how vendors end up in the customer’s incident-response postmortems even when the vendor is not the original incident vector — because once the attacker is on the customer network, the S2S tunnel is a path to related systems.

The credential-rotation problem

S2S VPNs use pre-shared keys or certificate-based authentication. Both require rotation. Both have meaningful rotation cost — the rotation involves coordinating between two network teams who do not work for the same company.

In practice, S2S VPN credentials get rotated rarely. The vendor and customer both know this and neither wants to admit it on the phone. The rotation policy is on paper. The rotation cadence is “when something forces it.”

The audit findings on this point are routine and embarrassing.

What outbound-only changes

Outbound-only connectivity flips the topology. The customer side opens a connection outbound to the vendor side. There are no inbound listeners on the customer side. There is no inbound attack surface added to the customer’s perimeter.

The vendor side does have inbound listeners — but the vendor is the operator and the inbound listener is for a known service running known code under the vendor’s operational control. The customer’s risk register does not gain an entry. The customer’s threat model is unchanged.

Lateral movement becomes constrained by the application protocol. The outbound connection is not a routed network path; it is an application-layer channel. The vendor cannot scan the customer’s subnet from the other end of the connection. The vendor can only do what the application protocol on top of the connection allows. Narrowing reachability is a code-review question, not an ACL drift question.

Credential rotation becomes operationally cheap. The customer-side component is a binary the vendor ships. Rotating credentials is rotating a config value the vendor controls and shipping a new build. The customer side does not need a coordinated maintenance window for a credential roll.

The objections, and the responses

The standard objections to outbound-only are the same three, and they have the same three responses.

“Outbound-only is just a NAT-traversal trick.” It is not. It is an architectural commitment to removing inbound exposure as a structural property of the deployment. The NAT-traversal mechanics are an implementation detail; the security property comes from the topology, not the firewall configuration.

“What about latency? Connection setup is slow.” The connection sets up once and stays up. Application requests over the established channel have the same latency as any other TCP-over-TLS connection. For workloads with sustained traffic, outbound-only and S2S VPN have indistinguishable performance.

“What about availability? If the vendor side goes down, we lose connectivity.” This is symmetric — the same is true of S2S VPN. The vendor-side service is a known component with known availability characteristics. If the vendor is the bottleneck, the customer chose the vendor. The right response is an SLA, not a different topology.

What this means in practice

If you are designing operator-to-customer connectivity for an AI or SaaS product, do not start with “the customer needs to open a tunnel to us.” Start with “we will ship a Client component that runs in the customer environment and opens an outbound connection.” Build everything else on top of that.

If you have an existing S2S VPN deployment with a customer and you are trying to evolve it, the migration path is straightforward: deploy an outbound-only Client alongside the VPN, cut over application traffic, then decommission the tunnel. The hardest part is convincing the customer’s network team that the change is worth their time. Show them the inbound exposure numbers from the existing tunnel. They will be on your side.

The architectural case for outbound-only is strong enough that it has become the modern default for new deployments at scale (Cloudflare Tunnel, Tailscale subnet routing in some configurations, BeyondCorp, the Ewii Hub-Client model). The remaining question is not whether to make the change. It is which outbound-only product fits your specific operational shape — and that is a question the comparison pages and the Architecture Review exist to answer.