Split Tunnel and Cisco AnyConnect

cisco-anyconnectsplit-tunnelvpn

I am using Cisco AnyConnect Secure Mobility Client 3.1.02026 on Windows 7 64-bit. I have heard there is a checkbox which enables split tunneling. However, this checkbox is removed from the GUI probably due to the administrator's settings. The administrator doesn't want to make any configuration changes. I would like to force split tunneling. How? It's okay if the solution uses a different VPN client. The solution can not make any changes on the VPN server. I have tried a virtual machine and it works, but I would like a more convenient solution. I have tried messing around with route table but I failed probably due to lack of knowing how to do it right.

Here is my route print before connecting to the VPN.

===========================================================================
Interface List
 14...00 1e 4f d7 64 5b ......Intel(R) 82566DM-2 Gigabit Network Connection
  1...........................Software Loopback Interface 1
 25...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 27...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

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.3     10
        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
      169.254.0.0      255.255.0.0         On-link       192.168.1.3     11
  169.254.255.255  255.255.255.255         On-link       192.168.1.3    266
      192.168.1.0    255.255.255.0         On-link       192.168.1.3    266
      192.168.1.3  255.255.255.255         On-link       192.168.1.3    266
    192.168.1.255  255.255.255.255         On-link       192.168.1.3    266
        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.1.3    266
  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.1.3    266
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      169.254.0.0      255.255.0.0      192.168.1.3       1
          0.0.0.0          0.0.0.0     10.154.128.1       1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 27     58 ::/0                     On-link
  1    306 ::1/128                  On-link
 27     58 2001::/32                On-link
 27    306 2001:0:5ef5:79fd:3431:3b25:b736:1859/128
                                    On-link
 14    266 fe80::/64                On-link
 27    306 fe80::/64                On-link
 27    306 fe80::3431:3b25:b736:1859/128
                                    On-link
 14    266 fe80::3933:bb6f:892:d161/128
                                    On-link
  1    306 ff00::/8                 On-link
 27    306 ff00::/8                 On-link
 14    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Here is my route print after connecting to the VPN.

===========================================================================
Interface List
 19...00 05 9a 3c 7a 00 ......Cisco AnyConnect Secure Mobility Client Virtual Miniport Adapter for Windows x64
 14...00 1e 4f d7 64 5b ......Intel(R) 82566DM-2 Gigabit Network Connection
  1...........................Software Loopback Interface 1
 25...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 27...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
167...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #3
===========================================================================

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.3     10
          0.0.0.0          0.0.0.0     10.154.128.1     10.154.159.8      2
     10.154.128.0    255.255.224.0         On-link      10.154.159.8    257
     10.154.159.8  255.255.255.255         On-link      10.154.159.8    257
   10.154.159.255  255.255.255.255         On-link      10.154.159.8    257
        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
     137.254.4.91  255.255.255.255      192.168.1.1      192.168.1.3     11
      169.254.0.0      255.255.0.0         On-link      10.154.159.8    306
      169.254.0.0      255.255.0.0         On-link       192.168.1.3    306
  169.254.255.255  255.255.255.255         On-link      10.154.159.8    257
  169.254.255.255  255.255.255.255         On-link       192.168.1.3    266
      192.168.1.1  255.255.255.255         On-link       192.168.1.3     11
      192.168.1.3  255.255.255.255         On-link       192.168.1.3    266
        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.1.3    266
        224.0.0.0        240.0.0.0         On-link      10.154.159.8    257
  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.1.3    266
  255.255.255.255  255.255.255.255         On-link      10.154.159.8    257
===========================================================================
Persistent Routes:
  Network Address          Netmask  Gateway Address  Metric
      169.254.0.0      255.255.0.0      192.168.1.3       1
          0.0.0.0          0.0.0.0     10.154.128.1       1
===========================================================================

IPv6 Route Table
===========================================================================
Active Routes:
 If Metric Network Destination      Gateway
 19     11 ::/0                     On-link
  1    306 ::1/128                  On-link
 19    266 fe80::/64                On-link
 19    266 fe80::2a78:5341:7450:2bc1/128
                                    On-link
 14    266 fe80::3933:bb6f:892:d161/128
                                    On-link
 19    266 fe80::c12f:601f:cdf:4304/128
                                    On-link
 19    266 fe80::c5c3:8e03:b9dd:7df5/128
                                    On-link
  1    306 ff00::/8                 On-link
 14    266 ff00::/8                 On-link
===========================================================================
Persistent Routes:
  None

Best Answer

First understand that the reason your network admins have disallowed split tunneling is because it potentially allows any malicious person/code to circumvent the security measures that have been implemented by accessing the network via your computer. Believe me I know not having a split tunnel is annoying, but ask your self is it worth the risk?

