kern/59097: wg(4) returning packets with wrong source address

[Christoph Badura <bad%bsd.de@localhost>]

>Number:         59097
>Category:       kern
>Synopsis:       wg(4) replies to peers may not come from the peer's endpoint address
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 24 12:25:00 +0000 2025
>Originator:     Christoph Badura
>Release:        current, NetBSD 10.0
>Organization:
Peoples Front Against Replying From The Wrong Address
	<organization of PR author (multiple lines)>
>Environment:
	<The following information is extracted from your kernel. Please>
	<append output of "ldd", "ident" where relevant (multiple lines).>
System: NetBSD quietly-confident 10.0 NetBSD 10.0 (XEN3_DOM0) #0: Thu Mar 28 08:33:33 UTC 2024 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/xen/compile/XEN3_DOM0 amd64
Architecture: x86_64
Machine: amd64
>Description:
	<precise description of the problem (multiple lines)>
Outgoing packets from wg(4) do not have the source address set to the
addresss that the client's endpoint is configured to.

Rather they leave it to the network stack to select an appropriate source
address.

On interfaces with more than one useable address configured, this seems to
select the first address in the appropriate family.

This breaks wg(4) clients behind statefull NAT at least, when the
configured endpoint address is not the first address of the outgoing
interface.

>How-To-Repeat:
	<code/input/activities to reproduce the problem (multiple lines)>

I've noticed this on a system that had:

$ cat /etc/ifconfig.wm0
inet xx.xx.xx.204/29 
inet alias xx.xx.xx.202/29 
inet alias xx.xx.xx.203/29 
up

$ ifconfig wm0
wm0: flags=0x8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
	inet6 fe80::5eba:2cff:fe25:e332%wm0/64 flags 0 scopeid 0x1
	inet xx.xx.xx.204/29 broadcast 85.88.27.207 flags 0
	inet xx.xx.xx.202/29 broadcast 85.88.27.207 flags 0
	inet xx.xx.xx.203/29 broadcast 85.88.27.207 flags 0

# tcpdump -ntp -i wm0 udp port 50281
IP yy.yy.yy.224.54311 > xx.xx.xx.202.50281: UDP, length 148
IP xx.xx.xx.204.50281 > yy.yy.yy.224.54311: UDP, length 92

>Fix:
	<how to correct or work around the problem, if known (multiple lines)>
Test please.
Yes please.

>Unformatted:
 	<Please check that the above is correct for the bug being reported,>
 	<and append source date of snapshot, if applicable (one line).>