Strange behavior of PPP/PPTP service on CHR.

RouterOS General
1

“Sorry for my English, it is not my native language”

We use PPTP VPN, there is a central (Rc router) router, routers from remote offices are connected to it
Periodically (several times a day, on average) VPNs are disconnected at offices, although their Internet connection works fine and there is a connection to Rc.
After VPN shutdown, the router from the remote office immediately reconnects and works on until the next disconnect.

When the connection to one of the offices falls, other VPN connections work fine. Then they will also turn off, each in its own random time.

This problem has always been, it does not directly depend on the version of RouterOS, but it seems that the more offices are connected, the more often it happens for everyone.


I made a debug of the moment the VPN connection of one of the remote offices fell (Rr1 router), on routers it looks like this:

  1. Rc - Virtual Machine with CHR (x86_64) P1 License, RouterOS v6.46.4

Office VPN interfaces are created dynamically, tried with static ones - there is no difference, breaks continue.

At the time of falling On Rc:
Internet works, other VPN connections work fine too
The average external traffic is less than 20 Mbit / s, the average processor load is less than 10%

Rc Log (cutting only about this connection):
—Rc Log----
Jun 19 13:30:33 Rc pptp,ppp,debug,packet debug: <35004>: sent LCP EchoReq id=0x0
Jun 19 13:30:33 Rc pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:34 Rc pptp,ppp,debug debug: <35004>: LCP missed echo reply
Jun 19 13:30:34 Rc pptp,ppp,debug,packet debug: <35004>: sent LCP EchoReq id=0x1
Jun 19 13:30:34 Rc pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:35 Rc pptp,ppp,debug debug: <35004>: LCP missed echo reply
Jun 19 13:30:35 Rc pptp,ppp,debug,packet debug: <35004>: sent LCP EchoReq id=0x2
Jun 19 13:30:35 Rc pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:36 Rc pptp,ppp,debug debug: <35004>: LCP missed echo reply
Jun 19 13:30:36 Rc pptp,ppp,debug,packet debug: <35004>: sent LCP EchoReq id=0x3
Jun 19 13:30:36 Rc pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:37 Rc pptp,ppp,debug debug: <35004>: LCP missed echo reply
Jun 19 13:30:37 Rc pptp,ppp,debug,packet debug: <35004>: sent LCP EchoReq id=0x4
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: LCP missed echo reply
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: LCP lowerdown
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: LCP closed
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: CCP lowerdown
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: CCP closed
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: BCP lowerdown
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: BCP down event in starting state
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: IPCP lowerdown
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: IPCP closed
Jun 19 13:30:38 Rc pptp,ppp,debug debug: <35004>: IPV6CP lowerdown
—Rc Log----

We see that at some point the VPN connection from Rr1 stops flowing, Rc sends five LCP Requests, does not receive responses within a second and closes the connection.


2) At the same moment on Rr1

At the time of falling on Rr1:
Internet is working.
The average external traffic is less than 0.5 Mbit / s, the average processor load is less than 10%
Problems doesn’t depends of router model and OS version

----Rr1 Log-----
Jun 19 13:30:33 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: rcvd LCP EchoReq id=0x0
Jun 19 13:30:33 Rr1 pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:33 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: sent LCP EchoRep id=0x0
Jun 19 13:30:33 Rr1 pptp,ppp,debug,packet debug: <magic 0x2068982a>
Jun 19 13:30:34 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: rcvd LCP EchoReq id=0x1
Jun 19 13:30:34 Rr1 pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:34 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: sent LCP EchoRep id=0x1
Jun 19 13:30:34 Rr1 pptp,ppp,debug,packet debug: <magic 0x2068982a>
Jun 19 13:30:35 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: rcvd LCP EchoReq id=0x2
Jun 19 13:30:35 Rr1 pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:35 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: sent LCP EchoRep id=0x2
Jun 19 13:30:35 Rr1 pptp,ppp,debug,packet debug: <magic 0x2068982a>
Jun 19 13:30:36 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: rcvd LCP EchoReq id=0x3
Jun 19 13:30:36 Rr1 pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:36 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: sent LCP EchoRep id=0x3
Jun 19 13:30:36 Rr1 pptp,ppp,debug,packet debug: <magic 0x2068982a>
Jun 19 13:30:37 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: rcvd LCP EchoReq id=0x4
Jun 19 13:30:37 Rr1 pptp,ppp,debug,packet debug: <magic 0x5b12475e>
Jun 19 13:30:37 Rr1 pptp,ppp,debug,packet debug: pptp-out-axpl: sent LCP EchoRep id=0x4
Jun 19 13:30:37 Rr1 pptp,ppp,debug,packet debug: <magic 0x2068982a>
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: LCP lowerdown
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: LCP closed
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: CCP lowerdown
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: CCP closed
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: BCP lowerdown
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: BCP down event in starting state
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: IPCP lowerdown
Jun 19 13:30:38 Rr1 pptp,ppp,debug debug: pptp-out-axpl: IPCP closed
----Rr1 Log-----

We see that the router receives LCP Requests (Req-magic matches) from Rc, sends an LCP Replies. Those. he receives five LCP Request,
answers them, but Rc no longer receives these answers.


3) However, this is not the case if you look at a dump of external traffic on a central Rc

The dump is taken from Rc itself using the “Packet Sniffer”, i.e. this traffic definitely got to the router.

See Rc_req.jpg, Rc_rep.jpg

We see that traffic is exchanged, we see all five LCR request and LCP Reply to them, magics are match (only for some reason inverted), the answers came in less than 10 ms, but for some reason the PPP/PPTP Service on the Rc router didn’t see this traffic, it thought that the remote Rr1 didn’t answer him and broke the VPN connection, although, in fact, the traffic to the router came.

Reconnection occurs immediately and then the VPN works fine until the next similar problem.
Other VPNs, at the time of the fall of one, work fine.

It looks like at some point, for some reason, the PPP/PPTP service on the Rc router stops receiving traffic and disconnects, although the traffic was definitely coming to it, including and all five LCR responses.

P.S. Tried with L2TP, such problems are not observed.


The questions are:
Why can this happen?
Maybe this is some known issue in Mikrotik PPP / PPTP routers?

Is there any way to fix this?
Rc_rep.jpg
Rc_req.jpg

2

It might be related to handling of GRE in Mikrotik firewall where a vulnerability has been fixed a few ROS versions ago, but that fix has brought some issues. So if one of the clients has a fixed IP address, it may be worth trying to add a rule chain=input src-address=ip.of.that.client protocol=gre action=accept before (above) the chain=input connection-state=invalid action=drop one. If that client stops having issues after doing so, the connection tracking in firewall has some additional issue with GRE. If it changes nothing, it looks like an issue of the PPTP stack itself.

Other than that, PPTP security has not been considered strong enough since long ago; if you substitute it by plain L2TP without IPsec, you get about the same security as the same MPPE is used for encryption in both cases. So it is better to use L2TP over IPsec, but once you touch IPsec, it is even better to leave out the L2TP part, saving some overhead bytes and allowing to use certificate-based authentication and IKEv2 (and maybe some other tunneling protocol if you’re afraid of drowning in the policy-based routing used by bare IPsec).

3

Thank you for answer, a will add firewall rules, like you adviced.

4

Sorry to resurrect this. Over the last couple of months have been having the exact same issue. Did you resolve the problem? if so what did you do?

5

can you show your firewall rules to see if there is a track ?