dpinger picks "default" IPv6 bind address for multipoint WireGuard tunnel

[darkk]

Important notices

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

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• 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

I have several WireGuard peers acting as gateways and attached to the same interface, that's how ifconfig looks like:

wg1: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
	description: mgmth2h (opt3)
	options=80000<LINKSTATE>
	inet6 fd41:bb86:195d:b108:f19e:3751:1221:e117 prefixlen 64
	inet6 fd41:bb86:195d:4b74:f19e:3751:1221:e117 prefixlen 64
	inet6 fd41:bb86:195d:614f:f19e:3751:1221:e117 prefixlen 64
	groups: wg wireguard mgmt_wg
	nd6 options=1<PERFORMNUD>

I've set up Gateway monitoring towards fd41:bb86:195d:b108::1, fd41:bb86:195d:4b74::1 and fd41:bb86:195d::1. dpinger is bound to fd41:bb86:195d:b108:f19e:3751:1221:e117 for each of three instances, so two peers drop pings.

I'm not familiar with concept of aliases in FreeBSD, OPNsense, but none of these addresses is considered to be an alias by the loop over interfaces_addresses() in dpinger.inc:

... opnsense 99088 - [meta sequenceId="24"] /usr/local/etc/rc.routing_configure: TRACE addr: address=fd41:bb86:195d:b108:f19e:3751:1221:e117 family=inet6 alias=.
... opnsense 99088 - [meta sequenceId="25"] /usr/local/etc/rc.routing_configure: TRACE addr: address=fd41:bb86:195d:4b74:f19e:3751:1221:e117 family=inet6 alias=.
... opnsense 99088 - [meta sequenceId="26"] /usr/local/etc/rc.routing_configure: TRACE addr: address=fd41:bb86:195d:614f:f19e:3751:1221:e117 family=inet6 alias=.
... opnsense 99088 - [meta sequenceId="27"] /usr/local/etc/rc.routing_configure: Chose to bind wgmgmt_pakt on fd41:bb86:195d:b108:f19e:3751:1221:e117 since we could not find a proper match.

Expected behavior

I expect same-network IPv6 address to be used for bind() if it's available. That reflects ping behavior as well.

Describe alternatives you considered

One workaround is to use one interface per tunnel. It works and might be useful in some other cases.

Another workaround is to apply the following patch to mimic IPv4-like behavior:

--- _usr_local_etc_inc_plugins.inc.d_dpinger.inc	2024-09-30 21:19:26.000000000 +0300
+++ /usr/local/etc/inc/plugins.inc.d/dpinger.inc	2024-10-16 16:09:30.849799000 +0300
@@ -207,13 +207,11 @@
             if (is_linklocal($gateway['monitor'])) {
                 /* link local monitor needs a link local address for the "src" part */
                 list ($gwifip) = interfaces_scoped_address6($gateway['interface'], $ifconfig_details);
-            } else {
-                list ($gwifip) = interfaces_routed_address6($gateway['interface'], $ifconfig_details);
             }
 
             if (empty($gwifip) && is_ipaddrv6($gateway['gateway'])) {
                 foreach (interfaces_addresses($gateway['interface'], false, $ifconfig_details) as $addr) {
-                    if ($addr['family'] != 'inet6' || !$addr['alias']) {
+                    if ($addr['family'] != 'inet6') {
                         continue;
                     }
 
@@ -223,6 +221,13 @@
                         $gwifip = $addr['address'];
                         break;
                     }
+                }
+            }
+
+            if (empty($gwifip)) {
+                list ($gwifip) = interfaces_routed_address6($gateway['interface'], $ifconfig_details);
+                if (!empty($gwifip)) {
+                    log_msg(sprintf('Chose to bind %s on %s since we could not find a proper match.', $name, $gwifip));
                 }
             }
 

However, I have no idea if the patch makes sense to a person who is more familiar with FreeBSD and OPNsense :-)

Environment

OPNsense 24.7.5_3-amd64