Hello all,
searched online first but couldn’t find much besides old discussions about v6 and unanswered topics like: http://forum.mikrotik.com/t/tcp-clamp-or-clamp-to-pmtu/104666/1
I’ve seen some recommendations that suggest lowering TCP MSS, especially for VPNs like WireGuard that can’t handle PMTU;
It seems to me that the first solution is applicable where you know the exact calculated MTU, and the second is applicable on different VPN services or MTU values (like having one client running IPv4 only and another IPv6).
What are your thoughts on this?
Thanks!
The first example is used when one hop along the path, not controlled by you, has a lower MTU and path MTU discovery is blocked.
The second example can be used on the router, controlled by you, that is at the edge of the path with the lower MTU.
Thanks @mrz, for using easy words,
first case: Wireguard used on MT router on one side, PC client on other side, the hop with PMTU blocked could be between the PC and the router.
second case: Wireguard used on both MT routers as site-to-site.
Sounds good examples?
clamp-to-pmtu is reducing MTU for each connection passing through the interface?
But “clamp-to-pmtu” on a local interface should get you the RourerOS interface’s MTU less TCP’s 40 bytes. So for WG with 1420 MTU, setting new-mss to “clamp-to-pmtu”, should result in a 1380. So explicitly setting new-mss=1380 should be same as new-mss=clamp-to-pmtu with WG defaults. The issue with explicitly setting new-mss= is that it always sets the specified value - even if MSS is already lower – that’s why the examples uses “tcp-mss=<new-mss + 1>-65535” filter so that SYN packets with a lower MSS are NOT modified.
What I’m still trying to figure is,
if using clamp-to-pmtu to an interface list, every packet/connection is reduced to the appropriate MTU?
Let’s say we have a main WireGuard client (as server) connected to other WireGuard clients (router or PC) having different MTU values, this roule fits all?
My understanding is, at least for wireguard, if your router is the client for handshake, typically to 3rd party providers, then
one can use either of these two settings, and depending upon the provider one may work better than the other. I have not heard of adding this setting to the Server (for handshake) router.
add action=change-mss chain=forward comment=“Clamp MSS to PMTU for Outgoing packets” new-mss=clamp-to-pmtu out-interface=wireguard1 passthrough=yes protocol=tcp tcp-flags=syn
OR add action=change-mss chain=forward new-mss=1380 out-interface=wireguard1 protocol=tcp tcp-flags=syn tcp-mss=1381-65535
This all assumes the WAN used by WG on BOTH sides is 1500 MTU. It “most of the time” is 1500, so WG’s 1420 MTU is right. But… for example, some PPPoE deployments might uses 1492 as MTU - which mean WG should be lower by 8 bytes… This then effects the “manual” way of specify the MSS using the “action=change-mss” method have to use “new-mss=1372.” - while “action=clamp-to-pmtu” should “do the math” for you from the configured MTU.
Yes*. But MSS likely to not require adjustment vast majority of cases, since if icmp/“ping” is not blocked MTU will be discovered automatically. And, if MSS is set wrong (too high), you may have worse problems than fragmentation. Why I think “clamp-to-pmtu” is generally a “better” approach… since you cover the case if the MTU is lower elsewhere (at least for TCP traffic), the “clamp-to-mss” rule should not increase the MSS - which be bad. While the “set-mss”, I believe, would adjust it higher since it ignores any PMTUD calculation & just apply the rule to set MSS to a specific value.
*Technical point, MSS is based on the MTU. So the MTU is not adjusted, just the “MSS” field within TCP SYN packets is changed. So stuff like UDP is not affected.
The rule of thumb when controlling both ends IS to match MTU, I think the default is 1420 not 1500 on the MT.
In any case, if one know the MTU setting at the other end, the first thing to try is matching it on the MT.
Then the rules above.
They recommend the follow “linux command”: iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu
which is cousin of RouterOS: /ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn action=change-mss new-mss=clamp-to-pmtu out-interface-list=VPN
Now ProCustodibus using SYN+RST in their example, I’d can’t say if that is also needed but basically same. Anyway that article above put more meat on this topic.
The rule of thumb when controlling both ends IS to match MTU, I think the default is 1420 not 1500 on the MT.
Correct. RouterOS does use 1420 as default for WG interfaces, same as default on Linux. And, default for ethernet WAN is 1500. So if the ENTIRE PATH is 1500 MTU, then MSS will always be right, by default. The real world is messy,
Yup, 100% agree. Get the MTU right FIRST on BOTH the WG interface & “WAN” interface. If these are correct, then the action=clamp-to-pmtu should work