Wireguard: IPv6 within tunnel broken since update to 24.1.3_1

[schnipp]

Since upgrading to Opnsense 24.1.3_1 (from 24.1.2_1) IPv6 within the wireguard tunnel is not working anymore until restarting the service.

Configuration:

• Roadwarrior connection from Android to Opnsense via IPv6
• Static private IPv4 and IPv6 (ULA) address on the Smartphone
• Routing IPv4 and IPv6 internet traffic through the tunnel

Everything worked fine till the upgrade to the above version. After upgrading and performing reboot of the Opnsense, IPv6 traffic in the tunnel is not routed anymore. A packet dump shows that the traffic still arrives at the virtual wireguard interface (wgX). Thus, wireguard itself (IP addresses and allowed IP addresses) is correctly configured. But the firewall rules do not see any IPv6 packets (no ULA packets are visible in the firewall's live view even logging of all packets is enabled).

I did some checks:

• The firewall rule configuration look fine (even on console via 'pfctl -s rules')
• Routing table looks fine (even on console via 'netstat -rn')
• Output of 'wg' command on console look fine

The only weird entry in the wireguard I have found is:

Code Select Expand


2024-03-17T12:24:50 Error wireguard /usr/local/opnsense/scripts/Wireguard/wg-service-control.php: The command
   '/usr/sbin/arp -s '10.2.x.x' '00:1d:ec:xx:xx:xx'' returned exit code '1', the output was 'arp: cannot
   intuit interface index and type for 10.2.0.3'


The result of the arp command is clear. The related IP address belongs to an interface which is currently not active. But, I don't have a clue why the wireguard control script tries to create static arp entries on the opnsense (for a client which has no relation to wireguard). In my eyes, this looks like a bug, but possible not causal for the described problem.

Restarting the wireguard service after booting the machine for the specific interface solves the problem.


Does anybody has an idea how to track this down?

[schnipp]

Maybe, it looks similar to this one: #7148