Why does L2TP-Client+IPSec on MikroTik hEX RB750Gr3 work differently depending on the type of Internet connection?

Question

Mikrotik

Given: L2TP Server on D-Link DFL-260E (with static white IP).
MikroTik hEX RB750Gr3, firmware 6.42.7, with configured L2tp-client (l2tp-out1).
Modem Megafon M150-2 (firmware stick, defined as ppp-out1 interface, not LTE).
Configuration 1:
We connect the megaphone modem to Mikrotik's USB port (directly, without extension cords), the ppp-out1 connection works, the Internet on the computer works (there is a NAT rule for ppp_out1).
l2tp-out1 connects and works, but slowly. Pings to the server go without loss.
Configured rules in IP - Routes for direct packets to the l2tp server.
Packet Sniffer + Wireshark does not show anything particularly suspicious on the ppp-out1 interface, but on l2tp-out1,
shows a lot of "TCP Dup ACK" and "TCP Retransmissions".
Configuration 2:
Everything is exactly the same as in configuration 1, except for the method of connecting to the Internet.
We use an intermediate router TP-Link TL-MR3420.
We connect the same megaphone modem to the TP-Link USB port,
from TP-Link a twisted pair cable to the microtic's ether1 port (there is also a NAT rule for the ether1 port).
l2tp connects and works much faster than in the first configuration, only occasional TCP Retransmission skips in Wireshark.
The problem is that there is a program that, when launched, connects to the MSSQL database through the l2tp + ipsec tunnel, and this
connection does not want to work stably on the 1st configuration.
For several weeks of various experiments, everything that Yandex and Google advised was tested.
Different MikroTik devices were used, but the same model RB750Gr3.
Different modems were used (MTS, Rostelecom, 3G, 4G).
Change MTU/MRU/MRRU on both ppp-out and l2tp-out interfaces, change MSS (enable/disable in PPP profiles, create rules in Mangle), change TTL. Disabling all rules in the Firewall. Wrapping L2TP traffic in NAT. And many more experiments. Problem still exists.

Answer 1

Most likely, your MTU is not the one you need - for example, my PPPoe eats another 20 from MTU and with an IPSec tunnel MTU 1436 is already. (True, I have Mikrotik on both sides)
And with the intermediate TP-Link Mikrotik, it’s not the packets that are fragmented by Mikrotik, but the TP-link, which is why it works.
Try on Mikrotik go to tools - ping and pervert to send packets:

Ping To — 8.8.8.8	
Interface — PPP_out1
ARP Ping — Нет
Packet Count — 5
Advanced:
Packet Size — 1480
Dont Fragment — Да

if 1480 passes, but 1481 does not (Packet too large... ...Fragmentation needed) - then PPP_out eats 20 from MTU
Further, the same thing, but aim (Ping To) at the internal resource (DB Server) for L2TP (Interface - l2tp -out1) and reduce the packet size until Packet too large is gone. Then you will find out which MTU will definitely fly through L2TP and your PPP without any problems.
PS: those who know, please do not throw slippers =)

Answer 2

MTU is the first thing I started experimenting with.
Mikrotik itself, by default, sets the following MTUs:
For configuration 1:
ppp - max mtu 1460, actual mtu 1460, this is also confirmed and with Ping, 1461 already issues a fragmentation need.
l2tp - max mtu 1450, actual mtu 1376, respectively, Ping from 1376 passes, but from 1377 it does not.
For configuration 2:
ether1 - max mtu and actual mtu 1500.
l2tp - actual mtu as before 1376.
During the experiments, I tried many different values, even the minimum possible for MTU (512), this does not change the situation. I created a rule with change mss clamp to pmtu, it also had no effect.
Mikrotik processor load in both options, during the passage of traffic via l2tp, 0-1%.
As far as I understand the situation, packets are lost precisely in the l2tp tunnel, while nothing is lost on the ppp interface, the Internet on a computer connected to this microtic works quite well.
If you disable l2tp in Mikrotik in the first configuration and programmatically create an l2tp client in windows, then there is no problem, everything works quickly and without errors.

Answer 3

Similar problems recently began (about half a year as) on an iota ... Only the transition to OVPN helped.
The only thing is that it's strange that it works normally through TPLink, it looks like it really is MTU or somewhere here ... Or Mikrotik bugged modems again ...