Why BGP Over a VPN Doesn't Control Your Underlay Path

Two sites peer BGP across an IPsec tunnel, learn each other's prefixes, and the diagram gets relabeled as path control. That label is where the confusion starts. The session does exchange reachability and it does apply policy, but it has no say in which provider, cable or router carries the encrypted packets. I have watched a team rebuild a working tunnel because they expected a BGP route change to move traffic onto a different fiber path the session could never influence.

What people assume a session buys

Most of the expectation comes from how a route change looks in a lab. You advertise a prefix over the tunnel, the far side installs it, and traffic moves. The same sequence happens on a router that does have traffic-engineering knobs, so the two get conflated. In the lab both sites usually share one access link, which is exactly why the difference never shows up there.

BGP is a reachability protocol. It tells a peer that you can deliver packets for a prefix and lets each side rank the offers it receives. That is genuinely useful across a tunnel: prefixes appear and disappear as sites come and go, and you can refuse a range without writing a static route on every edge device. What it does not do is put a provider's routers under your control.

The underlay carries the outer header. Your tunnel endpoint sends encrypted packets to a peer address, and the network between those two addresses forwards them using whatever routes its operators installed. Nothing in the BGP session changes that decision unless the same provider exposes a supported service that does.

What the session actually carries

The BGP speaker opens a TCP connection to port 179 on its peer, using the message formats and path attributes defined in RFC 4271. When the peer address lives inside the tunnel, the tunnel must be up and that address must be reachable before the session can even start. A completed IKE exchange is not a BGP neighbor. Route-based IPsec implementations only pass traffic once a matching tunnel route exists, and a policy-based one needs the peer address inside the protected selector. Getting this backwards produces the classic state where the tunnel is green and the session sits idle.

Once the session is up, policy decides what crosses it. Prefix lists, AS-path filters, a maximum-prefix ceiling and an explicit decision about default routes are the minimum, and they apply in both directions. A peer that accepts everything it receives can hand you a default route that quietly replaces local internet access. The two directions need separate lists, because what you accept from a peer and what you advertise to it are different decisions.

router bgp 65010
 neighbor 10.255.0.2 remote-as 65020
 address-family ipv4 unicast
  neighbor 10.255.0.2 prefix-list SITE-B-IN in
  neighbor 10.255.0.2 prefix-list SITE-B-OUT out
  neighbor 10.255.0.2 maximum-prefix 50

MTU bites next. The encapsulation shrinks the usable payload, so a large update can stall a session that looks perfectly established: the peer stays up, prefixes never arrive, and nothing obvious lands in the log. Clamp the TCP MSS on the tunnel interface, or set a tunnel MTU with room for the overhead, before you blame the filters.

Where the outer packets still go

Encrypted packets from one site to the other leave through whatever the local router selects for the peer's public address. If both sites buy transit from the same provider, cross the same metro facility, or one side sits behind carrier-grade NAT, the tunnel survives a provider failure only by accident. Counting tunnel icons in a monitoring tool tells you nothing about that.

Route selection and forwarding installation are also separate events. A prefix can sit in the BGP table as best and still be missing from the forwarding table, because the next hop is unresolvable or a more specific route wins. When someone reports that BGP learned the prefix but traffic does not flow, the useful question is whether it is installed and which next hop it points at.

The honest answer for a design review is a list of shared dependencies: access circuit, upstream provider, facility, and any stateful device in the return path. A session across the tunnel cannot remove a dependency it does not sit above.

Three decisions worth separating

When a design mixes these up, every outage conversation goes in circles. Keep them apart on paper first, then map each one to the device that actually enforces it.

Each row has a different owner. The first is a negotiation, the second is configuration on your devices, the third is mostly someone else's network. A change request naming the row it touches is far easier to approve than one that says BGP issue.

Failure modes worth planning for

Accepting a peer's summary route is the most common self-inflicted wound. Someone advertises a short aggregate to simplify the exchange, the far side accepts it, and traffic for ranges that are not behind the tunnel follows the tunnel and dies. Filter on exact expected prefixes, or use a prefix list with the right bounds, and never accept a bare aggregate because it makes the session look tidy.

Withdrawal timing is the second. Detection depends on hold timers, BFD if you enabled it, tunnel dead-peer detection, and how fast the far side stops advertising. Existing sessions are a separate problem: a new route may restore new connections while established TCP sessions keep using stale addresses, and stateful firewalls or NAT on the path may hold entries that no longer match. Put application recovery in the acceptance criteria instead of assuming a route change settles everything.

The third is return path asymmetry. Traffic can arrive over the tunnel and return over a provider link that was never meant to carry it, which shows up as one-way audio, failed handshakes, or a firewall dropping replies. Check both directions separately.

What to write into the contract, and how to verify it

Ask for the permitted prefixes in writing: who is authorized to originate each range, whether a default route is allowed, and which address families the tunnel service supports. RFC 8212 made explicit import and export policy the expectation for eBGP in implementations that follow it, so a peer still relying on implicit accept-anything behavior is worth questioning.

Then verify from the device rather than the diagram. Useful commands on FRR-style routers:

show bgp summary
show bgp ipv4 unicast 10.10.0.0/16
show bgp ipv4 unicast neighbors 10.255.0.2 advertised-routes
show ip route 10.10.0.0/16

Add two observations the routing table cannot give you. Capture on the outer interface to confirm which address the encapsulated packets actually target, for example tcpdump -ni eth0 udp port 51820 for a WireGuard tunnel, or an ESP filter for IPsec. Then trace toward the peer's public address and compare the hops with a trace inside the tunnel; if both follow the same provider chain, your redundancy lives in routing policy rather than in the network.

Finally, test a withdrawal on purpose. Bring the tunnel down during a maintenance window, record how long the prefix stays installed, what happens to existing sessions, and whether the far side falls back to a route you would actually accept. That exercise says more about the design than any diagram.

A route is not authorization. The prefixes you agree to exchange say nothing about which users may reach which service behind the tunnel, so keep authentication, permitted services and host firewalls exactly where they were. A reachable peer is also not permission for unlimited transit or for originating arbitrary addresses, and that kind of authority belongs in the contract as a commercial question, not in a BGP policy line.

• Name the prefixes each side may originate, and the ones it must never accept.
• Clamp MSS on the tunnel and confirm large updates actually arrive.
• List the shared underlay dependencies, not the tunnel count.
• Time a real withdrawal and note what the application does.