PSA: Check your MSS settings on WG interfaces.
-
I’ve been working on an issue for weeks now that presented as weird TCP issues...some websites wouldn’t load or would particularly load, or wouldn’t load over TLS but would load http non-tls just fine.
Check your mss settings. Start with a value of 1420 in the GUI, assuming your WG interfaces are at the default of MTU of 1420 (which is chosen because most outer tunnel connections are 1500.
An mss clamp really should be enabled by default on WG interfaces imo
-
@vbman213 There's a good article on the sizing of the Wireguard packets in a recent netgate blog post: https://www.netgate.com/blog/wireguard-in-pfsense-2-5-performance.html
In Netgate's testing 1420 would be suggested for IPv4 and 1380 for IPv6.
-
@dma_pf correct, the default on all WireGuard implementations is 1420 MTU. However because my tunnel was sitting in the middle with 1500 MTU on either side, funny things were going on. It’s also important to clamp the maximum segment size otherwise you’ll get packet loss.
[server1]<——1500—->router1——1420—->router2<——1500—->[server2]
-
@vbman213 said in PSA: Check your MSS settings on WG interfaces.:
It’s also important to clamp the maximum segment size otherwise you’ll get packet loss.
[server1]<——1500—->router1——1420—->router2<——1500—->[server2]
You've raised an interesting point here that I've been thinking about but do not have clear in my head.
Let's say that I have a peer, a computer in the office. It's sending a packet to a remote server over a site-to-site Wireguard tunnel. Both sides of the tunnel have pfSense. The packet is leaving the peer at on the way to the Wiregurad tunnel at the LAN default of 1500.
On both on both sides of the tunnel I have interfaces established for the Wiregurad tunnels. I only use IPv4, so based on the article I posted, I have set the MSS to 1420 on both of those interfaces. My understanding is that Wireguard can pass 1500 packets and in this way the data payload would be limited to the 1420 and with the overhead the packet would total 1500. Therefore there shouldn't be any fragmentation.
But what I can't get my head around is what is happening with the extra data payload from the original 1500 data packet from the peer. Obviously the original data payload from the peer is bigger than the 1420 being used by the Wireguard tunnel. So that original data payload has to be fragmented in order to to send it over the tunnel. What happens to that original fragmented peer data payload? Does that now mean that some packets are going across the Wireguard tunnel as with smaller data packets than the 1420? Is there anything that should be done to maximize the flow of those fragmented packets across the tunnel (limiters, traffic shaping)?
-
@rcmcdonald91 said in PSA: Check your MSS settings on WG interfaces.:
I’ve been working on an issue for weeks now that presented as weird TCP issues...some websites wouldn’t load or would particularly load, or wouldn’t load over TLS but would load http non-tls just fine.
Check your mss settings. Start with a value of 1420 in the GUI, assuming your WG interfaces are at the default of MTU of 1420 (which is chosen because most outer tunnel connections are 1500.
An mss clamp really should be enabled by default on WG interfaces imo
can you explain to a dummy like me, MSS settings where? WG interface? My WAN interface? both?
-
@dirtyfreebooter The WG Interface:
-
@dem
Do I need to make any changes on the client side as well, like defining an MTU, or are the changes you show above for the MSS in the wg0 interface page enough? -
@keshav I haven't done enough testing to be certain that this change handles all cases, but this is the change @rcmcdonald91 is suggesting above.
-
@dem would be a good option like Ovpn does with the parameter mtu-test, regards!!!
