Wireguard Windows keeps using lower priority interface (wifi) when a higher priority interface (wired) becomes available

Wireguard Windows keeps using lower priority interface (wifi) when a higher priority interface (wired) becomes available

[Dave Mifsud]

We are implementing Wireguard as a VPN solution for our network on
Windows 10/11 clients. One issue we have encountered is that Wireguard
VPN traffic keeps transiting the wifi interface, even when wired
becomes available.

We have tested the same Windows device without Wireguard, and when the
wired connection becomes available, traffic switches to the wired
connection.

Unfortunately users do not realise this, and at times are located in
an area where wifi connectivity is not optimal.

Has anyone come across this issue? Can anything be done, apart from
creating a trigger in windows such that whenever a wired connection
becomes available Wireguard is restarted? We would like to avoid this,
as the solution seems too drastic.

Dave

Re: Wireguard Windows keeps using lower priority interface (wifi) when a higher priority interface (wired) becomes available

[Daniel Gröber]

Hi Dave,

On Thu, Oct 19, 2023 at 09:43:46AM +0200, Dave Mifsud wrote:
> Has anyone come across this issue? Can anything be done, apart from
> creating a trigger in windows such that whenever a wired connection
> becomes available Wireguard is restarted? We would like to avoid this,
> as the solution seems too drastic.

Sounds very similar to the behaviour I'm seeing with the Linux kernel
implementation. This is intentional as best I can tell, it's called "sticky
sockets".

See my lament thread "Wg source address is too sticky for multihomed
systems aka multiple endpoints redux"
https://lists.zx2c4.com/pipermail/wireguard/2023-July/008111.html

It's safe to say many people have run into this and I think will continue
to do so as multihoming (aka wifi+ethernet) is pervasive.

I have a workaround for this on Linux without breaking connectivity by
completely restarting the interface. It involves setting fwmark which
invalidates the cached route, not sure a comparable codepath exists in the
windows impl.

--Daniel