Fwd: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

Hi

I built Wireguard with the change you made below and confirm it fixes 
the longstanding problem I had - I can now connect to a peer over the 
PulseSecure tunnel and even simultaneously connect to another peer over 
the default route (with the MultipleSimultaneousTunnels=1 registry entry).

Is there a reason this fix can not be adopted?

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.