[flarecoder]

Just curious if MSS or PMTU blocking has anything to do with the problem.

In the 2 different Wireshark dumps, a relevant difference is MSS=1460 and MSS=1380 in the second one.

I'd recommend setting the local NIC MTU to a low value just to see if it has an impact. However, the Wireshark dump doesn't show packet fragmentation, so perhaps this isn't a problem at all?

[flarecoder]

Some random links about PMTU issues: https://www.znep.com/~marcs/mtu/ https://serverfault.com/questions/1050567/why-does-setting-m... https://serverfault.com/questions/126468/mtu-dsl-router-and-... https://serverfault.com/questions/162062/how-to-check-who-bl...

[t0mas88]

This is quite a common issue with PPPoE connections like the one OP seems to use with his own router. You need to increase the MTU of the physical underlying ethernet connection to 1508 to allow a 1500 MTU for the encapsulated packets inside the PPPoE tunnel. Otherwise you'll run into weird issues and unreachable websites.

[toast0]

You also need to make changes on the PPPoE server, which is hard because if a provider is running PPPoE in 2023, they probably don't care about doing things well (but maybe I'm just bitter about CenturyLink)

I have a browser based mtu test http://pmtud.enslaves.us/

Currently IPv4 only, requires a somewhat recent browser, and client to server testing is iffy, but if you start the test and get OK in the notes field for both directions, your MTU settings are probably fine (or something is doing proper mss clamping between your client and my server, my server is limited to 1500 MTU so problems with jumbograms can't be detected)

[lxgr]

Increasing the MTU at the sender side to something >1500 is not a great idea. It’s unlikely that the path will support 1508 byte end-to-end.

A better idea would be to reduce the MSS inside the tunnel.

[kungpao42]

+1 ^^ This

Set MTU on affected systems to 1400 or implement MSS clamping via firewall, etc.