dpinger picks "default" IPv6 bind address for multipoint WireGuard tunnel
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
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