Now that warnings are out of the way I can tell you Cisco AnyConnect prevents a split tunnel by temporarily re-writing the routing table of the host computer. Use route print before you start AnyConnect and use it again after to see the differences. You can write a script to adjust the routing table and run it after you start AnyConnect. An easier solution that probably doesn't violate your networks usage policy is simply using a VM with AnyConnect. Your host's NIC doesn't get locked down and you don't break any rules... best of both worlds.

Part 1. Output of locally-generated (outbound connection) packages.

Mark outgoing locally generated packages with connection-specific mark for future rerouting with different rt_table.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp --dport Y -m owner --uid-owner 100Z -j CONNMARK --set-mark 2
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp --dport Y -m owner --uid-owner 100Z -j CONNMARK --set-mark 2

Translate connection-specific markers to package-specific markers.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j MARK --set-mark 2
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j MARK --set-mark 2

Save marker for further restoring it for all tracked connections. This can be implemented in NAT POSTROUTING table only - it's just a precaution to not loose markers after connection traverse the routing table.

/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p tcp -m owner --uid-owner 100Z -m tcp --dport Y -m connmark ! --mark 0 -j CONNMARK --save-mark
/sbin/iptables -t mangle -A OUTPUT -s 192.168.XXX.XXX -p udp -m owner --uid-owner 100Z -m udp --dport Y -m connmark ! --mark 0 -j CONNMARK --save-mark

Normally connection-specific markers should be saved after packages rerouted and reached NAT POSTROUTING table

/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j CONNMARK --save-mark
/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j CONNMARK --save-mark

Replace source with proper VPN-related local address for tun0 interface.

/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p tcp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j SNAT --to-source 10.???.???.???
/sbin/iptables -t nat -A POSTROUTING -s 192.168.XXX.XXX -o tun0 -p udp --dport Y -m owner --uid-owner 100Z -m connmark --mark 2 -j SNAT --to-source 10.???.???.???

Part 2. Input of connections related to locally-generated (outbound connection) packages.

Restore connection-related markers for input packets before they go to the routing table.

/sbin/iptables -t mangle -A PREROUTING -i tun0 -p tcp -j CONNMARK --restore-mark
/sbin/iptables -t mangle -A PREROUTING -i tun0 -p udp -j CONNMARK --restore-mark

Part 3. Optional optimization

Other than above rules there is a strong desire in optimizing marking process to prevent or minimize redundant and repeated checks with marking. The most general approach for this task is to distinguish rules between NEW and RELATED,ESTABLISHED connection and use below template for optimal remarking already marked connections: * Restore old markers (you probably won't do this for NEW connections because they are obviously wasn't marked earlier):

/sbin/iptables -A OUTPUT -t mangle -j CONNMARK --restore-mark

Skip already marked connections:

/sbin/iptables -A OUTPUT -t mangle -m mark ! --mark 0 -j ACCEPT

Mark new (usually marking only NEW connection should be enough) connections:

/sbin/iptables -A OUTPUT -m mark --mark 0 -p tcp --dport 21 -t mangle -j MARK --set-mark 1
/sbin/iptables -A OUTPUT -m mark --mark 0 -p tcp --dport 80 -t mangle -j MARK --set-mark 2

Mark other packages with a "dummy" marker (that is not used anywhere else at all):

/sbin/iptables -A OUTPUT -m mark --mark 0 -t mangle -p tcp -j MARK --set-mark 3

Finally save markers:

/sbin/iptables -A OUTPUT -t mangle -j CONNMARK --save-mark

NOTE: the above settings are not a mandatory part of netfilter configuration for split tunnel - it is just a template (i.e. proper suggestion) for the way to minimize redundant filter checks. It also can be POSTROUTING instead of OUTPUT, but only one place is recommended for markings, do not need to implement it twice.

Part 4. Create table aliases in rt_tables.

echo 2 vpn >/etc/iproute2/rt_tables
echo 3 novpn >/etc/iproute2/rt_tables

Part 5. Configuring routing tables for VPN connections.

This is a standard configuration for VPN that allows to redirect all local sources (0.0.0.0/1 and 128.0.0.0/1 subnets include the whole IP range for local addresses) and also provides backward compatibility for returning packages (i.e. the "default" route).

Table with VPN connection

ip route flush table vpn
ip route add 10.???.???.(???+1) dev tun0 src 10.???.???.??? table vpn
ip route add 0.0.0.0/1 dev tun0 via 10.???.???.(???+1) table vpn
ip route add 128.0.0.0/1 dev tun0 via 10.???.???.(???+1) table vpn
ip route add 192.168.0.0/16 src 192.168.XXX.XXX dev eth0 table vpn
ip route add default via 192.168.XXX.1 dev eth0 table vpn

