Community discussions

MikroTik App
 
GiovanniG
Member
Member
Topic Author
Posts: 341
Joined: Sun Nov 15, 2015 4:12 pm

How to deal with MTU size

Mon Mar 27, 2023 2:07 pm

Hi mates, I've 2 mikrotik connected by OVPN, on both sides I have enough bandwith (30mbit client and 100m server), tested with speedtest, but if the client uses OVPN as default route I have no more than 2,5mbit.
I suppose the problem is on MTU and fragmentation packets, on another vpn I saw 1460 bytes, so I ued the same instead of default 1500, but the result isn't changing.

someone may kind me teach how to deal with it?
There exist a site where online I can measure the fragmentation/errors/retrasmissions?
The MTU should be declared the same on both sides?
When I set an MTU less than 1500, tcp protocol (PC Windows who create it) is supposed to find it adapt itself to avoid fragmentation? Does TCP wors like this? (if so, why I have so bad results?)
Thank you
 
fragtion
Member Candidate
Member Candidate
Posts: 257
Joined: Fri Nov 13, 2009 10:08 pm
Location: Johannesburg, South Africa

Re: How to deal with MTU size

Mon Mar 27, 2023 2:29 pm

Step 1: Switch to wireguard
Step 2: Use EOIP tunnel over the wireguard if you need more MTU
That's what I do, and works a treat.. but lots of manual config setup for each tunnel, not very scalable
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 19105
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: How to deal with MTU size

Mon Mar 27, 2023 6:10 pm

Concur!
 
tomislav91
Member
Member
Posts: 303
Joined: Fri May 26, 2017 12:47 pm

Re: How to deal with MTU size

Mon Mar 27, 2023 6:57 pm

Firstly, it's important to note that an MTU of 1460 bytes is generally recommended for OpenVPN connections. However, the MTU should be set to the same value on both sides of the connection.
Regarding measuring fragmentation, errors, and retransmissions, you can use a tool like Wireshark to capture and analyze network traffic. This will give you insight into any issues that may be occurring.
In terms of TCP's behavior with an MTU less than 1500, it will adapt to avoid fragmentation by reducing the size of its segments. However, this can result in decreased performance, especially over high-latency connections like a VPN.

To improve your VPN speeds, you may want to try adjusting your OpenVPN settings, such as enabling compression or changing encryption algorithms. Additionally, you can try adjusting your TCP settings, such as increasing the TCP window size or enabling TCP timestamps.

In terms what you have been proposed about WireGuard:
WireGuard has a simpler codebase and a smaller footprint, which means it is faster and uses fewer system resources than other protocols. It also uses a more modern encryption scheme, which can provide better security while maintaining good performance.
However, switching to WireGuard would require setting up a new VPN connection between your Mikrotik routers, which may involve additional configuration steps. You would also need to ensure that both routers support WireGuard, and that you are using compatible versions of the protocol.

If you are experiencing performance issues with your current VPN connection, it may be worth considering switching to WireGuard. However, you should evaluate the potential benefits against the costs and complexity of setting up a new VPN connection.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to deal with MTU size

Mon Mar 27, 2023 7:08 pm

First of all, you need to discovery the real MTU of your ISP,
for example my clients have all 1500, I config properly pppoe and relative chains
to increase the MTU from the default 1480 / 1492 (that other providers provide) to 1500.

You can use some free programs like mtupath, probably some similar exist on linux & co.
(can be used also the ping with no-fragment flag and inrease ping size until can not reach the other net)

DOS code

mtupath 1.1.1.1

MTU path scan to 1.1.1.1, ttl=64, limit=48
# 16 processing - best MSS 1472 (estimated MTU 1500) [pPPPPpPppPpppppp]
# 01 nearest minimum MTU on local interface

        #1 MSS IN RANGE     1 <==  1471 ==>  1472
        #2 MSS EXCEEDED  1473 <== 14911 ==> 16384
