Fwd: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

Hi

Thanks, maybe the powers-that-be would consider your change to be a fix 
and accept it into the next release? I guess by removing the default 
route I am causing the bind to fail as it doesn't know which interface 
to bind to which has the same result as removing the bind. The bit of 
code you removed certainly causes problems!

Thanks
Peter

On 15/01/2021 10:32, Christopher Ng wrote:
> ---------- Forwarded message ---------
> From: Christopher Ng <facboy at gmail.com>
> Date: Fri, 15 Jan 2021 at 09:46
> Subject: Re: Problems with Windows client over PulseSecure VPN
> To: Peter Whisker <peter.whisker at gmail.com>
>
>
> i fixed this in my local build by disabling the binding in
> defaultroutemonitor.go.  tbh i'm not sure what it's for, i found an
> old discussion (about linux) about not binding to only one interface,
> so i'm not sure why Windows binds to one interface.
>
> diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go
> index 6ee95129..12456332 100644
> --- a/tunnel/defaultroutemonitor.go
> +++ b/tunnel/defaultroutemonitor.go
> @@ -6,12 +6,10 @@
>   package tunnel
>
>   import (
> -       "log"
>          "sync"
>          "time"
>
>          "golang.org/x/sys/windows"
> -       "golang.zx2c4.com/wireguard/conn"
>          "golang.zx2c4.com/wireguard/device"
>          "golang.zx2c4.com/wireguard/tun"
>          "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg"
> @@ -50,18 +48,22 @@ func bindSocketRoute(family
> winipcfg.AddressFamily, device *device.Device, ourLU
>          }
>          *lastLUID = luid
>          *lastIndex = index
> -       blackhole := blackholeWhenLoop && index == 0
> -       bind, _ := device.Bind().(conn.BindSocketToInterface)
> -       if bind == nil {
> -               return nil
> -       }
> -       if family == windows.AF_INET {
> -               log.Printf("Binding v4 socket to interface %d
> (blackhole=%v)", index, blackhole)
> -               return bind.BindSocketToInterface4(index, blackhole)
> -       } else if family == windows.AF_INET6 {
> -               log.Printf("Binding v6 socket to interface %d
> (blackhole=%v)", index, blackhole)
> -               return bind.BindSocketToInterface6(index, blackhole)
> -       }
> +       // disable this because if my peers are on different
> interfaces...well i don't know how it can work.  i can't
> +       // bind the socket to only one of them
> +       /*
> +               blackhole := blackholeWhenLoop && index == 0
> +               bind, _ := device.Bind().(conn.BindSocketToInterface)
> +               if bind == nil {
> +                       return nil
> +               }
> +               if family == windows.AF_INET {
> +                       log.Printf("Binding v4 socket to interface %d
> (blackhole=%v)", index, blackhole)
> +                       return bind.BindSocketToInterface4(index, blackhole)
> +               } else if family == windows.AF_INET6 {
> +                       log.Printf("Binding v6 socket to interface %d
> (blackhole=%v)", index, blackhole)
> +                       return bind.BindSocketToInterface6(index, blackhole)
> +               }
> +       */
>          return nil
>   }
>
> On Wed, 13 Jan 2021 at 17:06, Peter Whisker <peter.whisker at gmail.com> wrote:
>> Hi
>>
>> I have managed to work around the issue caused by Wireguard sending
>> packets via default route interface even though the route to the peer is
>> over a different interface (the issue caused by IP_UNICAST_IF). My
>> Wireguard peer is down a corporate Pulse Secure tunnel.
>>
>> I use a PreUp and PostDown script as follows:
>>
>> PreUp
>> =====
>>
>> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do
>> if not defined ip set ip=%%a
>> route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1
>> route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1
>> route delete 0.0.0.0 mask 0.0.0.0
>>
>> PostDown
>> ========
>>
>> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do
>> if not defined ip set ip=%%a
>> route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1
>> route delete 0.0.0.0 mask 128.0.0.0
>> route delete 128.0.0.0 mask 128.0.0.0
>>
>> This replaces the /0 default route by two /1 routes before bringing up
>> the WireGuard interface. Traffic to the peer then gets sent down the
>> correct route (why is this different from having a default route?). When
>> the WireGuard instance is closed, it recreates the default route and
>> removes the two /1 routes.
>>
>> Is there a way this could be done better in the Wireguard executable (I
>> am currently using 0.3.4).
>>
>> Thanks
>>
>> Peter
>>
>> On 26/11/2020 13:11, Jason A. Donenfeld wrote:
>>>> Is PulseSecure not setting up a /0 route? If so, then this is a known
>>>> issue with the lack of policy routing on Windows.