0

I run CentOS 6.4 on Amazon EC2, using xl2tpd-1.3.1 from EPEL repository together with StrongSwan 5.0.4.

I setup a simple IPSec connection:

conn l2tp
    type=transport
    keyexchange=ikev1
    rekey=no
    authby=psk
    leftsubnet=0.0.0.0/0
    rightsubnet=0.0.0.0/0
    compress=yes
    auto=add

And here is xl2tpd.conf:

[global]
ipsec saref = yes

[lns default]
ip range = 192.168.0.2-192.168.0.250
local ip = 192.168.0.1
ppp debug = yes
pppoptfile = /etc/ppp/options.xl2tpd
length bit = yes

Here is options.xl2tpd:

ms-dns 8.8.4.4
auth
lock
debug
proxyarp

There is only one client - Android 4.2

Android connects successfully:

Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Connection established to x.x.x.x, 59578.  Local: 18934, Remote: 29291 (ref=0/0).  LNS session is 'default'
Oct 27 19:45:02 ip-172-31-17-30 xl2tpd[2706]: Call established with x.x.x.x, Local: 36452, Remote: 29845, Serial: -1369754322
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: pppd 2.4.5 started by howard, uid 0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Using interface ppp0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Connect: ppp0 <--> /dev/pts/0
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: peer from calling number x.x.x.x authorized
Oct 27 19:45:02 ip-172-31-17-30 pppd[2709]: Deflate (15) compression enabled
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: Cannot determine ethernet address for proxy ARP
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: local  IP address 192.168.0.1
Oct 27 19:45:03 ip-172-31-17-30 pppd[2709]: remote IP address 192.168.0.2
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 disappeared from ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] 192.168.0.1 appeared on ppp0
Oct 27 19:45:03 ip-172-31-17-30 charon: 06[KNL] interface ppp0 activated

In the meanwhile, Internet works perfectly on the Android client, the VPN connection is stable and fast.

However, it always happens that within 2-5 minutes after the connection is established:

Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Maximum retries exceeded for tunnel 18934.  Closing.
Oct 27 19:47:07 ip-172-31-17-30 xl2tpd[2706]: Connection 29291 closed to 95.91.227.224, port 59578 (Timeout)
Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deactivated
Oct 27 19:47:07 ip-172-31-17-30 charon: 06[KNL] interface ppp0 deleted

Then the VPN connection is broken.

So what might have gone wrong?

The same L2TP service works flawlessly on iOS 7, MacOS 10.8, and Windows 7, there is no disconnection issue on those OSes.

Thank you!

1
  • I've met the similar problem, but it is my windows client that was unstable, but ios/osx/ios/android are ok
    – lichenbo
    Jul 29, 2015 at 1:56

1 Answer 1

0

After nearly a month of debugging effort, I still cannot give a definitive answer to the problem, but there is a workaround.

In the original issue, the Android client appears to always request tunnel twice - "peer requested tunnel xxx twice", but it does not happen on other clients (MacOS, Macbook, Windows 7, iOS).

In the source code, xl2tpd kills a tunnel if retransmission counter reaches certain threshold, it logs a message saying "Maximum retries exceeded for tunnel xxx" then hangs up on PPP connection.

But the problem is: for whatever reason, the tunnel is the actively used tunnel, so hanging it up means terminating Android's L2TP connection.

So I ended up forking xl2tpd version 1.3.1 to https://github.com/HouzuoGuo/xl2tpd in branch 1.3.1. With my fixes, xl2tpd no longer kills tunnel on "maximum retries exceeded", it simply logs a message and moves on.

All clients are now happy, Android no longer disconnects and the same configuration still works beautifully on MacOS/iOS/Windows 7.

By the way, xl2tpd 1.3.2 has been released, but according to my tests, it does not work with Android at all:

  • Scheduler responsible for calculating select() timeout yields a timeout too short (sub second), resulting in lots of network timeouts and Android L2TP connection cannot be established in-time.
  • Even if the select() timeout is manually changed (to 5 or 10 seconds), the "peer requested tunnel xxx twice" problem not only exists, but it gets worse - Android cannot establish a connection at all.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .