BGP session down after upgrade to 2.9.0

mcfly9

Hi,

An upgrade to 2.9.0 brings bug #12760 to the surface as the upgraded FRR package seems to break when no IPv6 link-local exists on WireGuard site-to-site interfaces.

TL;DR, fix from the redmine bug:

Assign the WireGuard interface in pfSense (don't use the package interface config).
Create a Virtual IP for the WireGuard interface - enter an IPv6 link-local address like fe80::290:bff:fe7c:5fb%tun_wg0.
Add the LL address as an allowed IP in the peer config.

Redmine link: https://redmine.pfsense.org/issues/12760

For sake of completeness, here's what I was facing:

192.168.246.1: nexthop_set failed, local: 192.168.246.2:179 ... resetting connection - intf tun_wg0
bgp_connect_success: bgp_getsockname(): failed for peer 192.168.246.1
%NOTIFICATION: sent to neighbor 192.168.246.1 5/0 (Neighbor Events Error/Unspecific)

I have a WireGuard site-to-site tunnel and BGP session across it using the IPv4 address as neighbor definition.
Site-to-site links that only have IPv4 addresses survived the upgrade, links that have both IPv4 and IPv6 addresses are broken.
pfSense 2.9.0 seems to have upgraded frr from 9.1.2 to 10.6.1.

Claude traced it back to the following:

"In bgp_zebra.c, bgp_zebra_nexthop_set() returns v6_ll_avail. Even for an IPv4 session it insists on an fe80:: link-local on the peering interface when that neighbor is activated under address-family ipv6 unicast. Your WireGuard interfaces have a ULA but no link-local.
bgp_getsockname() fails → the TCP connection is torn down before the OPEN is sent (hence Opens sent: 0, only NOTIFICATIONs).

It works on IPv4-only links because of this check:

if (!peer_has_ipv6_configured || !direct)
        v6_ll_avail = true;

The important consequence: one missing fe80:: takes down the IPv4 session too, because nexthop_set runs per TCP connection, not per address family."

Adding a link-local address to the WireGuard interfaces on both sides restored the BGP session and IPv6 forwarding.