Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 07 Nov 2025 18:39:20 +0000
From:      bugzilla-noreply@freebsd.org
To:        net@FreeBSD.org
Subject:   [Bug 290768] if_wg(4): handshake response has src and dst reverse
Message-ID:  <bug-290768-7501-QxYiO1VToM@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-290768-7501@https.bugs.freebsd.org/bugzilla/>
References:  <bug-290768-7501@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290768

Kyle Evans <kevans@freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |glebius@FreeBSD.org,
                   |                            |kevans@freebsd.org

--- Comment #4 from Kyle Evans <kevans@freebsd.org> ---
What's unclear is where CARP might be breaking an assumption that wg(4) is
making.  The source address is set with IP_SENDSRCADDR using udp_in[1] that we
got via udp_input() -> udp_append() -> tunnel func -- is that address wrong, or
is it getting dorked up on udp_send()?

Actually, I'm kind of eyeballing this commit[0] by glebius and wondering if
it's still a problem in 15.0 / main.  The wg(4) socket has previously been
sobind() to 0.0.0.0:<port>, which presumably takes us into this branch:

                if (inp->inp_laddr.s_addr == INADDR_ANY ||
                    inp->inp_lport == 0 ||
                    sin->sin_addr.s_addr == INADDR_ANY ||
                    sin->sin_addr.s_addr == INADDR_BROADCAST) {

So we call in_pcbconnect_setup(), which at a minimum probably clobbers our
specified src address in laddr.s_addr.  I don't know where CARP comes in or if
this ends up somehow clobbering in this precise way, but finding a way to test
this on main or stable/15 would be a good start towards working on a resolution
-- at the very least, if udp_send() wasn't wreaking some havoc there, we can
try a custom kernel with more diagnostics to figure out if it's messing up on
the way *in* to if_wg(4) or on the way out.

[0]
https://cgit.freebsd.org/src/commit/?id=69c05f42871406b4b2b2dac00a268d1da0cacd3e

-- 
You are receiving this mail because:
You are the assignee for the bug.


Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-290768-7501-QxYiO1VToM>