Ways to circumvent Cisco AnyConnect VPN Routing Table

In order to access the enterprise intranet remotely, we have to use the Cisco AnyConnect VPN client. We're allowed to install it on any personal machines, and they provide downloads and instructions for Windows, Mac and Linux. This works fine except for the routing table configurations they provide.

They route everything except the 10.0.0.0/8 and 172.0.0.0/8 (that's not a typo) subnets over the VPN. This is baked into the client and I can't find a way to change it. All I really need are ports 80, 443 and 22 for a small Class C subnet routed through the VPN tunnel.

Is there a way to change the routing table configurations? Barring that, would it be possible to setup a linux VM with an HTTP/S proxy and SSH that route over the VPN tunnel?

Barring that, would it be possible to setup a linux VM with an HTTP/S proxy and SSH that route over the VPN tunnel?

I can only address the first part of that question, "would it be possible to setup a linux VM ... that route over the VPN tunnel". Yes, you can.

If you make use of an alternate client, openconnect, split tunneling is fairly straightforward. You'd also need vpnc-script in order to make the process of setting up routes a little easier (although you can always manually go back afterwards and use the ip route commands).

Then you'd follow the instructions in this github gist. Essentially,

sudo openconnect <corporate-vpn-endpoint> \
     -m 1290 \
     -u <your-vpn-user> \
     --servercert sha256:<0446a7EXAMPLE8901278394> \
     -s 'vpn-slice <10.10.0.0/14>'

where 10.10.0.0/14 should be the subnet you'd like to have pass through the VPN.

Your routes after this command will end up looking something like

# ip route
default via 10.1.1.1 dev wlp4s0 proto static metric 600
10.1.1.0/24 dev wlp4s0 proto kernel scope link src 10.1.1.50 metric 600
10.10.0.0/14 dev tun0 scope link
10.10.0.0/14 dev tun0 scope link metric 6
180.10.34.165 dev tun0 scope link
180.10.34.165 dev tun0 scope link metric 6

Note that most traffic is passing over the default route, while the subnet specified in the command (10.10.0.0/14) is passing over the tunnel.

It doesn't allow split tunnels. This is a security feature of the VPN software. Allowing split tunnels puts the business network at risk because this can be used to bypass the firewall. The software actively monitors host routing changes, and it will reverse changes made to the host routing.

Since the routing has to allow for TCP packets towards the VPN server, you can use clever NAT rules and software like SSLH to multiplex additional streams (such as SSH with tunnels) on this by-design hole.

See details here for step-by-step instructions and how/why this works