Once you know the real MTU, some sites can have less MTU, or the other end of the connection can have less MTU.
Must be discovered both max MTU of each connection involved.
At that point subtract from the MTU the overhead added from your VPN type, and use that MTU on VPN.
If you use EoIP, for example, for send 1500 packet, you add useless overhead and frills to the network, for not set correctly the right MTU.
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

Re: How to deal with MTU size

Wed Mar 29, 2023 4:09 pm

Step 1: Switch to wireguard
Step 2: Use EOIP tunnel over the wireguard if you need more MTU
That's what I do, and works a treat.. but lots of manual config setup for each tunnel, not very scalable
why would I want EOIP and not IPIP?
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: How to deal with MTU size

Wed Mar 29, 2023 5:33 pm

I think the question was about MTU. Would WG be better than OpenVPN, sure. If using Layer 2 (Ethernet Bridging) with OpenVPN, then you'd also need something like EoIP with WG.

But shouldn't need IPIP with WG however. IPIP is just tunneling Layer 3 though Layer 3, but NOT bridging ethernet. So Layer3 WG alone should be enough. On Mikrotik, you can using routing/NAT/mangle/whatever to WG interface directly which avoids the added overhead of IPIP tunnel. Cases for IPIP, but few and far between, especially on a Mikroitk where you have a lot of control.

I would NOT discount @rextended's example to test your MTU is the critical step. You can do this with a "ping" and setting "do not fragment" to test packet sizes on other OSes (search other forum posts, Google or even ChatGPT for examples). But it the resulting number from these tests that should guide the MTU settings.

If MTU is wrong, things still work – just generally slower, so pretty easy to think MTU is fine until later complaints of "crappy Wi-Fi" because of fragmentation. Why testing MTU is important.
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 11982
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: How to deal with MTU size

Wed Mar 29, 2023 6:06 pm

(and is also important to not obstacle at all ICMP for correct MTU path discovery...)
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: How to deal with MTU size

Wed Mar 29, 2023 6:17 pm

(and is also important to NOT obstacle block/drop at all ICMP for correct MTU path discovery...)
And traceroute will show that – where it stops...ICMP (what "ping" uses) is blocked by that intermediate router's firewall. In Mikrotik default firewall, ICMP is allowed, but very good point here...
 
User avatar
nichky
Forum Guru
Forum Guru
Posts: 1275
Joined: Tue Jun 23, 2015 2:35 pm

Re: How to deal with MTU size

Thu Mar 30, 2023 8:23 am

i will stick with @anav and his example here:

viewtopic.php?t=194310

WG===VxLAN
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: How to deal with MTU size

Thu Mar 30, 2023 9:59 am

Why would VXLAN be better? That would only makes the MTU problems worse, not better... And if L2 isn't needed, a waste.

You don't escape dealing MTUs by switching protocols. You just change the MTU math since the overhead of each protocol is different.

You can calculate the overhead here:
https://baturin.org/tools/encapcalc/

And, the underlying issue here may be OP's WAN has a MTU lower than 1500, which would mean the default value need to be adjusted downward. @rextended's point about not blocking ping/icmp, is that PMTUD will attempt to fix MTU, but that breaks if ICMP is blocked in the firewall.
 
gdanov
Member Candidate
Member Candidate
Posts: 150
Joined: Thu Jan 17, 2019 1:10 pm

Re: How to deal with MTU size

Thu Mar 30, 2023 11:09 am

As I've been dealing with this recently, let me share some experience that backs up most of the advise:
* if MTU is wrong, things work until they don't. In my case everything looked fine until I ran a bandwidth test that fails only on TCP only in one direction
* looking on both sides' value is essential
 
pe1chl
Forum Guru
Forum Guru
Posts: 10195
Joined: Mon Jun 08, 2015 12:09 pm

Re: How to deal with MTU size

Thu Mar 30, 2023 11:39 am

