radvd RAs get out of sync with tracked 6rd interface addresses

[jfieber]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• [x] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [x] I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Describe the bug

Following on from this forum message which requested a github ticket for a suspected missing 6RD/6to4 event to reconfigure clients.

The short version: With an IPv6 prefix coming from a 6rd WAN interface, and LAN interfaces IPv6 configured to track the WAN interface, radvd needs manual intervention after router boot or a WAN address change in order to properly advertise the prefix on the LAN interfaces.

This may be the same thing as #5198, involving the same ISP, but in that case the reporter just moved to 3rd party IPv6 solution instead of solving the 6rd problem.

To Reproduce

Version: OPNsense 24.7.7-amd64

WAN interface configuration:

• IPv4: PPPoE, over vlan interface (because the ISP requires tagged frames), on hardware interface igc1
• IPv6: 6rd Tunnel

Assorted LAN interfaces IPv6 config:

• Track WAN interface
• Also a static ULA address (via Virtual IPs config)

General radvd config:

• Router Advertisements: Unmanaged
• Router Priority: Normal
• Source Address: Automatic
• Advertise Default Gateway: yes
• Advertise Routes: one custom ULA /48 prefix defined

Expected RA content on LAN interfaces:

• Dynamic GUA prefix from 6rd WAN tunnel
• Static ULA prefix from statically assigned IP
• One Custom ULA /48 prefix
• DNS server & search options

In all cases, the RA content has the expected values for last three items. The GUA from the WAN interface is the problem.

Capturing the unsolicited RAs on a LAN interface (via wireshark), starting from router boot shows how things go wrong (times in seconds relative to the previous RA packet)

Step1: Router boot, 4 RAs are issued

1. (0) Router lifetime = 1800, includes ULA and 6rd assigned prefix
2. (3.938289) Router lifetime = 0, includes ULA and 6rd assigned prefix
3. (0.007557) Router lifetime = 1800, includes only ULA prefix
4. (16.001452) Same as 3

The first RA is completely correct, but then it messes things up with 2 and 3.

Step 2: Manual radvd restart generates 3 RAs

1. (0) Router lifetime = 0, includes only ULA prefix
2. (0.002888) Router lifetime = 1800, includes ULA and 6rd assigned prefix
3. (16.002888) Same as 2

This manual intervention puts things right again.

Step 3: Reload WAN interface (from the Interfaces Overview)

Forcing a 6rd prefix change, because this ISP changes the prefix way too often, so this needs to behave correctly.

1. (0) Router lifetime = 0, includes ULA and 6rd assigned prefix
2. (0.009600) Router lifetime = 1800, includes only ULA prefix
3. (0.302180) Same as 2
4. (0.626825) Same as 2
5. (16.021727) Same as 2

The first RA discards the existing GUA, as would be expected if the prefix is changing, but never configures the new prefix.

Step 4: Manual radvd restart generates 3 RAs

1. (0) Router lifetime = 0, includes only ULA prefix
2. (0.009150) Router lifetime = 1800, includes ULA and 6rd assigned prefix
3. (16.017444) Same as 2

This manual intervention puts things right again.

---

Expected behavior

Not requiring manual restarts of radvd after the router reboots or the WAN interface address changes.

Describe alternatives you considered

A different ISP, but that would at least double my internet cost.

Screenshots

If applicable, add screenshots to help explain your problem.

Relevant log files

If applicable, information from log files supporting your claim.

Additional context

Add any other context about the problem here.

Environment

Software version used and hardware type if relevant, e.g.:

OPNsense 24.7.7-amd64

[devopsbarbarian]

Experiencing the same issue on 24.7.7-amd64 with 6rd. I need to manually restart radvd on OPNSense boot