Cloud VPN BGP addresses belong inside the tunnel, not on a NIC

Open the Cloud Router page for the VPN and a BGP session with an address in 169.254.0.0/16 stares back at you. The natural reaction is to put that address somewhere on the VM and wait for the session to come up. That reaction is wrong in a specific way: the pair belongs to the logical link the IPsec tunnel creates, not to the machine's ordinary network interface. Nothing you add to the NIC makes the tunnel carry BGP.

Follow the pair down the stack instead of adding it to the host.

Start where the console shows the pair

The session page lists a Cloud Router BGP address and a peer address, both link-local for an IPv4 HA VPN. Beside them are the outer gateway addresses that terminate the tunnels. Those are different objects: the link-local pair lives inside, and the gateway addresses live outside and must be routable before anything else works.

Write all three down before opening a configuration file, because mixing them up is the entire failure mode.

Walk down to the tunnel that carries it

The link-local pair means something only once an IPsec security association exists between the two gateways. On the Google side the HA VPN tunnels create it on the two interfaces; on your side it is whatever the peer negotiated. Check the data association first with swanctl --list-sas and note which tunnel is up on which interface, because a healthy BGP session over a dead tunnel is impossible and a dead tunnel with a hopeful configuration is routine.

The BGP packet is inner IP traffic. The outer network never sees it, so no switch needs both addresses on one VLAN.

Now configure the Linux peer to match

Choose the supported tunnel design and let it decide the inside addresses. With a route-based interface, the routing entry and the negotiated traffic selectors have to agree, because an interface name alone permits nothing. Point BIRD at the inside local address and the Cloud Router inside address, set the AS numbers from the session page, and allow TCP 179 within the protected path. Keep the route to the far outer address on the physical uplink so the tunnel does not capture its own transport.

A tunnel that routes itself is a loop with a handshake, and it will look like a firewall problem for an hour.

Check each stage in order, not the whole thing at once

Walk the stages: security association up, inside peer reachable from the tunnel address, BGP session established, prefixes accepted, then a workload prefix actually used. birdc show protocols answers the third question and nothing else, which is why people declare victory early.

An established neighbor does not promise that both sides advertised the prefixes you need, or that those routes were installed as preferred.

If the session is established and traffic still takes the wrong path, compare the advertised prefixes with what the routing table does with them. A more specific route elsewhere, or a preference favouring another path, gives you a working BGP session and no useful forwarding.

Stop before you apply this to Router Appliance

Network Connectivity Center Router Appliance is a different attachment model. Its Cloud Router peers use internal addresses from the VPC and subnet arrangement rather than the HA VPN link-local pair. If the real goal is BGP with a routing VM, follow that product interface requirements instead of copying a link-local session.

Link-local scope still means what it says. The logical tunnel supplies this adjacency, and it does not license routing arbitrary link-local destinations across the VPC.