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 at 1:10
add comment

8 Answers

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 at 15:40
add comment

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
add comment

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
add comment

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 at 15:46
add comment

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
add comment

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
add comment

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
add comment

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 at 8:48
    
wasn't allowing me to add comments to existing questions. –  Tony May 1 at 14:44
add comment

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.