Problems with Windows client over PulseSecure VPN

Peter Whisker peter.whisker at gmail.com
Wed Jan 13 15:13:19 UTC 2021


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.


More information about the WireGuard mailing list