Thank you
Yes as of a few months ago, I get my internet through Verizon 5g home internet. The results of my ping tests (1400 + 28) and their support person response to my inquiry (1428) led me to change my WAN MTU to 1428.
On the VPN side… using proto UDP … if I do nothing with the MTU, nothing works. So then I set mssfix to 1388, and most things seem to work … though there’s the occasional weirdness. (Anything LESS than 1400, AKA… 1399 and under… seems to work in at least some/most cases). I’m going to try 1378 and maybe that’ll fix the outliers.
———————
For my proto UDP tunnel, Im using …
AES 128 GCM
IPv4
(And presumably TCP traffic is sent inside my UDP tunnel … in additional to UDP traffic … right?)
Y’all are AWESOME
Ah yes forgot about wireless internet they have some nuances.
Yes your TCP is encapsulated within the UDP stream. That makes the connection "reliable" (UDP is a non-guaranteed delivery but having TCP within it makes it guaranteed). UDP is used as it is more efficient for encryption, less overhead. In cases of really bad connections, you might have to switch to TCP mode as the tunnel will drop if enough UDP packets are lost, but doesn't sound like you're having that. In that case you'd need to remove another 12 bytes from your MSS size.
mss clamping mechanisms like mssfix actually intercept the TCP handshake and tell both ends the largest TCP packet size to use, basically like NAT for MSS. So the TCP header is already factored in (TCP includes its header when setting its size). So that 20 bytes is already included. Looks like OVPN also automatically calculates in the encryption overhead too and deducts that from whatever you specify. So in reality, you only need to deduct 28 bytes (20 for IP, and 8 for UDP). But they suggest 50, which I'm guessing is so that you can do both IPv4 (20 byte) and IPv6 (40 byte) plus 8 byte UDP and 2 bytes for headroom/padding. If you only plan to use IPv4, you can probably do 28 or 30 less than MTU.
So if your WAN/LAN MTU is set to 1428, and your mssfix is correct, you don't necessarily need to set the Tunnel MTU and OVpn even says best to
not touch it. This is because with properly sized MSS, the MTU of any packet won't exceed the maximum MTU you can support, so that setting is moot. It sort of sounds like Ovpn automatically calculates the Tunnel MTU for you based on MSS (not positive on that, but doesn't matter, even if it is set to 1500, no packet should ever hit that). But the documentation suggests adding the --fragment option "just in case".
So you can try Asus GUI MTU 1428 (note this doesn't change the MTU on wireless interfaces but it does change it on the bridges and uplink to CPU which is enough, since PMTUD nearly always works within a LAN).
mssfix in theory should be able to be 1400 (which will actually tell the endpoints that the MSS is 1384 since I think AES-128-GCM is 16 bytes). Since that isn't working for you, my guess is there is some padding going on, so use 1398 (bad form to use odd numbers). But sounds like you are having some issues with even 1388. My guess is those issues may be related to stuff using protocols other than TCP (mssfix can only intercept TCP, not UDP, ESP, etc) That's what the --fragment option is for, those outliers. So try setting mssfix to 1398 and adding the --fragment option, and see how many packets are getting fragmented. If it is not many, then you should be good, if it is all of them, then you need to go lower.
The fact that 1399 and lower works for "almost everything" sounds like 1398 with --fragment is probably going to be your solution, the --fragment will fix the little bit that isn't working.
Or you can try doing their default "50 less" which would be 1378 and see if that resolves the outliers without the --fragment option. Then add it on anyway just to be safe.
Long story short
I guess you have two options (both using WAN MTU of 1428)
- mssfix of 1378 and see if everything works good with no fragmentation, then add the --fragment option as a "just in case". You'll reduce your throughput some for large files but it won't be a huge difference. You should also be able to use IPv6 over this size if you ever wanted to (who knows, some stuff may be using it and you don't even know it).
- mssfix 1398 with --fragment option and see how many packets are getting fragmented. If it is just a few percent, should be fine and you'll improve throughput and efficiency a bit.
Below is some info for OVPN in UDP tunnel mode (I believe 1473 below is a typo and should be 1478 for IPv4).
--mssfix max
Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed
maxbytes. The default value is
1450.The
max parameter is interpreted in the same way as the
--link-mtu parameter, i.e. the UDP packet size after encapsulation overhead has been added in, but not including the UDP header itself. Resulting packet would be at most 28 bytes larger for IPv4 and 48 bytes for IPv6 (20/40 bytes for IP header and 8 bytes for UDP header). Default value of 1450 allows IPv4 packets to be transmitted over a link with MTU 1473 or higher without IP level fragmentation.
The
--mssfix option only makes sense when you are using the UDP protocol for OpenVPN peer-to-peer communication, i.e.
--proto udp.
--mssfix and
--fragment can be ideally used together, where
--mssfix will try to keep TCP from needing packet fragmentation in the first place, and if big packets come through anyhow (from protocols other than TCP),
--fragment will internally fragment them.
Both
--fragment and
--mssfix are designed to work around cases where Path MTU discovery is broken on the network path between OpenVPN peers.
The usual symptom of such a breakdown is an OpenVPN connection which successfully starts, but then stalls during active usage.
