Comment 11 for bug 441204

Hello All,

Forgive me if I'm dong this wrong - first time adding any info. Nice work to all by the way...

Okay: Using vpnc to connect to CISCO ASA 5510 at my office - I happen to be the network Admin, so I know what's on the other side. I happen to be using Split Tunneling as well.

Ubuntu 10.04 LTS w/ vpnc (command line) on a DELL Latitude D510 w/ 2GB RAM and the DELL wi-fi card.
Connecting to LAN w/ Wi-Fi.

The symptom was exactly what was described above: Connect vpn using the VPNC (not CISCO client) and everything looks good for a short time - about long enough to connect to a server on the other side using the default installed Terminal Server Client. Then hard freeze. The only way out was to shutdown via the powerbutton. Shades of Windows creeping in and giving me the willies...

I've read a bunch of threads on various bugs related to VPN and Ubuntu and ended up here.

I did run this on 9.04 and 9.10 and even the 10.04 LTS without any problems ... At HOME.

The difference here is that I'm not at home, I'm outside, using a Sprint 3G/4G hotspot (Sierra Wireless modem + wi-fi AP w/ router, DHCP)

I could not figure out why I was not able to use this for VPN, but could surf internet just fine until I connected the VPN. UNLIKE this bug, I usually got everything back after shutting down all VPN and Terminal services processes - if I was able to.

ANSWER: (and it makes this seem that perhaps it is NOT A BUG) is that the LAN settings happen to match a defined route within my office network. Thus I created an impossible condition as soon as the VPN returned the route info from my office and altered my route list on the laptop.

In short, the condition existed that the default path to get out of my LAN was also defined within my office network.

So, assuming that my local gw is 192.168.0.1 - as many of them are - and there is a path defined within the VPN connected LAN such that 192.168.0.0 subnet mask 255.255.255.0 or 255.255.0.0 (worse case) exists then you get an impossible routing condition setup and the local machine, my laptop, is frozen trying to resolve how to get anywhere.

so, to get to the VPN connected network I have a route that says to use 192.168.0.1 on eth1, but a littel further down the route table I have a statement -returned from the VPN- that says that for anything on the 192.168.0.0 network (mask 255.255.255.0) to use tun0 (see below)

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
<VPN-IP> 192.168.0.1 255.255.255.255 UGH 0 0 0 eth1
192.168.4.0 * 255.255.255.0 U 0 0 0 tun0
192.168.0.0 * 255.255.255.0 U 0 0 0 tun0

In this case, you are hosed.

I changed the 3rd octet on my local LAN and the DHCP assignment ranges to match and all the problems went away.

Note: I altered the route table above to show what HAS to be the situation, since while it exists I cannot get to the route table to copy it. However, all that I did was change the 3rd octet to, in this case <>0 and <>4 value, something not defined as a route inside the VPN attached network and you should be good.

It was not until I realized that the same settings and code worked from home but not when not at home and thought about the differences external to the code - and realized that the freeze was very similar to what happens when you create a loop between two network switches without aggregating the ports (which happened about a month ago and brought down the VoIP system unexpectedly - oops, too many chiefs) that it all fell into place for me.

So, this may not be a bug, if everyone who has said this effects them can play around with their local LAN settings, or, find out from the admins on the other network if there is a route defined (just trace route the same IP that you have as your default gateway from your pc at the office/school/etc and see if it goes someplace) and then let us all know if this is still a bug. I very seriously thought that I was going to be hosed for VPN and Remote Access to my office once all of this started to fail ... but now I'm happy to discover it was just me all along.

Thanks for all the great info that can be found here...