Ytdyklly

The problem with Anyconnect is that it first modifies the routing table, then babysits it and fixes it up should you modify it manually. I found a workaround for this. Works with version 3.1.00495, 3.1.05152, 3.1.05170, and probably anything else in the 3.1 family. May work with other versions, at least similar idea should work assuming the code does not get rewritten. Fortunately for us Cisco has put the babysitter "baby is awake" call into a shared library. So the idea is that we prevent action by vpnagentd via LD_PRELOAD.

1. 
   

   First we create a file hack.c:

   
   
   

   #include <sys/socket.h>
   
   #include <linux/netlink.h>
   
   
   
   int _ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEv()
   
   {
   
     int fd=50;          // max fd to try
   
     char buf[8192];
   
     struct sockaddr_nl sa;
   
     socklen_t len = sizeof(sa);
   
   
   
     while (fd) {
   
        if (!getsockname(fd, (struct sockaddr *)&sa, &len)) {
   
           if (sa.nl_family == AF_NETLINK) {
   
              ssize_t n = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);
   
           }
   
        }
   
        fd--;
   
     }
   
     return 0;
   
   }
   
   

   
   


2. 
   

   Then compile it like this:

   
   
   

   gcc -o libhack.so -shared -fPIC hack.c
   
   

   
   


3. 
   

   Install libhack.so into the Cisco library path:

   
   
   

   sudo cp libhack.so  /opt/cisco/anyconnect/lib/
   
   

   
   


4. 
   

   Bring down the agent:

   
   
   

   /etc/init.d/vpnagentd stop
   
   

   
   


5. 
   

   Make sure it really is down

   
   
   

   ps auxw | grep vpnagentd
   
   

   
   
   

   If not, kill -9 just to be sure.

   
   


6. 
   

   Then fix up /etc/init.d/vpnagentd by adding LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so
   where the vpnagentd is being invoked so it looks like this:

   
   
   

   LD_PRELOAD=/opt/cisco/anyconnect/lib/libhack.so /opt/cisco/anyconnect/bin/vpnagentd
   
   

   
   


7. 
   

   Now start the agent:

   
   
   

   /etc/init.d/vpnagentd start
   
   

   
   


8. 
   

   Fix up iptables, because AnyConnect messes with them:

   
   
   

   iptables-save | grep -v DROP | iptables-restore
   
   

   
   
   

   You may want to do something more advanced here to allow access only to certain LAN hosts.

   
   


9. 
   

   Now fix up the routes as you please, for example:

   
   
   

   route add -net 192.168.1.0 netmask 255.255.255.0 dev wlan0
   
   

   
   


10. 
    

    Check to see if they are really there:

    
    
    

    route -n
    
    

    
    

A previous, simpler version of this hack gave a function that only did "return 0;" - that poster noted that "The only side effect that I've observed so far is that vpnagentd is using 100% of CPU as reported by top, but overall CPU is only 3% user and 20% system, and the system is perfectly responsive. I straced it, it seems to be doing two selects in a loop when idle returning from both quickly, but it never reads or writes - I suppose the call that I cut out with LD_PRELOAD was supposed to read. There might be a cleaner way to do it, but it is good enough for me so far. If somebody has a better solution, please share."

The problem with the trivial hack is it caused a single cpu core to be 100% all the time, effectively reducing your hardware cpu thread count by one - whether your vpn connection was active or not. I noticed that the selects the code was doing were on a netlink socket, which sends vpnagentd data when the routing table changes. vpnagentd keeps noticing there's a new message on the netlink socket and calls the routeCallBackHandler to deal with it, but since the trivial hack doesn't clear the new message it just keeps getting called again and again. the new code provided above flushes the netlink data so the endless loop which caused the 100% cpu doesn't happen.

If something does not work, do gdb -p $(pidof vpnagentd), once attached:

b socket

c

bt

and see which call you are in. Then just guess which one you want to cut out, add it to hack.c and recompile.

