Community discussions

MikroTik App
 
mikruser
Long time Member
Long time Member
Topic Author
Posts: 578
Joined: Wed Jan 16, 2013 6:28 pm

How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:09 pm

Hello,

How to determine the real (actual) MTU of the L2TP+IPsec tunnel?
L2TP have "Max MTU" setting, but it is "fake" MTU.
For example - for L2TP+IPsec tunnel i set too big "Max MTU" =1460, and mturoute show Path MTU =1460. But this is unreal!
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:12 pm

just use ping with the non-fragment flag set and the size 1500, then decrease the size by one until the ping passes
Last edited by rextended on Tue Sep 21, 2021 2:20 pm, edited 1 time in total.
 
mikruser
Long time Member
Long time Member
Topic Author
Posts: 578
Joined: Wed Jan 16, 2013 6:28 pm

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:19 pm

rextender
Noob, don't mess up my threads with your bullshit. First, learn how mturoute works.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:24 pm

rextender
Noob, don't mess up my threads with your bullshit. First, learn how mturoute works.
From the question you ask, I think you are the first who does not know how it works,
and then you are a great rude, no doubt, just the vulgar answers that express how much you do not understand anything.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:29 pm

Another valid program I use on Windows is this, work for both IPv4 and IPv6 addresses
https://www.iea-software.com/products/mtupath/
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 2:43 pm

L2TP add 40Bytes to the standard 1500 and MTU must be reduced to 1460 to avoid fragmentation,
but
adding also IPsec add more Bytes to the packet, and depend by what encryption method are used, but for be sure, 60Bytes

and the final MTU of 1400 can be a reasonable value to set.

But obviously anything between the two machine can reduce for one reason or another, the MTU usable without fragmentation.
 
tdw
Forum Guru
Forum Guru
Posts: 1841
Joined: Sat May 05, 2018 11:55 am

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 4:44 pm

Any AES-based encryption methods work on 16 byte blocks of data so setting an inappropriate MTU can result in up to 15 bytes of redundant padding being included in the encrypted payload, the IPsec integrity check value length depends on the authentication algorithm.

For L2TP/IPsec using AES/SHA-256 without NAT-T and a WAN which has an MTU of 1500 the optimal setting is 1420 (from 20 + 4 + 4 + 16 + 8 + 2 + 2 + 2 + 4 + 1420 + 0 + 1 + 1 + 16 = 1500)

If you have a PPPoE WAN with an MTU of 1492 and/or NAT-T for the IPsec connection the optimal setting is 1404.
 
mikruser
Long time Member
Long time Member
Topic Author
Posts: 578
Joined: Wed Jan 16, 2013 6:28 pm

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 5:02 pm

tdw
My question is why mturoute show incorrect Path MTU?
Looks like the Mikrotik router is fragmenting the packet (even if DF bit set), but does not report about it.
 
tdw
Forum Guru
Forum Guru
Posts: 1841
Joined: Sat May 05, 2018 11:55 am

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 5:47 pm

A quick test sending pings from a Mikrotik through an L2TP/IPsec client interface with DF set works as expected for packet size > L2TP client MTU, which would create multiple IPsec payload packets, however it does appear to generate IP fragments where L2TP client MTU + IPsec overhead > WAN MTU, which would create a single IPsec payload with multiple IP fragments. It could be that the DF bit is not propagated from inner traffic to the outer traffic.
 
mikruser
Long time Member
Long time Member
Topic Author
Posts: 578
Joined: Wed Jan 16, 2013 6:28 pm

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 6:14 pm

tdw
It could be that the DF bit is not propagated from inner traffic to the outer traffic
Oh, i found my very old post about this issue: viewtopic.php?t=109241
Mikrotik fixed this issue for gre tunnels (Dont Fragment:inherit setting), but for l2tp tunnels this issue still not fixed for unknown reason...
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 6:35 pm

rextender
Noob, don't mess up my threads with your bullshit. First, learn how mturoute works.
really rude and with little memory, you don't even remember that you already asked
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11967
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 6:36 pm

From @ZeroByte post_id 542346

This is because the packet is below the inner MTU, thus it is neither discarded nor dropped. The resulting encrypted tunnel packet may exceed the physical interface's MTU, and since the IPSec session is technically not the inner traffic, it is eligible for fragmentation. There's no way around this fact - even if DF was inherited, PMTUD would fail, and here's why:
Hosts A and Z communicate via an encrypted tunnel between routers B and Y.
A sends a DF packet via B, and the packet is larger than the tunnel interface MTU at router B, and router B can send ICMP fragmentation needed message to A, and A can reduce the packet size and retransmit properly.
If A sends a DF packet via B which is small enough to fit the MTU of the tunnel interface, then B doesn't send a message to A because the packet fits. However, when the encrypted packet is built and B then finds that the resulting packet is too large for the physical interface MTU, then B must fragment the tunnel packet - and technically, B could possibly have some stateful information enough to send an ICMP fragmentation required message to A - but this is unlikely already since the IP stack of the physical host will see the crypto engine as the source of the packets, not host A - but let's suppose that it's doable - okay so B can still notify A.
Now let's assume that the inner payload + crypto overhead does not exceed the physical egress interface MTU at router B. Router B will forward the packet to the Internet. Suppose somewhere in the middle of the internet at a link between routers P and Q, the MTU is lower than the B->C link. Even if the DF bit were inherited, router P will see B as the source, not A, so the ICMP message would not reach A for A to lower its MTU.
Even if you were to propose that B should receive these ICMP fragmentation required messages from router P, and figure out which packet caused it and which internal host needs the message, and to adjust the message's reported next-hop MTU from P accounting for the encapsulation overhead, it wouldn't require DF inheritance. It would be easier for B and Y to always use DF on the outer packets and do their own PMTUD and then dynamically adjust the MTU of the tunnel interface.
Thus - if you know the PMTU between your B and Y routers, you should set the MTU of the tunnel to be low enough to not require fragmentation.
 
sindy
Forum Guru
Forum Guru
Posts: 10205
Joined: Mon Dec 04, 2017 9:19 pm

Re: How to determine the real (actual) MTU of the L2TP+IPsec tunnel?

Tue Sep 21, 2021 9:37 pm

Mikrotik fixed this issue for gre tunnels (Dont Fragment:inherit setting), but for l2tp tunnels this issue still not fixed for unknown reason...
The reason is that the PPP standard says nothing about respecting the Don't fragment bit, and Mikrotik choose not to go beyond the requirements of the standard, as someone from Mikrotik staff has explained in the related topic here on the forum.

Who is online

Users browsing this forum: adimihaix, Qalderu and 73 guests