Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

How can I maintain local LAN access while connected to Cisco VPN?

When connecting using Cisco VPN, the server has to ability to instruct the client to prevent local LAN access.

Assuming this server-side option cannot be turned off, how can allow local LAN access while connected with a Cisco VPN client?


I used to think it was simply a matter of routes being added that capture LAN traffic with a higher metric, for example:

  Network 
Destination      Netmask        Gateway       Interface  Metric
   10.0.0.0  255.255.0.0       10.0.0.3        10.0.0.3      20  <--Local LAN
   10.0.0.0  255.255.0.0  192.168.199.1  192.168.199.12       1  <--VPN Link

And trying to delete the 10.0.x.x -> 192.168.199.12 route don't have any effect:

>route delete 10.0.0.0
>route delete 10.0.0.0 mask 255.255.0.0
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1 if 192.168.199.12
>route delete 10.0.0.0 mask 255.255.0.0 192.168.199.1 if 0x3

And while it still might simply be a routing issue, attempts to add or delete routes fail.

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?

The Cisco VPN client cannot be employing magic. It's still software running on my computer. What mechanism is it using to interfere with my machine's network? What happens when an IP/ICMP packet arrives on the network? Where in the networking stack is the packet getting eaten?

See also


Edit: Things I've not yet tried:

>route delete 10.0.*

Update: Since Cisco has abandoned their old client, in favor of AnyConnect (HTTP SSL based VPN), this question, unsolved, can be left as a relic of history.

Going forward, we can try to solve the same problem with their new client.

share|improve this question
1  
The VPN Link has a lower metric and is thus tried before your local route. Increasing the metric of your local LAN is most likely going to disable your local LAN. If the VPN is not configured to tunnel all traffic switching your home subnet could be a solution. What are the IP's you need to access through this VPN? Is this the entire 10.0.0.0 on the VPN side? –  pberlijn May 17 '11 at 15:55
    
That sounds like it very well could be the issue; i thought metric of higher = better. –  Ian Boyd Jun 15 '11 at 2:22
    
Indeed, Lower metric = preferred. –  Jonathon Reinhart Jan 20 '14 at 1:10

9 Answers 9

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.

share|improve this answer
    
This is genius. I'm trying to get it to work on OSX and have one question: how did you know that the method to override was named _ZN27CInterfaceRouteMonitorLinux20routeCallbackHandlerEv? –  donturner Feb 6 '14 at 15:40
    
+1 for tremendous dedication :) –  user2240431 Oct 8 '14 at 21:49

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.

share|improve this answer

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
share|improve this answer

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).

share|improve this answer
    
It would be amazing if this was available for android. –  Gabriel Fair Jan 22 '14 at 15:46

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.

share|improve this answer
    
As far as linux is concerned, this (petefreitag.com/item/753.cfm) seems to indicate that the firewall is involved too. –  Marki Jul 23 '11 at 19:51
1  
i found ShrewSoft VPN. It can connect to a Cisco IPSec VPN server, and it ignores the VPN server administrator's demand that i be disconnected from my own network. (See superuser.com/questions/312947/… for detailed instructions) Even though it doesn't answer this question, it is a workaround. Note: ShrewSoft VPN only works for IPSec; it doesn't work with SSL VPN (i.e. newer Cisco AnyConnect VPN client) –  Ian Boyd Jul 24 '11 at 0:57

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.

share|improve this answer
1  
+1 for Mac client; which doesn't apply to me. And while this command might work, the Cisco client might delete it shortly after being created (the Cisco client seems to prevent anyone from changing routes) –  Ian Boyd Mar 5 '13 at 19:06

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. 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 template
#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 error\n"
        spawn killall \$vpn_client
        exit 1
    }
    ">> The VPN client is not connected." { exit 0};
    ">> state: Disconnecting" { exit 0};
    "Connect Anyway?"
}
sleep .1
send -- "y\r"
expect { 
    timeout {
        puts "timeout error\n"
        spawn killall \$vpn_client
        exit 1
    }
    "Username:"
}
sleep .1
send -- "\$user\r"
expect { 
    timeout {
        puts "timeout error\n"
        spawn killall \$vpn_client
        exit 1
    }
    "Password: "
}
send -- "\$pass\r";
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
share|improve this answer

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) http://i.stack.imgur.com/ApHb3.png

yet the result of ping are following

C:\Users\Mike>ping -n 1 10.64.10.11
Reply from 10.64.10.11: bytes=32 time=162ms TTL=127

C:\Users\Mike>ping -n 1 8.8.8.8
PING: transmit failed. General failure.

C:\Users\Mike>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)

http:// i.stack.imgur.com/GU6z1.png

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)

http:// i.stack.imgur.com/1Nfzg.png

(sorry for broken links and images as links, SO won't allow me to write "normal" reply...) I'm stuck!

share|improve this answer

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.

share|improve this answer
    
If you need clarification or additional information on a question please post a comment rather than including it in your answer. Thanks. –  Matthew Williams May 1 '14 at 8:48
    
wasn't allowing me to add comments to existing questions. –  Tony May 1 '14 at 14:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.