18

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?

2
  • I don't understand the problem you're trying to solve. Can you restate your question?
    – joeqwerty
    Jul 25, 2016 at 16:01
  • 2
    @joeqwerty : The VPN is pushing almost all traffic down the VPN tunnel unnecessarily. So any internet bound traffic is being pushed through the VPN tunnel and private network addresses that aren't valid on the intranet. This is a huge bottleneck since the VPN throughput is severely constrained. Jul 25, 2016 at 16:26

3 Answers 3

7

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.

4

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.

8
  • 5
    I disagree that a split tunnel puts them at risk. The Web Security Agent (local firewall) runs by default regardless of the status of the Secure Mobility Agent (the VPN). Both can be disabled or removed, because they're installed on unmanaged machines. So there's a risk that the machine can be compromised and then connect to the VPN. Jul 25, 2016 at 16:31
  • 2
    The risk is that you could use the tunnel from inside the firewall at the business site to get to things on the Internet which are forbidden by policies and protections on the firewall. It really doesn't matter whether or not you disagree, that is why the software was designed that way, and how it works.
    – Ron Maupin
    Jul 25, 2016 at 16:36
  • 2
    It is the equivalent of allowing a PC at the business to have a separate connection to the Internet. The PC could be configured to allow others to go through it to the Internet. This makes the business firewall and Internet policies moot. Your offsite PC is directly connected to the business network while using the VPN, just as if it was connected at the business site. When you disconnect the tunnel, your routing returns to normal. Cisco designs the software for businesses, not end-users.
    – Ron Maupin
    Jul 25, 2016 at 16:50
  • 2
    Those aren't equivalents. VPN users should be treated as hostile and relegated to a subnet on your network with limited routing on the intranet. The Cisco VPN supports this and actually allows account level restrictions. Additionally the clientside routes are not defined by Cisco, they're defined by the network admin deploying the production. The VPN client also comes with a separate Firewall solution that is required to be running while the VPN client is running, but can be disabled when the VPN client is disabled. Jul 25, 2016 at 17:02
  • 3
    Look, you asked the question, and I explained why it is the way it is. I didn't design the software, so don't gripe to me about it, gripe to Cisco, but don't expect to get very far. You may not like it, but it is what it is.
    – Ron Maupin
    Jul 25, 2016 at 17:04
2

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

You must log in to answer this question.

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