Wireguard - wrong MSS

RouterOS Beginner Basics
1

Hello, I’m experimenting with Wireguard on 7.2 and noticed some strange issues: Mikrotik sends too big mss and requests to lower it later with icmp unreachable.

  1. Server has MSS = 1420.

Mikrotik configuration

/interface wireguard
add listen-port=51820 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=-snip- endpoint-port=51820 interface=wireguard1 persistent-keepalive=15s public-key="RvCiqqxCP3PD43ttnsoRNJsvDzs1Rb/IrRguzcpp6G4="

However, when I try to make a tcp connection this very Mikrotik sends mss 1460, that fails to pass server’s 1420:

20:10:13.877083 IP -snip-55118 > 151.101.65.67.https: Flags [S], seq 3727460725, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 3017899 ecr 0], length 0

resulting in

20:10:13.952138 IP 151.101.65.67.https > -snip-: Flags [P.], seq 1449:2897, ack 518, win 285, options [nop,nop,TS val 3508144898 ecr 3017968], length 1448
20:10:13.952146 IP -snip- > 151.101.65.67: ICMP -snip- unreachable - need to frag (mtu 1420), length 176

This issue needs mangle rule to work correctly, however, maybe other methods exists?
Any client side MTU on wireguard1 is effectively ignored, packets are still mss=1460. On the other side, bumping wireguard interface to 1500 on server works, but with horrible performance, as everyhing is fragmented to hell.

2

No, it has an MTU of 1420. Max TCP MSS = path MTU - 40. Details…


However, when I try to make a tcp connection this very Mikrotik sends mss 1460, that fails to pass server’s 1420:

MTU vs MSS terminology aside, simply configuring the MTU on the router doesn’t change anything about the client’s configuration. It doesn’t get copied back into the client’s network stack or anything. All it does is says what the MTU at the router is, not about what MTU is to either side.


lower it later with icmp unreachable.

Yes, that’s a feature of TCP called PMTUD. From what you’ve shown, it may well be operating precisely as intended.


This issue needs mangle rule to work correctly

Applying a change-mss rule like the following saves the round-trip times required for PMTUD to work, and it can solve problems with components in the middle preventing PMTUD from working properly in the first place:


/ip firewall mangle add out-interface=wireguard1 protocol=tcp tcp-flags=syn action=change-mss new-mss=1380 chain=forward tcp-mss=1381-65535

1380 = your 1420 MTU - 40.


maybe other methods exists?

I suppose you could go around to all of your clients and set MTU to 1420. I wouldn’t recommend it, but you asked for alternatives. :slight_smile:


everyhing is fragmented to hell.

It shouldn’t be. If PMTUD is working properly, it occurs in the first few packets of a TCP session, fixing the problem from that point forward. However:

  1. It’s per TCP connection since each may take a different path, so the stack can’t reuse what it discovers on one connection with another. If you have many TCP connections (e.g. a modern fat web site with 100+ resources on a single page and no HTTP pipelining) you pay that round-trip overhead of PMTUD per conn.

  2. PMTUD might be broken somewhere along the path between your client and the server.

3

What is the setting for MTU on the server?

Why not ensure that Server and Router have the same settings!!
On the WIREGUARD interface definition there is an entry there for MTU.
What about on your server>>>’

Ahh, I see, It has MSS but not MTU and MTU is MSS-40??

Interesting trying playing with the numbers.

1420MTU 1460mss
1460MTU 1500mss
1500MTU 1540mss

and then down
1400MTU 1440mss
1380MTU and 1420mss

4

Advice I see from other threads.

  1. Do not block ICMP !!