The other table called "novpn". It's goal to provide direct routing bypassing VPN connection.

ip route flush table novpn
ip route add 192.168.0.0/16 src 192.168.XXX.XXX dev eth0 table novpn
ip route add default via 192.168.XXX.1 dev eth0 table novpn

Part 6. Configuring routing rules (it is better to follow rule order below)

ip rule add from all lookup novpn
ip rule add from all fwmark 2 lookup vpn
ip rule add from 10.XXX.XXX.XXX lookup vpn

Part 7. Final steps

Now it is time to flush main routing table (there is no need for it while split tunnel is working):

ip route flush table main

The last step in configuration is to enable IP forwarding and dynamic IP addresses for sockets (client application connections) in Linux kernel:

echo 1 >/proc/sys/net/ipv4/ip_forward
echo 1 >/proc/sys/net/ipv4/ip_dynaddr

Now we can launch OpenVPN client with "--route-noexec" and/or "--ifconfig-noexec" (whether you already know or still not receive push message from VPN server with your tun0 interface configuration) parameters. If there are troubles with tun0 addresses - it is better to not use "--ifconfig-noexec" and let OpenVPN client set tun0 addresses for you. After that you just need to delete some old rules from "ip route" and "/sbin/iptables" and replace them with similar ones containing proper tun0 addresses (refer to all lines with 10.XXX.XXX.XXX or 10.XXX.XXX.(XXX+1) from above).

openvpn --config ./<your_config>.ovpn --route-noexec --ifconfig-noexec --auth-nocache

Those are only rules for outbound connections. The main difference between inbound and outbound configurations: inbound rules should be implemented mostly in "mangle" table, not "nat", and vice-verse for outbound as shown above. There is an exception - for output of both locally-generated (outbound) and answered (inbound connection) packages rules must be placed in "mangle" table due to netfilter architecture implementation (for some reason "nat" table will intercept packages only after the rerouting procedure - consult Wikipedia netfilter graph or netfilter official documentation).

Linux – Routing all traffic over VPN on Ubuntu Linux

Your local network is 192.168.1.0/24, as shown by this line in your routing table:

 192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.32  metric 1

Your VPN network is 10.0.0.0/8, as shown by this line:

 10.0.0.0/8 dev tun0  scope link

Currently, your default router is:

 default via 192.168.1.254 dev eth0  proto static

which is of course what you do not want, because it belongs to your local LAN: thus all of your stuff is routed through your local gateway, as if the VPN did not exist.

 You do have however, the all-important statement

 128.122.252.68 via 192.168.1.254 dev eth0  src 192.168.1.32

which is the route to your VPN-provider.

EDIT:

I had not realized that the routing table is simply the one that is obtained from your VPN, without your intervention. This may indicate (indirectly) that your service provider is willing to forward only the traffic explicitly allowed in your table through the interface tun0, and may have taken further steps to block all other traffic, in which case your efforts will be futile.

However, assuming that your provider is willing to forward all of your traffic, what you need to do is the following.

First, you need to find out whether there is a gateway willing to accept your connection on the other side, because we need its IP address. I will give you four methods to do this.

1) With the pc connected to the VPN, try the following command:

   sudo dhclient -v tun0

If everything goes well, you should see a reply containing this line:

 DHCPOFFER of a.b.c.d from x.y.w.z

x.y.w.z is the IP address of the local gateway. You may have to shutdown your VPN after this test, and maybe even to reboot your pc, because we will have just messed up the routing table pretty well.

2) Alternatively, you may try navigating to one of the allowed sites (those that appear in your routing table as going through the tun0 interface), then issuing the command:

  ip neigh show

You should get a list of pcs contacted through the ARP protocol, with MAC and IP address; most likely, you will receive either zero or one reply. If you get a single reply, then that's your router.

3) If you get no such reply, then you may try with

  sudo nmap -sn 10.0.0.0/8

(which is going to be very slow). Your gateway will be one of the pcs listed, most likely the one with address ending in .1 or in .254, if any such exist.

4) Use the tcpdump command:

  sudo tcpdump -n -i tun0

and see the IP addresses spewed out by the command.

If you get no proper reply to this test either, it means someone has really tightened the screws in his network.

But let us be optimistic, and suppose you now have a candidate IP address x.w.y.z for the remote router. You will need to delete the default gateway, (as sudo!):

  ip route del default via 192.168.1.254

an add the new one:

  ip route add default via x.w.y.z

and try to navigate.

Let me repeat: since your provider has allowed traffic only to a few selected IP addresses through his VPN, it is possible he may have taken extra measures (=firewall) to prevent a smart user to force his generic traffic through his VPN. In this case, there is nothing you can do. But if he did not, the above steps should help you find a solution.