Can't change routes with VPN Client

My VPN connection forces all internet traffic through the tunnel, and that's very slow. I want to be able to tunnel only certain IP addresses, and to do that at my side (client-side).

I'm connecting to a VPN with FortiSSL Client, the route table looks like this before a connection is established:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101     40
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.0.0    255.255.255.0         On-link     192.168.0.101    276
    192.168.0.101  255.255.255.255         On-link     192.168.0.101    276
    192.168.0.255  255.255.255.255         On-link     192.168.0.101    276
    192.168.119.0    255.255.255.0         On-link     192.168.119.1    276
    192.168.119.1  255.255.255.255         On-link     192.168.119.1    276
  192.168.119.255  255.255.255.255         On-link     192.168.119.1    276
    192.168.221.0    255.255.255.0         On-link     192.168.221.1    276
    192.168.221.1  255.255.255.255         On-link     192.168.221.1    276
  192.168.221.255  255.255.255.255         On-link     192.168.221.1    276
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link     192.168.119.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.221.1    276
        224.0.0.0        240.0.0.0         On-link     192.168.0.101    276
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link     192.168.119.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.221.1    276
  255.255.255.255  255.255.255.255         On-link     192.168.0.101    276

After connecting it looks like this:

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.0.1    192.168.0.101   4265
          0.0.0.0          0.0.0.0         On-link        172.16.0.1     21
        127.0.0.0        255.0.0.0         On-link         127.0.0.1   4531
        127.0.0.1  255.255.255.255         On-link         127.0.0.1   4531
  127.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
       172.16.0.1  255.255.255.255         On-link        172.16.0.1    276
      192.168.0.0    255.255.255.0         On-link     192.168.0.101   4501
    192.168.0.101  255.255.255.255         On-link     192.168.0.101   4501
    192.168.0.255  255.255.255.255         On-link     192.168.0.101   4501
    192.168.119.0    255.255.255.0         On-link     192.168.119.1   4501
    192.168.119.1  255.255.255.255         On-link     192.168.119.1   4501
  192.168.119.255  255.255.255.255         On-link     192.168.119.1   4501
    192.168.221.0    255.255.255.0         On-link     192.168.221.1   4501
    192.168.221.1  255.255.255.255         On-link     192.168.221.1   4501
  192.168.221.255  255.255.255.255         On-link     192.168.221.1   4501
   200.250.246.74  255.255.255.255      192.168.0.1    192.168.0.101   4245
        224.0.0.0        240.0.0.0         On-link         127.0.0.1   4531
        224.0.0.0        240.0.0.0         On-link     192.168.119.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.221.1   4502
        224.0.0.0        240.0.0.0         On-link     192.168.0.101   4502
        224.0.0.0        240.0.0.0         On-link        172.16.0.1     21
  255.255.255.255  255.255.255.255         On-link         127.0.0.1   4531
  255.255.255.255  255.255.255.255         On-link     192.168.119.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.221.1   4501
  255.255.255.255  255.255.255.255         On-link     192.168.0.101   4501
  255.255.255.255  255.255.255.255         On-link        172.16.0.1    276

The VPN client puts a catch-all route with a lower metric than all of my other routes and this routes all internet traffic through the tunnel. I tried changing my default internet route's metric to a lower value:

C:\Windows\system32>route change 0.0.0.0 mask 0.0.0.0 192.168.0.1 metric 10 if 13
OK!

But nothing changed.

Then I tried deleting the VPN's "catch-all" route, the one with metric 21 above:

C:\Windows\system32>route delete 0.0.0.0 mask 0.0.0.0 if 50
OK!

And it broke everything:

C:\Windows\system32>ping 8.8.8.8

Pinging 8.8.8.8 with 32 bytes of data:
PING: transmit failed. General failure.

I tried changing the metric on the adapters as well, but the FortiSSL Client overrides all settings when it connects, so it didn't help.

The fix must come from my side, as the folk on the other side take days to respond.

I'm running Windows 7 x64 if that helps.

-- UPDATE (2013-12-24) --

Thanks to mbrownnyc's tip, I examined the issue with Rohitab and found out FortiSSL Client watches the routes table with the NotifyRouteChange IP Helper API call.

I set a breakpoint before NotifyRouteChange calls and used the option "Skip Call" to sucessfully prevent FortiSSL from resetting route metrics, and I now have:

Routes with metrics favoring my Wifi adapter

Yet when I run tracert my route still goes out through the VPN:

C:\Windows\system32>tracert www.google.com

Tracing route to www.google.com [173.194.118.83]
over a maximum of 30 hops:

  1    45 ms    47 ms    45 ms  Jurema [172.16.0.1]

Is there any aspect of windows networking I'm not aware of that can favor a certain route even if route print's metrics say otherwise?

Juliano

Posted 2013-12-16T17:13:28.203

Reputation: 290

Juliano, were you able to use the Rohitab tool to get this working? I have the same issue, and am trying to use the API Monitor, but cannot get to the screen you show. And is your issue solved? – Daniel Williams – 2017-08-31T04:39:44.193

@DanielWilliams couldn't solve it. Last progress I made is what's on the update in the question. Rohitab helped me prevent FortiSSL from undoing my route changes, but they never took effect. I was never sure if FortiSSL was doing something else behind the scenes to prevent my routes from taking effect, or if I was misunderstanding some networking concept while setting them up. – Juliano – 2017-09-01T05:00:32.233

Isn't it kind of the point for your VPN client to enforce that policy? The company probably has a security policy that requires you to not use split-tunneling, and circumventing that policy would be a security risk. – Ryan Ries – 2013-12-16T18:20:37.620

