The proper way to deal with the PMTUD issues is not to change MTU on either side, but rather to make sure you do not drop (block) ICMP messages that should not be dropped. A rather widespread workaround is to use TCP MSS clamping on the router (which some people consider an ugly hack- and for a reason).
The problem is that even when you do not drop ICMP messages yourself, there may be other places in the network towards the server you connect that do that...
From the problem description above it is not clear to me if there potentially are other parties involved, but it is quite common for those that have smaller MTU than 1500 to experience random problems when visiting sites (many sites work OK, some do not) due to incompetent system administrators elsewhere in the network.
And even when that is all OK, not all operating systems show reasonable behavior when ICMP frag needed is received. Some do just retransmit the current segment in fragments, but then they continue sending large segments immediately or quickly thereafter. As there usually is some rate throttling on ICMP messages, this results in extreme throughput problems on such connections.
As ugly as it is, the TCP MSS clamping workaround is the most effective workaround in place.
I am guilty of "inventing" it in 1995, but I did not publish it widely and did not patent it... does anyone know of others implementing this before august 1995?
(I noticed that e.g. in Cisco IOS this appeared much later)
Another possible "ugly hack" is to clear DF on large packets entering a VPN or other tunnel:
add action=clear-df chain=postrouting comment=\
"clear DF on large packet to GRE" out-interface-list=gretun packet-size=\
After all, it is the DF flag (that is being used to implement PMTUD) that is causing all the trouble. Without this, the packets are just fragmented and routed on. PMTUD was implemented to avoid the inefficiency of fragmentation, but unfortunately it often causes the frustration of non-working applications. You select what you prefer.