This is VERY convoluted, but if you create a minimal VM using VMWare Player or similar, and run the Cisco AnyConnect VPN client in that, it might be possible to set up routing as you want using the VMWare virtual network adapters, or simply use the VM for access to whatever resources are required via the Cisco SSL VPN and "drag/drop" files to/from your actual machine.

Shrew Soft VPN software did the trick for me, also, as Ian Boyd suggested.

It can import Cisco VPN client profiles. I have used Cisco VPN Client version 5.0.05.0290, and after installing the Shrew VPN (version 2.1.7) and importing Cisco profile, I was able to access local LAN while connected to corporate VPN without any additional configuration of Shrew VPN connection (or software).

Thanks to Sasha Pachev for the nice hack above.

vpnagentd also messes with the resolver by overwriting the changes made to /etc/resolv.conf. I solved it by eventually winning the race against it:

#!/bin/bash



dnsfix() {

    [ -f /etc/resolv.conf.vpnbackup ] || echo "Not connected?" >&2 || return 0 # do nothing in case of failure

    while ! diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup #>/dev/null

    do

         cat /etc/resolv.conf.vpnbackup >/etc/resolv.conf

    done

    chattr +i /etc/resolv.conf

    diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null 

}



while ! dnsfix

do

    echo "Retrying..."

    chattr -i /etc/resolv.conf

done

Don't forget to chattr -i /etc/resolv.conf when disconnecting.

I'm trying to solve it by intercepting the callback, like for the routes method above, but can't yet find the corresponding callback or method.

Update1/2: A strace revealed that vpnagentdis using the inotify API to monitor the resolver file changes. From there onwards it was downhill.
Here's the additional hack:

int _ZN18CFileSystemWatcher11AddNewWatchESsj(void *string, unsigned int integer)

{

  return 0;

}

That's a little bit overkill, granted, as it disables all file watching for the agent. But seems to work OK.

The vpn client wrapper script below integrates all the functionality(updated to include this additional hack). chattr is no longer used/needed.

Update 3: Fixed username/password settings in the script. It now uses a vpn.conf file with the format described below(and root-only permissions).

#!/bin/bash



# Change this as needed

CONF="/etc/vpnc/vpn.conf"

# vpn.conf format

#gateway <IP>

#username <username>

#password <password>

#delete_routes <"route spec"...> eg. "default gw 0.0.0.0 dev cscotun0"

#add_routes <"route spec"...> eg. "-net 192.168.10.0 netmask 255.255.255.0 dev cscotun0" "-host 10.10.10.1 dev cscotun0"



ANYCONNECT="/opt/cisco/anyconnect"



usage() {

    echo "Usage: $0 {connect|disconnect|state|stats|hack}"

    exit 1

}



CMD="$1"

[ -z "$CMD" ] && usage



ID=`id -u`



VPNC="$ANYCONNECT/bin/vpn"



dnsfix() {

    [ -f /etc/resolv.conf.vpnbackup ] || echo "Not connected?" >&2 || return 0 # do nothing in case of failure

    while ! diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null

    do

         cat /etc/resolv.conf.vpnbackup >/etc/resolv.conf

    done

#    chattr +i /etc/resolv.conf

    diff -q /etc/resolv.conf /etc/resolv.conf.vpnbackup >/dev/null 

}



case "$CMD" in

    "connect")

        [ $ID -ne 0 ] && echo "Needs root." && exit 1

        HOST=`grep ^gateway $CONF | awk '{print $2}'`

        USER=`grep ^user $CONF | awk '{print $2}'`

        PASS=`grep ^password $CONF | awk '{print $2}'`

        OLDIFS=$IFS

        IFS='"'

        DEL_ROUTES=(`sed -n '/^delete_routes/{s/delete_routes[ t"]*//;s/"[ t]*"/"/g;p}' $CONF`)

        ADD_ROUTES=(`sed -n '/^add_routes/{s/add_routes[ t"]*//;s/"[ t]*"/"/g;p}' $CONF`)

        IFS=$OLDIFS



        /usr/bin/expect <<EOF

set vpn_client "$VPNC";

set ip "$HOST";

set user "$USER";

set pass "$PASS";

set timeout 5

spawn $vpn_client connect $ip

match_max 100000