Quite the contrary. I now have access to this company's partners' IP-restricted webservices, since my web traffic goes out through their internet IP address. It's a very a lazy configuration on their part, as in "I'll tunnel everything through the VPN so I'll never have to add another IP or subnet to the route table". – None – 2013-12-16T19:09:49.210

@Juliano The point of avoiding split tunneling is to prevent users from coming in one tunnel and then having access to the data on the other tunnel. I would expect you to have the same access to the network you are tunneling to, that you would have if you were on the network. However, you don't want to use a split tunnel to grant that access to the world. – BillThor – 2013-12-17T00:02:01.023

2Actually if I were on that network I'd be able to setup my routes and metrics to give priority to the internet connection I desired (3g/4g ie.). I'd have that option because I wouldn't be subject to a ridiculously restrictive VPN client. Preventing split tunneling sounds OK in theory, but it limits me WAY more than if I was actually physically on that network. You guys are justifying a security implementation that's hurting me instead of helping me find a way out, which is the question at hand. How do I bypass this? – None – 2013-12-17T11:32:18.687

There is also interface metrics: ncpa.cpl> NIC properties> IP v4 stack entry properties> General tab/Advanced> Automatic Metric. Look there on both interfaces. Also see this blog post about multihomed Windows.

– mbrownnyc – 2013-12-26T13:57:40.923

Note that I am not using regular networking notation for addressing here (such as CIDR or even host/mask notation, as not to confuse the asker).

Instead of deleting your "default gateway" route (0.0.0.0 mask 0.0.0.0) so that your network stack has no idea where to send most packets, try to raise the metric of the VPN route below that of your default route (in this case 4265).

After connecting with the Fortigate client:

route change 0.0.0.0 mask 0.0.0.0 172.16.0.1 metric 4266 if N

Where N is the interface number for the fortissl interface returned at the beginning of route print.

The networking stack should treat this properly:

The route that "includes the destination addresses" will handle the packets (the route tells the network stack to send packets destined for this IP to this gateway for further routing).
All packets with a destination IP 172.16.*.* will be sent to the VPN; because the Windows network stack knows that if there's an address attached to an interface, then that interface is how you access other IPs on in that address range. I can get more explicit with the range if you post the "Subnet Mask" for the 172.16.0.1.

You must determine the IP addresses of resources you need access to over the VPN. You can do this easily by using nslookup [hostname of resource] when connected without having adjusted the routes.

[rant]

I have no problem with allowing split-tunneling over VPN, particularly because of the usage issue you cite. If your IT department considers split-tunneling a security mechanism, they need to rethink what they are doing:

VPN clients' access to resources should be isolated and heavily restricted as if they are being accessed via the Internet (because assets where you don't assert complete control present higher risk than assets where you can assert some).
They should integrate a network access control mechanism for VPN clients. This could allow them to enforce some policies on the client machines (such as "are anti-virus definitions up to date?", etc etc).
Consider using a rigid solution like the Fortigate SSL VPN Virtual Desktop (which is fairly easy to configure and free [me thinks] with the SSL VPN license).

[/rant]

mbrownnyc

Posted 2013-12-16T17:13:28.203

Reputation: 188

When I try to change the VPN's 0.0.0.0 route metric to a higher value than the internet route, FortiSSL Client sets my internet route to an even higher metric. – Juliano – 2013-12-19T12:52:34.273

There were two default gateway routes on the "after" table. The VPN's 0.0.0.0 and the wifi card's 0.0.0.0. I deleted the VPN's default gateway but left the wifi card's one, which should make it like it was before, but it broke everything. Either fortissl does something to the stack to prevent people from doing what I'm trying to do, or I'm doing it wrong. – Juliano – 2013-12-19T12:56:29.700

They are different interfaces, so you should be able to adjust the route costs of the routes separately. If the client watches the routing table, nothing is gonna help you there. The Cisco VPN client is configured with a PRF file that can be controlled on the system. The Fortigate SSL client is likely the same, either registry or file. I am just unsure where the setting would be. Poke around a bit and you might find something that allows you to configure the client. Additionally, the "support for split tunneling" is configure "server-side"/on the Fortigate unit. – mbrownnyc – 2013-12-20T17:36:48.580

Look within: HKEY_CURRENT_USER\Software\Fortinet\SslvpnClient. Tunnel should be interesting. Please post back what you find. Or answer and mark as a community wiki so that you can help others. – mbrownnyc – 2013-12-20T17:40:12.987

The client certainly watches the route table, enforcing the VPN interface's metric. It also prevents me from changing the interface metrics on the adapter. – Juliano – 2013-12-23T16:49:52.370

As for configurations, there is no .prf file, and registry show: http://i.imgur.com/d4zK3Hc.png and http://i.imgur.com/BEZBmkV.png nothing interesting.

– Juliano – 2013-12-23T16:57:02.663

1Too bad. Not sure of your situation, but is it worth putting in a request for split tunneling? Otherwise, looks like you're gonna have to hijack some API calls with something like rohitab or MSFT's detours. It might be a fun weekend project! – mbrownnyc – 2013-12-24T03:04:47.050

I did request split tunneling but as of yet got no response. Thanks for the tip on Rohitab tho, awesome tool, really helped me advance on the issue. – Juliano – 2013-12-24T18:15:39.703

Cool! Check these out as well: Using MSFT Detours to hook an API, and Working with the AppInit_DLLs registry value; the latter is still applicable to Windows 7.

– mbrownnyc – 2013-12-26T13:47:46.180

Can't change routes with VPN Client

Answers