Tray icon says I'm not connected but I actually am

Asked by Nicholas Taylor on 2011-10-23

I have successfully created and connected to a VPN using the tray icon but after a timeout period the tray icon notifies me that I am not connected. I am on Ubuntu 11.10 and connecting to a openswan-2.6.34(netkey)/xl2tpd-1.2.8 server. Windows and Mac clients can successfully connect to the server I am trying to connect to. As far as I am concerned the connection works and is stable. A ppp interface is created and an IP address is assigned to that interface. My resolv.conf is being updated properly as well. I can also ping the remote ppp IP address. All that is missing is a route to the remote network which I think what is making the "Not Connected" message come up.

In the source code to the program it appears that there are some gateway checks prior to issuing a "Connected" message. Looking at /etc/ppp/ip-up.d/L2tpIPsecVpn-up I see three lines where the route program is run and routes are added. When I manually check my route via "route" those entries do not exist.

I'm not really concerned with having a default route to the internet across the vpn, though having the option would be nice. I just need the split tunneling functionality. I have tried adding the split tunneling through the tray icon but I get the same results. As a temporary workaround for the issue I am manually adding a route via "route add -net 192.168.1.0 netmask 255.255.255.0 dev ppp0" to enable access to the remote network and then I am killing pluto and xl2tpd after I am done.

Sometimes these errors appear in the connection log but when they do the connection still works. I can provide additional documentation as requested.

pppd[16592]: Connect: ppp0 <--> /dev/pts/7
pppd[16592]: local IP address 10.48.196.2
pppd[16592]: remote IP address 10.48.196.1
xl2tpd[16543]: Can not find tunnel 24497 (refhim=0)
xl2tpd[16543]: network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 24497 Dumping.
xl2tpd[16543]: Can not find tunnel 24497 (refhim=0)
xl2tpd[16543]: network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 24497 Dumping.
xl2tpd[16543]: Can not find tunnel 24497 (refhim=0)
xl2tpd[16543]: network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 24497 Dumping.
xl2tpd[16543]: Can not find tunnel 24497 (refhim=0)
xl2tpd[16543]: network_thread: unable to find call or tunnel to handle packet. call = 0, tunnel = 24497 Dumping.

Question information

Language:
English Edit question
Status:
Solved
For:
L2TP over IPsec VPN Manager Edit question
Assignee:
No assignee Edit question
Solved by:
Nicholas Taylor
Solved:
2011-10-24
Last query:
2011-10-24
Last reply:
Nicholas Taylor (ntaylor-i) said : #1

After playing around with everything for awhile things are now working as expected. I only did two things on the iteration of my changes/testing that worked are detailed below.

I ran these commands (obviously replacing shell variables with actual values) to test if manually setting routes as is done in /etc/ppp/ip-up.d/L2tpIPsecVpn-up. After the routes were manually set everything worked as expected.
/sbin/route add -host briteair.dyndns.org gw ${DFLT_GWY} dev ${EXT_INTF}
/sbin/route add -net 0.0.0.0 dev ${PPP_IFACE}
/sbin/route add -net 0.0.0.0 gw ${DFLT_GWY} metric 100 dev ${EXT_INTF}
/sbin/route del -net 0.0.0.0 gw ${DFLT_GWY} metric 0 dev ${EXT_INTF}

Since manually adding the routes worked I commented out everything other than the route commands in /etc/ppp/ip-up.d/L2tpIPsecVpn-up. I then killed the former pluto & xl2tpd processes and reinitiated my vpn connection via the tray icon. Sure enough my connection came up and the tray icon correctly reported that the connection successful. I then started re-enabling my commented out sections in /etc/ppp/ip-up.d/L2tpIPsecVpn-up and re-testing. Eventually I had returned /etc/ppp/ip-up.d/L2tpIPsecVpn-up back to it's original state and the connection was still working. For a final test I restarted my computer and had the tray icon configuration menus regenerate all of my configuration files. Again, it worked great.

I don't know how to explain what happened here so I'm trying to document it well in case it happens to someone else. If I was hearing someone else tell this story I would probably assume they had missed something and didn't notice what they did to fix it. Who knows, maybe that is what happened.

Nicholas Taylor (ntaylor-i) said : #2

Apparently I spoke too soon, my routes stopped being added again. As a workaround I edited /etc/ppp/ip-up.d/L2tpIPsecVpn-up again. I commented out the first IF/FI statement and the last CASE/ESAC statement. All is well with my routes once again.

Werner: I'll let you decide if you'd like to make this a bug. I could investigate further if you'd like. It would probably be enough to just echo all of the variables before the sections in question as well as before the route commands are run. Thanks for the great software!

Nicholas Taylor (ntaylor-i) said : #3

I dug around some and found that this is a bug which was introduced in xl2tpd-1.2.8. Actually it's a bugfix for a bug that never existed.... This version of xl2tpd overrides and ipparam settings in /etc/ppp/$connection.options.xl2tpd with the server you are connecting to.

Debian list talking about it
https://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/142e47f3cccf3b43

Solutions are to downgrade xl2tpd to 1.2.7 or wait for a new version. I installed version 1.2.7 from Ubuntu 11.04 and that seems to be working fine. I think this issue should be noted in documentation.

Werner Jaeger (werner-jaeger) said : #4

Hi Nicholas,

thank you so much for this really great work!

Of course, I'm going to include your valuable findings into the documentation.

Cheers,
 Werner

Matt Zuba (matt-mattzuba) said : #5

Thanks for posting this info. I purge removed l2tp-ipsec-vpn and all of it's dependencies, downloaded xl2tpd 1.2.7 for 11.04, installed, then reinstalled l2tp-ipsec-vpn and it works as it should.

Matt Zuba (matt-mattzuba) said : #6

Should note too that the lower version needs to be locked so it doesn't get upgraded by mistake (like what happened to me)... quick instructions located here: http://askubuntu.com/questions/18654/how-to-prevent-updating-of-a-specific-package

Matt Zuba (matt-mattzuba) said : #7

This is still a valid issue in Precise (12.04) as well, installing 1.2.7 from Natty again resolves it.

Nicholas Taylor (ntaylor-i) said : #8

I can confirm that this is no longer an issue on Precise (12.04). It shouldn't be unless ubuntu isn't following the ipparam behaviour from upstream. The bug where ipparam was hardcoded was only a problem for xl2tpd-1.2.8 and was fixed in later versions. I have double checked that my ipparam variable is being passed correctly to /etc/ppp/ip-up.d/L2tpIPsecVpn-up.

I have confirmed this on two separate installations.