12

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?

Improve this question
7
  • 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
    Dec 16, 2013 at 18:20
  • 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".
    – Juliano
    Dec 16, 2013 at 19:09
  • @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
    Dec 17, 2013 at 0:02
  • 2
    Actually 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?
    – Juliano
    Dec 17, 2013 at 11:32
  • 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.
    – brandeded
    Dec 26, 2013 at 13:57

1 Answer 1

Reset to default
2

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]

Improve this answer
9
  • 1
    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
    Dec 19, 2013 at 12:52
  • 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
    Dec 19, 2013 at 12:56
  • 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.
    – brandeded
    Dec 20, 2013 at 17:36
  • 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.
    – brandeded
    Dec 20, 2013 at 17:40
  • 1
    Too 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!
    – brandeded
    Dec 24, 2013 at 3:04

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .