Hi all,

I've been looking for a high-performance VPN solution to build a
secure tunnel for a network application we're developing, and
WireGuard has been perfect for us.

I encountered a problem with the Windows version though [1]. It looks
like a bug to me, and I have a workaround (although a dubious one),
but I'd like to have your confirmation/opinion on how to fix it
better.

The context is simple. There are 2 machines:

- A laptop running Windows 10 with a Wi-fi interface
(192.168.1.223/24) and an Ethernet interface (192.168.71.1/24);

- another computer running Linux is connected to it through an
Ethernet cable (local address 192.168.71.2/24)

I set WireGuard up on both sides as usual (public keys, allowed IPs,
etc.). From the logs on the Windows side ("Logs" tab on the GUI), it
looks like the handshake is sent, but always fails. Running tcpdump on
the Linux side, one can immediately see what the issue consists in
(59874 and 53187 are the UDP ListenPorts of the two WireGuard
instances):

$ sudo tcpdump -n -i eno1 udp port 59874 or udp port 53187
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eno1, link-type EN10MB (Ethernet), capture size 262144 bytes
14:51:36.011169 IP 192.168.71.2.53187 > 192.168.71.1.59874: UDP, length 148
14:51:36.013757 IP 192.168.1.223.59874 > 192.168.71.2.53187: UDP, length 92
14:51:41.096679 IP 192.168.71.2.53187 > 192.168.71.1.59874: UDP, length 148
14:51:41.122407 IP 192.168.1.223.59874 > 192.168.71.2.53187: UDP, length 92

As you can see, the handshake request is sent from 192.168.71.2 (Linux
computer) to 192.168.71.1 (Ethernet interface of the Windows
computer), but the response has source address 192.168.1.223, which is
the address of the *Wi-fi* interface of the Windows computer, even
though the packet has correctly come out of its Ethernet interface!

I've tried looking into the issue in the source code, and I can see
that the Windows client continuously queries the routing table to see
which is the default route, and binds its v4/v6 sockets to the
corresponding interface.  This interface's address is what ends up
wrongly as the source address of the packets, as shown in the tcpdump
output above, since the default route goes through the Wi-fi to get to
the internet. Skipping this operation seems to solve the issue
completely (see attached patch).

The question is: am I missing something? If skipping the binding of
the socket to the interface solves this issue, what is the purpose of
this step at all? I'd love to produce a real fix for this issue and
contribute it upstream, but I'd rather know your view on this issue
first.

Keep up the good work. Thanks a lot,
-Sebastiano Barrera

[1] https://github.com/WireGuard/wireguard-windows