Wireguard over VPN broken on windows

Wireguard over VPN broken on windows

[Christopher Ng]

I raised an issue on github which was closed, and issues seem to have
been disabled on github now so I can't respond there.

59e556f on wireguard-go breaks Wireguard working over OpenVPN on
windows.  It only ever worked in my private builds as there was no
public release of wireguard-windows that included  66ad537 (which
fixed a routing problem in wireguard-windows).  Now with
wireguard-windows 0.1.1 Wireguard over an OpenVPN tunnel no longer
works again.  I have triaged it with my own private builds of
wireguard-windows and 59e556f is where it starts breaking.

Re: Wireguard over VPN broken on windows

[Jason A. Donenfeld]

> 59e556f on wireguard-go breaks

59e556f fixes a regression, which never shipped in any release. There
is nothing here that "once worked and now doesn't." What you have in
mind has never worked.

We're currently using IP_UNICAST_IF on the wireguard socket, attaching
it to the default route. I'd much rather have something like Linux's
policy routing and suppress_prefixlen, but I don't know how to do that
(yet?) on Windows. If you have any ideas or want to do some research,
I'd certainly be very interested.

Re: Wireguard over VPN broken on windows

[Christopher Ng]

it worked for me on a local build, it never worked in any released version.

i've been playing around with a local build, if i comment out the
device.BindSocketToInterface calls in defaulltroutemonitor.go,
everything seems to work fine.  in a single config i have one peer on
an OpenVPN interface, and one on the default interface.  both are
connected, i can ping both peers over the wg interface.  why must the
socket be bound to a particular interface?  or perhaps i don't
understand what those calls do.



On Mon, 22 Jun 2020 at 09:23, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>
> > 59e556f on wireguard-go breaks
>
> 59e556f fixes a regression, which never shipped in any release. There
> is nothing here that "once worked and now doesn't." What you have in
> mind has never worked.
>
> We're currently using IP_UNICAST_IF on the wireguard socket, attaching
> it to the default route. I'd much rather have something like Linux's
> policy routing and suppress_prefixlen, but I don't know how to do that
> (yet?) on Windows. If you have any ideas or want to do some research,
> I'd certainly be very interested.

Re: Wireguard over VPN broken on windows

[Peter Whisker]

Hi

This has been a problem for me which I have only managed to overcome by 
using the Tunsafe client to connect over the VPN to my Linux Wireguard 
server.

I need to connect Wireguard over a PulseSecure SSLVPN. Wireguard 
attempts to connect but then gives up claiming to have received no 
handshakes. Tunsafe works fine with the identical configuration file. So 
it's not an insuperable problem!

Thanks

Peter

On 22/06/2020 11:56, Christopher Ng wrote:
> it worked for me on a local build, it never worked in any released version.
>
> i've been playing around with a local build, if i comment out the
> device.BindSocketToInterface calls in defaulltroutemonitor.go,
> everything seems to work fine.  in a single config i have one peer on
> an OpenVPN interface, and one on the default interface.  both are
> connected, i can ping both peers over the wg interface.  why must the
> socket be bound to a particular interface?  or perhaps i don't
> understand what those calls do.
>
>
>
> On Mon, 22 Jun 2020 at 09:23, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
>>> 59e556f on wireguard-go breaks
>> 59e556f fixes a regression, which never shipped in any release. There
>> is nothing here that "once worked and now doesn't." What you have in
>> mind has never worked.
>>
>> We're currently using IP_UNICAST_IF on the wireguard socket, attaching
>> it to the default route. I'd much rather have something like Linux's
>> policy routing and suppress_prefixlen, but I don't know how to do that
>> (yet?) on Windows. If you have any ideas or want to do some research,
>> I'd certainly be very interested.