Development discussion of WireGuard
 help / color / Atom feed
* Wireguard over VPN broken on windows
@ 2020-06-21 10:17 Christopher Ng
  2020-06-22  8:23 ` Jason A. Donenfeld
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher Ng @ 2020-06-21 10:17 UTC (permalink / raw)
  To: wireguard

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Wireguard over VPN broken on windows
  2020-06-21 10:17 Wireguard over VPN broken on windows Christopher Ng
@ 2020-06-22  8:23 ` Jason A. Donenfeld
  2020-06-22 10:56   ` Christopher Ng
  0 siblings, 1 reply; 4+ messages in thread
From: Jason A. Donenfeld @ 2020-06-22  8:23 UTC (permalink / raw)
  To: Christopher Ng; +Cc: WireGuard mailing list

> 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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Wireguard over VPN broken on windows
  2020-06-22  8:23 ` Jason A. Donenfeld
@ 2020-06-22 10:56   ` Christopher Ng
  2020-06-22 13:15     ` Peter Whisker
  0 siblings, 1 reply; 4+ messages in thread
From: Christopher Ng @ 2020-06-22 10:56 UTC (permalink / raw)
  To: Jason A. Donenfeld; +Cc: WireGuard mailing list

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Wireguard over VPN broken on windows
  2020-06-22 10:56   ` Christopher Ng
@ 2020-06-22 13:15     ` Peter Whisker
  0 siblings, 0 replies; 4+ messages in thread
From: Peter Whisker @ 2020-06-22 13:15 UTC (permalink / raw)
  To: wireguard

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.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, back to index

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-21 10:17 Wireguard over VPN broken on windows Christopher Ng
2020-06-22  8:23 ` Jason A. Donenfeld
2020-06-22 10:56   ` Christopher Ng
2020-06-22 13:15     ` Peter Whisker

Development discussion of WireGuard

Archives are clonable: git clone --mirror http://inbox.vuxu.org/wireguard

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.wireguard


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git