Cloud VPN Needs BGP: Why Other Routing Protocols Fail

The IPsec security association is up, the tunnel counters move, and traffic to the cloud prefix disappears. The operator then tries to enable OSPF on the customer router, expecting the neighbor to form, and nothing happens. The tunnel was never the missing piece: a managed cloud VPN exposes a defined routing contract, and on the large platforms that contract is BGP. Until a session exists and a prefix is accepted, the tunnel is just an encrypted path with no destinations behind it.

The tunnel is up and the route is missing

Phase 1 and phase 2 completing proves that the peers agree on protection, not that either side knows where to send traffic. Those are separate state machines with separate failure modes.

Ask three questions in order: was the prefix advertised, was it accepted by the peer, and was it installed for forwarding? A prefix that was advertised and filtered is a policy problem. A prefix that was never advertised is a session or configuration problem. A prefix that was accepted but not installed is a route selection problem, and each answer points at a different part of the configuration.

What the provider actually hands you

A managed VPN gateway is not an unrestricted router. The provider gives you a gateway with supported peer addresses, an autonomous-system setting, prefix limits, and a defined failure behavior. That surface is the product.

Google Cloud documents dynamic BGP routing for HA VPN, with Cloud Router learning peer routes and supplying eligible custom dynamic routes to the VPC. AWS Site-to-Site VPN documents a choice between static and dynamic routing, and describes BGP liveness checks as useful for tunnel failover while also supporting health checks for devices without BGP. Neither platform's behavior should be inferred from the other's product name.

The practical consequence is that you select the managed mode first, then read the supported knobs. A design that assumes an adjacency type the service does not offer is not a configuration problem to solve on the customer router.

Tunnel protection and reachability are separate jobs

IPsec protects the traffic that is selected for the tunnel. BGP supplies the reachability information that makes a prefix eligible. A working tunnel does not prove that the expected prefix was advertised, accepted, or installed.

Picture a branch that advertises 10.42.0.0/16 through two eligible tunnel paths. Remove one usable path and the routing choice can change without anyone editing each workload's route. Detection, route selection, and application recovery are not instantaneous, and they are not identical across deployments, so the failover test has to observe the whole sequence rather than the first packet that gets through.

When a cloud prefix is unreachable, check the session state and the learned routes before you touch crypto. An SA that is up with no route behind it is the most common version of this symptom.

Where OSPF assumptions break

OSPF, IS-IS, or another protocol inside an IPsec tunnel is entirely possible on a self-managed appliance, where you own both ends and the forwarding design. That fact says nothing about a managed service that only offers BGP as its dynamic routing mode.

If a proposed design needs an adjacency the service does not support, change the architecture deliberately. Options include a self-managed appliance in the VPC, static routing where the service supports it, or a different connectivity product. Configuring the protocol on the customer router alone cannot add a cloud-side peer that does not exist, and it will not make the prefix appear.

Do not carry one vendor's answer to another vendor's gateway. The same words, such as dynamic routing or tunnel failover, can describe different mechanisms and different limits.

Read the service requirement, then design

Before the first configuration line, write down the neighbor addresses, the autonomous-system numbers, the prefixes you will advertise and accept, the route limits, and the expected behavior when a tunnel fails. Those five items are the contract you are designing against.

Then verify in the same order: session established, prefix received, route present in the VPC route table, and a real flow to a service address. Repeat after a forced failover, because a session that re-establishes can come back with a different route set. If the design depends on sub-second convergence, measure it rather than assuming it.

Keep the service contract with the change record. When someone later asks why the tunnel cannot run OSPF, the answer is a product boundary, not a protocol limitation, and the record should say so.