Ich hab mal einen beidseitigen Mitschnitt erstellt.
Das ist jedenfalls kein MTU/MSS-Problem.
Im Client-Dump sieht man sehr schön, daß erst ein Verbindungswunsch (SYN) an den Server gesendet wird. Da der TCP-Stack keine Antwort erhält, sendet er nach 1 Sekunde das Paket erneut. Dann wird jeweils der RTO-Wert (Receive Timeout, also die Zeit, die auf eine Antwort gewartet wird) verdoppelt. Nach 6 Versuchen des erneuten Sendens wird dann für diese Verbindung aufgegeben und ein Fehler an die Anwendung (ich mutmaße an wget wie vorher auch) zurückgemeldet. Die Anwendung startet nun einen neuen Versuch (sieht man an der neuen Quellport-Nummer 58691, bei den Retransmissions bleiben die Endpunkte (jeweils IP/Port für Quelle und Ziel) gleich). Hier kommt dann auch irgendwann nach dem sechsten Versuch (ob das die Antwort auf den sechsten oder fünften Versuch ist, kann man nicht unterscheiden, ist auch egal) eine Antwort vom Server zurück (Paket 15 beim Client-Mitschnitt).
Entscheidend ist also der "Verlust" der SYN-Pakete auf dem Weg zum Server oder der Verlust der Antworten des Servers darauf. Da man im Server-Dump keine wiederholten SYN-Requests sieht, ist der Verlust auf dem Weg vom Client zum Server anzunehmen.
Das Verschwinden der SYN-Pakete erklärt auch den Unterschied im Verhalten mit oder ohne VPN. Je nach VPN-Typ (ich nehme mal AVM-IPSec mit NAT-T, also UDP auf Port 4500, an) erfolgt der Datenaustausch "blind", d.h. das Warten auf eine Bestätigung für eine TCP-Verbindung (der 3-Wege-Handshake) erfolgt nicht.
Da die SYN-Pakete (die nicht einmal annähernd an die MTU-größe heranreichen) verschwinden, ist ein MTU/MSS-Problem nicht anzunehmen.
Was noch denkbar wäre, ist ein Problem mit dem "connection tracking" beim NAT / der "stateful" Firewall. Das SYN-Paket muß ja auf dem Router auf die externe IP-Adresse (und normalerweise auch einen anderen Quell-Port) umgeschrieben werden. Der Client sendet von 192.168.178.21:58691 an den Server und kommt dort als 87.166.187.156:56352 an. Diese Umsetzung von Adresse und Port nimmt der Router vor. Wenn dabei schon die SYN-Pakete verschwinden (da braucht man dann wieder den Mitschnitt der externen Schnittstelle des Routers), wäre die Fritz!Box schuld an der Misere.
Ich kann mir allerdings beim besten Willen keinen Hardware-Schaden vorstellen, der Pakete im Connection-Tracking verschwinden läßt. Ein derart selektiver Software-Schaden im SquashFS ist (angesichts von Kompression und Integritätsprüfung) auch unwahrscheinlich. Anders als beispielsweise ein Switch hat die Box ja auch keinen dedizierten Buffer für irgendwelche Adressen (das wäre beim Switch Layer2 und bei der Box Layer3, aber bei einem Switch habe ich schon Schäden am MAC-Adresspuffer gesehen).
Die Aussage "Wenn es beim Neustart verschwindet, müßte es die Box sein." berücksichtigt nicht, daß normalerweise mit dem Neustart auch eine neue IP-Adresse und damit ein "Neuanfang" für alle darauf basierenden Verbindungen verbunden ist. Wenn jetzt irgendjemand die TCP-Verbindungen trackt, kann da ja auch ohne weiteres nach 5 Minuten ein Überlauf eintreten.
Ich behaupte mal, da liegt irgendwo im Weg der Pakete ein Schaden an einem Gerät vor, das TCP-Verbindungen überwacht. Warum und wo das überhaupt stattfinden sollte, ist mir allerdings ein Rätsel. Wenn nicht irgendetwas an TCP-Verbindungen anders zu überwachen ist, als an beliebigen anderen Protokollen, gibt es aus meiner Sicht keine Notwendigkeit, TCP-Verbindungen irgendwie zu tracken und dann gehören TCP-SYN-Pakete definitiv nicht zu dem Traffic, den ein Router (wie bei UDP) bei Überlastung einfach unter den Tisch fallen lassen darf. Sehr mysteriös ... beim CGN aber auch wieder sehr plausibel.
Und die 87.166.187.156 aus dem Server-Dump ist auch wirklich Deine öffentliche IPv4-Adresse auf der Fritz!Box ? Wenn nicht, dann wäre es ja die Adresse des "letzten" NAT-Gateways vor dem Server.
