[Bug 290768] if_wg(4): handshake response has src and dst reverse

[email protected]
Newsgroups gmane.os.freebsd.devel.net
Message-ID <[email protected]/bugzilla/>
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290768

Kyle Evans <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[email protected],
                   |                            |[email protected]

--- Comment #4 from Kyle Evans <[email protected]> ---
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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.