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.
