I have a Mikrotik L2TP client that connects to a Mikrotik L2TP server where a number of other Mikrotik L2TP clients connect and they work perfectly.
This L2TP client connects to the ISP via PPPoE ane the L2TP session connects successfully. Basically my setup works the way the computer at the L2TP server’s location uses L2TP client’s LAN IP as a default gateway. The computer’s port is in the same bridge as the L2TP client and this works for 8 other setups. I just can’t figure out why it doesn’t work here. After reading a lot, I assume it could be linked with PPPoE MTU (1480), but I have decreased the L2TP client’s MTU to 1480 (from 1500) with no success.
I have disabled fasttrack, disabled all the firewall rules on the client L2TP Mikrotik, except the one allowing me to connect to it via its’ WAN IP address, even the management’s interface login form when I connect through it’s LAN IP address doesn’t even load. Sometimes it does, but most of the time some those images (terminal, etc.) at the bottom don’t show up.
When I connect to the router via WAN IP, the interface works. I have changed Mikrotik to no success, also the ISP changed their modem with no success
Basically, I am lost and any ideas would be highly appreciated.
msatter, thank you very much, that solved the TCP communication. I still seem to have some issues with access to the web interface, but the TCP through 10.7.0.1 works from the server. I will report back if this remains as I think this might be connected to another issue.
As you are using BCP to provide a L2 connection you could use MRRU on the L2TP server and client so full ethernet frames are handled correctly, rather than resorting to mangling the MSS.
I have set MTU, MRU and MRRU and now everything works!
It’s still bugging me… I have exactly the same setup (same ISP, PPPoE, same modem type, L2TP, Mikrotik, but another firmware there) on a different location and everything works there without any required changes to MTU…
Likely something different in the firmware then, RouterOS has handled MSS clamping differently over the years.
The usual figure I’ve seen quoted for MRRU is 1600 which should be plenty for 1500-byte ethernet plus the encapsulation overheads. The other MTU/MRU values are less critical, but are ideally optimised so intermediate encapsulation are not also fragmented - this can be tricky with IPsec as the encryption used changes the overhead.
If the ISP doesn’t support baby-jumbo ethernet packets to support 1508 byte MRU/MTU (i.e. 1500 bytes for the PPPoE payload) the usual MRU/MTU setting is 1492. The tricky one is the L2TP MRU/MTU which needs to be WAN MRT/MTU - IPsec encapsulation overhead - L2TP encapsulation overhead - if it is set to a figure greater than this a full 1500-byte payload will generate three rather than the optimal two fragmented packets.
I have solved this by actually dealing with one of my ISP’s engineers who also runs on MikroTik equipment. At the time we were testing RFC4638, which is now working successfully.
So when you are running PPPoE on an ethernet interface, set the MTU of that particular ethernet interface to 1520 like this:
Now inside the PPPoE client, you do leave MTU,MRU,MRRU blank, ROS will auto-detect like this:
And finally, keep in mind that most vendors (I have seen on Cisco, Juniper, MikroTik) will automatically accept request for 1500 MRU from the client side, so double the benefits.
As you can see, I am actually getting 1500 correctly on the PPPoE client.
Inside PPP profile, enable TCP MSS clamping if auto-detected actual MTU on the PPPoE client is less than 1500, disable TCP MSS clamping if auto-detected actual MTU is 1500 or greater. But you don’t actually need TCP MSS clamping if the correct value is set on the outgoing interface which is what my guide will accomplish.
Now just set the detected actual MTU value as the same for the L2TP.
