On Windows: Wrong source IP address

Sebastiano Barrera sebastiano.barrera at gmail.com
Wed Sep 4 15:09:59 CEST 2019

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

The context is simple. There are 2 machines:

- A laptop running Windows 10 with a Wi-fi interface
( and an Ethernet interface (;

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

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

$ 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 > UDP, length 148
14:51:36.013757 IP > UDP, length 92
14:51:41.096679 IP > UDP, length 148
14:51:41.122407 IP > UDP, length 92

As you can see, the handshake request is sent from (Linux
computer) to (Ethernet interface of the Windows
computer), but the response has source address, 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

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

[1] https://github.com/WireGuard/wireguard-windows
-------------- next part --------------
A non-text attachment was scrubbed...
Name: disable_binding.patch
Type: application/octet-stream
Size: 1754 bytes
Desc: not available
URL: <http://lists.zx2c4.com/pipermail/wireguard/attachments/20190904/2bed3c65/attachment.obj>

More information about the WireGuard mailing list