new in-kernel wireguard and IPv6 endpoint

[Marek Zarychta]

W dniu 04.02.2021 o 05:25, Vasily Postnicov pisze:
> If the endpoint does not use the same WireGuard implementation from 
> FreeBSD, try to cherry-pick this commit first and then rebuild and 
> reinstall the kernel.
>
> https://cgit.freebsd.org/src/commit/?id=5aaea4b99e5cc724e97e24a68876e8768d3d8012 
> <https://cgit.freebsd.org/src/commit/?id=5aaea4b99e5cc724e97e24a68876e8768d3d8012>


Thank you for the reply, Vasily. Indeed, the second endpoint uses in Go 
implementation from ports (net/wireguard-go) and this version is capable 
to utilize IPv6 endpoints for the tunnels since a while (almost from the 
early beginning of the existence of the port). Thank you for the clue 
with cherry-picking the commit above, but my latest tests were done 
yesterday on 14-CURRENT already after this fix was committed.

The only thing I modified was touching the code in line 590 of file 
sys/dev/if_wg/module/module.c b/sys/dev/if_wg/module/module.c which is 
validating the endpoint length size. It always appeared to be 28 for 
IPv6 endpoints and 16 for legacy IP endpoints. Without this ugly hack, 
IPv6 endpoints were not accepted at all, but the code itself suggested 
that such an endpoint should be parsed if supplied in the correct form 
ie.: [IPv6_address]:port.

Perhaps the endpoint length is not correctly calculated for IPv6 sockets 
or there is an overflow which happens there?


>
> ср, 3 февр. 2021 г., 23:13 Marek Zarychta 
> <zarychtam at plan-b.pwste.edu.pl <mailto:zarychtam at plan-b.pwste.edu.pl>>:
>
>     W dniu 21.01.2021 o 20:03, Marek Zarychta pisze:
>     > Dear subscribers,
>     >
>     > please let me know if is it possible to use IPv6 addressed endpoint
>     > for the tunnel? I have tried to specify the address enclosed in []
>     > followed by the port number, for example: [2001:db8:0:1::1]:54333,
>     > have tried without it: 2001:db8:0:1::1:54333. I have also tried to
>     > specify it with prefix length, like this one:
>     > [2001:db8:0:1::1]/128:54333, but neither works.
>     >
>     > I got only some errors:
>     >
>     > matchaddr failed
>     > peer not found - dropping 0xfffff802099b6700
>     > wg0: wg_peer_add bad length for endpoint 28
>     >
>     > Is it possible to utilize IPv6 address as an endpoint for the
>     tunnel
>     > with this implementation?
>     >
>     >
>     There was not much feedback on the mailing list, so I changed the
>     code a
>     bit to not validate endpoint length so strictly and check if IPv6
>     address as endpoint is supported. This resulted in a partial success.
>     The handshake over IPv6 looks like established from the endpoint (as
>     it's reported by "wg show" command), but the tunnel is neither
>     capable
>     to carry any data nor keepalives are send.
>
>     Here is the handshake as sniffed on the endpoint:
>
>     00:00:00.000000 IP6 (hlim 57, next-header UDP (17) payload length:
>     156)
>     2001:db8:d47::c:100d.12345 > 2001:db8::b.55667: [udp sum ok] UDP,
>     length 148
>     00:00:00.002860 IP6 (hlim 64, next-header UDP (17) payload length:
>     100)
>     2001:db8::b.55667 > 2001:db8:d47::c:100d.12345: [bad udp cksum
>     0x6f50 ->
>     0x62b4!] UDP, length 92
>     00:00:00.000892 IP6 (hlim 57, next-header UDP (17) payload length:
>     120)
>     2001:db8:d47::c:100d.12345 > 2001:db8::b.55667: [udp sum ok] UDP,
>     length 112
>
>     Perhaps the incompatibility with IPv6 should be mentioned at least in
>     just added wg(4) manual page[1]?
>
>     [1] https://cgit.freebsd.org/src/commit/?id=e59d9cb41284
>     <https://cgit.freebsd.org/src/commit/?id=e59d9cb41284>
>
-- 

Marek Zarychta