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
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
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.
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)
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.
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.
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...
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.
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
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.
(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.
You may also choose to route all traffic or selected prefixes via OPENVPN, using Routing Rule(s), statically, to save from expensive router resources..