A L2TP bug of ten years

RouterOS General
1

when the L2TP and CLIENT is working well （ MT device routeboard、 x86、 CCR、CHR ）

In many cases, for example:
1、server or client network Abnormal disconnection
2、server or client reboot
3、server enalbe → disable → enalbe
that will make the client can‘t connect to the server anymore。

log like
client：
08:59:02 l2tp,ppp,info l2tp-bcp-client: terminating… - session closed
08:59:02 l2tp,ppp,info l2tp-bcp-client: disconnected
08:59:02 l2tp,ppp,info l2tp-bcp-client: terminating… - session closed
08:59:02 l2tp,ppp,info l2tp-bcp-client: disconnected
08:59:02 l2tp,ppp,info l2tp-bcp-client: terminating… - old tunnel was not close yet
08:59:02 l2tp,ppp,info l2tp-bcp-client: disconnected
08:59:02 l2tp,ppp,info l2tp-bcp-client: terminating… - old tunnel was not close yet
08:59:02 l2tp,ppp,info l2tp-bcp-client: disconnected

server：
first L2TP UDP packet form ...
first L2TP UDP packet form ...
first L2TP UDP packet form ...

maybe hours or days later, it can resume; or reboot the server and client many times may fix it

help!

2

if the server in trouble, it always make the l2tp-client of itself error, when it’s l2tp-client try to connect to other server ,will log:

15:45:36 l2tp,ppp,info l2tp-to-a5: terminating… - session closed
15:45:36 l2tp,ppp,info l2tp-to-a5: disconnected
15:45:36 l2tp,ppp,info l2tp-to-a5: initializing…
15:45:36 l2tp,ppp,info l2tp-to-a5: connecting…
15:45:41 l2tp,ppp,info l2tp-to-a5: terminating…

the other server log:
15:45:35 l2tp,info first L2TP UDP packet received from 5*..
15:45:36 l2tp,info first L2TP UDP packet received from 5*..
15:45:37 l2tp,info first L2TP UDP packet received from 5*..
15:45:38 l2tp,info first L2TP UDP packet received from 5*..
……

this time, my l2tp-server is in trouble for 3 days , and still in trouble ~~~

3

I have never seen that, and I have quite some L2TP setups. Although always over IPsec. But I don’t think that should affect this.
I have several L2TP clients that operate over 4G sticks that get a new IP address every day or every 8 hours, and of course at that time they lose the connection.
But they always come back flawlessly.

So there must be something particular to your configuration that makes this fail (e.g. firewall setup?).

4

I can confirm that many Android VPN-s end like that.
This is very common errors.
Rememer that now is very important fix when users connect vpn from the same NAT.

5

There is no fix on this as nothing is broken - it’s built into the LT2P/IPsec design that this doesn’t work. Details and workaround here.

6

THKS

In most cases, there is no problem, including clients using broadband or 4G as you do. After disconnection and reconnection, they can recover automatically. However, some nodes often have problems, even if they have never had problems before

And I’m sure I don’t have any firewall rights

7

I only encounter the connection problem between routers, other clients such as Android or windows have not encountered ,it is not about nat, just router to router

8

This “logs” we see when

  • user use ISP with IPv6 only and your L2TP Server use IPv4 only - user when start using a dns name then ipv6->4 start works proper and can connect thatns your name like vpn.consanto.com
  • users with windows and broken L2TP have #789 and sometimes they must only recreate vpn, or reinstall L2TP&IP Miniwan’s…
  • Some Android phones have that problem as indywidual phones, when ISP or Android not give new rel. then use a “Finder Firmware” all to update them, and they start works.

I know that problems only when stg. is not right at customer end-user site.