expect { 

    timeout {

        puts "timeout errorn"

        spawn killall $vpn_client

        exit 1

    }

    ">> The VPN client is not connected." { exit 0};

    ">> state: Disconnecting" { exit 0};

    "Connect Anyway?"

}

sleep .1

send -- "yr"

expect { 

    timeout {

        puts "timeout errorn"

        spawn killall $vpn_client

        exit 1

    }

    "Username:"

}

sleep .1

send -- "$userr"

expect { 

    timeout {

        puts "timeout errorn"

        spawn killall $vpn_client

        exit 1

    }

    "Password: "

}

send -- "$passr";

expect eof

EOF

        sleep 2

        # iptables

        iptables-save | grep -v DROP | iptables-restore



        # routes

        for ROUTE in "${DEL_ROUTES[@]}"

        do

#            echo route del $ROUTE

            route del $ROUTE

        done

        for ROUTE in "${ADD_ROUTES[@]}"

        do

#            echo route add $ROUTE

            route add $ROUTE

        done



        # dns

        while ! dnsfix

        do

            echo "Try again..."

#            chattr -i /etc/resolv.conf

        done



        echo "done."

        ;;

    "disconnect")

#        [ $ID -ne 0 ] && echo "Needs root." && exit 1

        # dns

#        chattr -i /etc/resolv.conf



        $VPNC disconnect

        ;;

    "state"|"stats")

        $VPNC $CMD

        ;;

    "hack")

        [ $ID -ne 0 ] && echo "Needs root." && exit 1

        /etc/init.d/vpnagentd stop

        sleep 1

        killall -9 vpnagentd 2>/dev/null

        cat - >/tmp/hack.c <<EOF

#include <sys/socket.h>

#include <linux/netlink.h>



int _ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEv()

{

  int fd=50;          // max fd to try

  char buf[8192];

  struct sockaddr_nl sa;

  socklen_t len = sizeof(sa);



  while (fd) {

     if (!getsockname(fd, (struct sockaddr *)&sa, &len)) {

        if (sa.nl_family == AF_NETLINK) {

           ssize_t n = recv(fd, buf, sizeof(buf), MSG_DONTWAIT);

        }

     }

     fd--;

  }

  return 0;

}



int _ZN18CFileSystemWatcher11AddNewWatchESsj(void *string, unsigned int integer)

{

  return 0;

}

EOF

        gcc -o /tmp/libhack.so -shared -fPIC /tmp/hack.c

        mv /tmp/libhack.so $ANYCONNECT

        sed -i "s+^([ t]*)$ANYCONNECT/bin/vpnagentd+1LD_PRELOAD=$ANYCONNECT/lib/libhack.so $ANYCONNECT/bin/vpnagentd+" /etc/init.d/vpnagentd

        rm -f /tmp/hack.c

        /etc/init.d/vpnagentd start

        echo "done."

        ;;

    *)

        usage

        ;;

esac

My company still uses that vpn.
The vpnc client simply changes you iptables settings that way :

# iptables-save

# Generated by iptables-save v1.4.10 on Sun Jun 17 14:12:20 2012

*filter

:INPUT DROP [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT DROP [0:0]

-A INPUT -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACCEPT 

-A INPUT -i tun0 -j ACCEPT 

-A INPUT -i lo0 -j ACCEPT

-A INPUT -j DROP 

-A OUTPUT -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPT 

-A OUTPUT -o tun0 -j ACCEPT 

-A OUTPUT -o lo0 -j ACCEPT 

-A OUTPUT -j DROP 

COMMIT

It filters all except for the vpn traffic.

Simply get the filter in a file with iptables-save, add INPUT and OUTPOUT access lines that match your needs and reapply the file with iptables-restore.

for instance to access a local network on 192.168.0

# Generated by iptables-save v1.4.10 on Sun Jun 17 14:12:20 2012

*filter

:INPUT DROP [0:0]

:FORWARD ACCEPT [0:0]

:OUTPUT DROP [0:0]

-A INPUT -s 123.244.255.254/32 -d 192.168.0.14/32 -j ACCEPT 

-A INPUT -s 192.168.0.0/24 -d 192.168.0.14/32 -j ACCEPT      #local in

-A INPUT -i tun0 -j ACCEPT 

-A INPUT -i lo0 -j ACCEPT 

-A INPUT -j DROP 

-A OUTPUT -s 192.168.0.14/32 -d 123.244.255.254/32 -j ACCEPT 

-A OUTPUT -s 192.168.0.14/32 -d 192.168.0.0/24 -j ACCEPT     #local out

-A OUTPUT -o tun0 -j ACCEPT 

-A OUTPUT -o lo0 -j ACCEPT 

-A OUTPUT -j DROP 

COMMIT

Any news on this?

At what level is Cisco VPN client driver doing what in the networking
stack that takes overrides a local administrator's ability to
administer their machine?

I fully agree and was wondering about the same thing.

Anyway, it's an app that requires admin privileges to install and while it runs it may very well filter what you do...

My attempts on Windows fail too:

route change 0.0.0.0 mask 0.0.0.0 192.168.1.1 metric 1

 OK!



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.230     21 <-- LAN

          0.0.0.0          0.0.0.0    192.168.120.1    192.168.120.3      2 <-- VPN

Haha. No metric below 20 here it seems.

I don't know if I have understood it right, but I first clarify my understanding:

You have a local LAN (for example, say 10.0.0.0/16, and a remote Cisco VPN Server (for example, 64.0.0.0/16). You want to connect to the VPN server through the Cisco VPN client and yet you need to have the LAN access. In this case you want to separate the whole 10.0.x.x/16 from the VPN connection). The following route must be added in a Mac client:

/sbin/route add -net 10.0 -interface en1

where en1 is the interface through which you are connected to your LAN. I know you can add the same thing in Windows and Linux as well.

Since I cannot add comments, I'll post here. I'm running on Windows.

The solution using Virtual Machine and run AnyConnect inside the VM and then use VM as a mediator between your working environment and company's network won't work if your "beloved" IT department routes 0.0.0.0 through VPN thus even your local network (including this between your local PC and VM) is routed through the VPN(sic!).

I tried to apply solution posted by @Sasha Pachev but eventually I ended up patching .dll so that it returns 0 at the beginning of the function.
Eventually after some fight with dynamic library, I was able to modify routing tables according to my needs but apparently that's not enough!

Even though my rules seems to be correct to achieve split tunneling, I still get General Failure.
Did you come across similar problem as were able to solve it?

• My gateway to the internet is 192.168.163.2


• My gateway to the company's network is 10.64.202.1 (thus whole 10...* subnet I treat as "comapny's")

This is how my routing table looks like now (after manual modifications while VPN is on)

yet the result of ping are following

C:UsersMike>ping -n 1 10.64.10.11

Reply from 10.64.10.11: bytes=32 time=162ms TTL=127



C:UsersMike>ping -n 1 8.8.8.8

PING: transmit failed. General failure.



C:UsersMike>ping -n 1 192.168.163.2

General failure.

Just for the reference, below is how route table looks like when VPN is disconnected (unaltered)

and this is how the table looks like when VPN is connected (unaltered)
in that case when I'm trying to ping 8.8.8.8 I simply get timeout (since company's firewall does not allow traffic to go outside the intranet)

For those looking to maintain control of their routing table when using a Cisco AnyConnect SSL VPN, check out OpenConnect. It both supports the Cisco AnyConnect SSL VPN and doesn't attempt to disrupt or 'secure' routing table entries. @Vadzim alludes to this in a comment above.

After trying everything but patching the AnyConnect Secure Mobility Client, I was able to successfully replace it on Windows with OpenConnect GUI. This enabled me to maintain connectivity to local resources (and update the routing table).

I use OpenConnect on Windows but it also supports Linux, BSD, and macOS (among other platforms) according to the project page.

Try remove those entries with gateway 10.64.202.13 see if ping 8.8.8.8 works then add them back one by one and identify which one is causing the trouble.

How did you patch the DLL. I can't even modify the routing table because it keeps adding the 0.0.0.0 with VPN gateway back.