First, indeed you do not want to use an L2 tunnel when you want to use it for routing. The advise to use EoIP is silly.
Furthermore, all tunneling protocols have header overhead and reduce the MTU, but some of them (like OpenVPN) support fragmentation in the VPN protocol itself.
So when you set the "full" 1500 byte MTU on the tunnel, it can transport the packets. Other VPN protocols often cannot, and drop it.
You can make use of this by setting the normal 1500 byte MTU but using a reduced MSS to guide TCP users to use smaller segments.
That way the bulk of your traffic will not incur the processor overhead of fragmentation, but you will not be affected by the problems caused by stupid admins dropping ICMP and thus the users not knowing that their (UDP and other) large packets are being dropped.
Most links do not have many full-size UDP packets, so it still works quite efficiently that way.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 3253
Joined: Sun May 01, 2016 7:12 pm
Location: California

Re: How to deal with MTU size

Thu Mar 30, 2023 5:27 pm

I guess the OP did have questions...

The MTU should be declared the same on both sides?
As noted above, YES – both sides.

When I set an MTU less than 1500, tcp protocol (PC Windows who create it) is supposed to find it adapt itself to avoid fragmentation?
If ping isn't blocked, yes. Otherwise, YMMV. As @pe1chi notes,
You can make use of this by setting the normal 1500 byte MTU but using a reduced MSS to guide TCP users to use smaller segments.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10195
Joined: Mon Jun 08, 2015 12:09 pm

Re: How to deal with MTU size

Thu Mar 30, 2023 7:49 pm

To further clarify:
You can add this mangle rule:
/ip firewall mangle
add action=change-mss chain=forward comment="Change MSS to 1280" \
    new-mss=1280 passthrough=yes protocol=tcp tcp-flags=syn
(or use another value that you like, e.g. 1400. note that MSS has to be at least 40 less than MTU!)

Then, even when you have set MTU to 1500, TCP will adapt itself and use smaller packets.
That works well in combination with a VPN that allows larger packets and does fragmentation, like OpenVPN.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: How to deal with MTU size

Mon Jun 19, 2023 10:35 pm

41 bytes security layer overhead per packet (includes packet tag (1), HMAC-SHA1 signature (20), initialization vector (16), sequence number (4))

28 bytes tunneling overhead per UDP packet (includes IP + UDP header)
OR
40 bytes tunneling overhead per TCP packet (includes IP + TCP header)

so, in conclusion;

openvpn over UDP over IPOE (DHCP/EAP) ; 1500 - 69 = 1431 bytes MAX-MTU
openvpn over TCP over IPOE (DHCP/EAP) ; 1500 - 81 = 1419 bytes MAX-MTU

openvpn over UDP over PPPOE ; 1492 - 69 = 1423 bytes MAX-MTU
openvpn over TCP over PPPOE ; 1492 - 81 = 1411 bytes MAX-MTU

These are for IP over IP. For ethernet over IP you may need to reduce another 14 bytes.

Useful resources;
https://baturin.org/tools/encapcalc/
https://forums.openvpn.net/viewtopic.php?t=15930
https://www.sonicwall.com/support/knowl ... 131319789/
Last edited by volkirik on Wed Jun 21, 2023 10:24 am, edited 2 times in total.
 
volkirik
Member Candidate
Member Candidate
Posts: 208
Joined: Sat Jul 23, 2016 2:03 pm

Re: How to deal with MTU size

Mon Jun 19, 2023 10:45 pm

You will also need to use Routing->Rules instead of firewall mark-routing to be compatible with FAST-TRACKING

For a resource-intensive script, See also; viewtopic.php?p=1001255#p1001255

You may also choose to route all traffic or selected prefixes via OPENVPN, using Routing Rule(s), statically, to save from expensive router resources..

Who is online

Users browsing this forum: EmuAGR, sas2k, truefriendcz and 85 guests