0
To connect to my client’s corporate network, I have been using the Cisco AnyConnect Secure Mobility Client, and this works fine but does not seem to allow me to use split tunneling (despite the fact that the VPN itself, according to the app’s Statistics tab, has Tunnel Mode (IPv4): Split Include, which to my understanding should mean I can). (Yes, I understand why split tunneling can be dangerous, but the VPN’s lockdown is interfering with my work and my client’s IT department is uninterested in making exceptions for a contractor—and like I said, the configuration seems to allow it.)
Trying to find a way to get split tunneling to work, I’ve installed OpenConnect instead, and that connects just fine—it accepts my credentials, I see the company’s “banner” message in the log, it works. But none of the destinations that I can access only through the VPN work.
I suspect the problem is with the routes. Both AnyConnect and OpenConnect add a number of routes to particular network destinations (the same ones), but have different values for Gateway and Interface. For an example,
AnyConnect
===========================================================================
Interface List
14...00 05 9a 3c 7a 00 ......Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
[...]
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.151 35
[...]
a.b.c.x 255.255.255.255 On-link a.b.c.d 2
a.b.c.y 255.255.255.255 On-link a.b.c.d 2
a.b.c.z 255.255.255.255 On-link a.b.c.d 2
[...]
192.168.1.1 255.255.255.255 On-link 192.168.1.151 36
[...]
224.0.0.0 240.0.0.0 On-link a.b.c.d 10000
[...]
255.255.255.255 255.255.255.255 On-link a.b.c.d 10000
OpenConnect
Interface List
[...]
63...00 ff 8d 2a 8a 57 ......TAP-Windows Adapter V9
[...]
===========================================================================
IPv4 Route Table
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.1.1 192.168.1.151 36
[...]
a.b.c.x 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
a.b.c.y 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
a.b.c.z 255.255.255.255 a.b.c.(d+1) 192.168.1.151 36
[...]
224.0.0.0 240.0.0.0 On-link a.b.c.d 291
[...]
255.255.255.255 255.255.255.255 On-link a.b.c.d 291
Aside from the 0.0.0.0
route, all of these routes are added by connecting to the VPN. For 0.0.0.0
, OpenConnect changes the Metric for route 0.0.0.0
to 36 (the values shown in the AnyConnect table are also the same as when I’m disconnected entirely). (For the record, AnyConnect also removes several IPv6 routes, which OpenConnect leaves alone—I don’t think this matters?)
To contrast the additions explicitly, AnyConnect uses “On-link” for the Gateway, while OpenConnect uses an IP address that is almost the same as what AnyConnect uses for Interface. For Interface, OpenConnect uses a private IP address. The IP addresses used for AnyConnect’s Interface and OpenConnect’s Gateway are in a range the client owns.
The metrics are also different—AnyConnect uses 2, which is higher priority than my 0.0.0.0
route (set to 35 when disconnected or connected via AnyConnect), while OpenConnect uses 36—and also changes my 0.0.0.0
route to use 36, so the priority is the same (all other routes on my system use a Metric higher than 36, for the record).
AnyConnect also adds a route for 192.168.1.1
, to 192.168.1.151
, which is what OpenConnect uses for the Interface. This is the only route that one has and the other lacks.
Both also add routes for 224.0.0.0
and 255.255.255.255
, but AnyConnect uses a Metric of 10000 (higher than any other route), while OpenConnect uses 291 (higher than any other addition but lower than some other, existing routes I had before connecting). Interestingly, OpenConnect uses the same Gateway and Interface that AnyConnect does for those two routes, despite using different values for all the other routes.
This is on a Windows 10 Pro x64 machine. Cisco AnyConnect is Version 4.5.03040; OpenConnect GUI is “Version 1.5.3 (32 bit) [...] Based on OpenConnect v7.08.”
I don’t really know that much about routing or VPNs; even coming by this much information took a lot of searching and reading. I didn’t even know the term “split tunneling” before starting this. A lot of the information out there is outdated, too—Windows 10 doesn’t offer a “Use default gateway on remote network” option to uncheck as a lot of other answers here and elsewhere recommend for split tunneling under AnyConnect. I don’t know if there are other pertinent details I can provide, but I’m certainly happy to if anything else is needed. Obviously, I’ve been trying to mask my client’s IP addresses, but I don’t think the specific address should matter much here (I don’t know that there’s any reason to mask them either, but it’s not my information to share so I’m not).
The "default gateway" option is found in the native Windows VPN client settings (e.g. for PPTP or IKEv2) -- it doesn't apply to third-party VPN apps. – user1686 – 2020-02-04T15:51:39.533
@user1686 In older versions of Windows, it was apparently found in the TCP/IP settings of the connection itself, and could be applied to AnyConnect and fix the split tunnel issue. Numerous discussions here and elsewhere describe this. – KRyan – 2020-02-04T16:26:38.070
Not quite -- Windows actually has two versions of the same "TCP/IP settings" dialog, and it doesn't depend on the OS version at all. Instead, you get one kind when configuring an Ethernet-like adapter (this includes Wi-Fi as well as the virtual AnyConnect or OpenVPN adapters), but you get a different kind when configuring a dialup-like adapter (this includes built-in PPTP and L2TP/IPsec VPNs). The setting you mention is still there in Windows 10, it's just that it only exists in the second kind. – user1686 – 2020-02-04T17:13:17.223
@user1686 Fair enough; despite having read probably a dozen answers suggesting that checkbox—and people saying it was missing—you’re the first to explain that distinction. There are definitely (many) claims out there that it can work for AnyConnect; maybe it was an older version of that rather than of Windows? Or a great many people were simply wrong. I do not know. – KRyan – 2020-02-04T17:34:11.777
Then it could be that the AnyConnect driver used to(?) mark the adapter as a different type somehow. I'll have to check later. – user1686 – 2020-02-04T17:57:08.640