<div dir="ltr">def gw Route's metric in Windows can be changed runtime.<br><div class="gmail_quote"><div dir="ltr">If you want to fix the def gw from vpn in windows 10 just go in NIC propriety of the vpn network interface, network, ipv4 -> Propriety, Advanced, Use default gateway, then apply :)<br><br><a href="https://goo.gl/Zj5ktL">https://goo.gl/Zj5ktL</a></div><div class="gmail-HOEnZb"><div class="gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">2018-01-11 9:35 GMT+01:00 Marian Kechlibar <span dir="ltr"><<a href="mailto:marian.kechlibar@circletech.net" target="_blank">marian.kechlibar@circletech.<wbr>net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
this is a description of a problem that I spent a better part of<br>
yesterday struggling with. I am sending a description of the problem and<br>
the solution for anyone who might be interested.<br>
<br>
I also have the feeling that this might be suited for the StrongSwan<br>
Wiki. Please let me know whether I should add it there.<br>
<br>
So.<br>
<br>
The symptoms<br>
------------<br>
Server: strongswan 5.5.3 on CentOS 7.<br>
Client: native Windows VPN client, Windows 7 or Windows 10.<br>
<br>
Upon connection, the client ignores the traffic selectors sent by the<br>
server. A "print route" command will reveal that they were not added to<br>
the routing table. But non-Windows clients (Linux, Android) are routing<br>
well, so the server is probably correctly set up.<br>
<br>
Setting log level of charon to 2 will reveal that the traffic selectors<br>
are indeed sent correctly.<br>
<br>
The cause<br>
---------<br>
Windows native VPN client ignores the traffic selectors unless your<br>
client IP address is from the same range. So if you get, say,<br>
10.105.107.31 and your local_ts is <a href="http://10.105.107.0/24" rel="noreferrer" target="_blank">10.105.107.0/24</a>, your routing will be<br>
OK, but if your local_ts is <a href="http://172.17.1.0/24" rel="noreferrer" target="_blank">172.17.1.0/24</a>, it will not.<br>
<br>
Whether this is a bug or a weird feature, I do not know. That is how<br>
things go with Microsoft.<br>
<br>
The solution<br>
------------<br>
AFAIK there is no way how to force the native client into acknowledging<br>
the traffic selectors sent by the server.<br>
<br>
All workarounds require Administrator privileges on the client Windows<br>
installation, at least for a few minutes.<br>
<br>
If your traffic selectors are dynamic, you are better off with another,<br>
non-native Windows client.<br>
<br>
If your traffic selectors are static, you can set up permanent routes on<br>
your system from Administrator's command line like this.<br>
<br>
First, you need to know the interface number of your VPN. Connect the<br>
VPN (even though the routing is bad) and run "route print". At the<br>
beginning of the output, list of all the interfaces is given. Each line<br>
represents one interface and begins with number of the interface. In my<br>
case, the VPN usually has something like 30.<br>
<br>
Disconnect the VPN and run the following command from your<br>
Administrator's command line:<br>
<br>
route -P add (range) mask (mask) (gateway) IF (interface number)<br>
<br>
This will create a permanent route tied to your VPN. After that, a<br>
regular Windows user will be able to connect the VPN with correct routing.<br>
<br>
On Windows 10, there is another solution using a PowerShell script. In<br>
case of interest, I can describe it as well.<br>
<br>
Best regards<br>
<span class="gmail-m_-3364648386972387864HOEnZb"><font color="#888888"><br>
Marian Kechlibar<br>
Prague, CZ<br>
</font></span></blockquote></div><br></div>
</div></div></div><br></div>