Und immer wieder MTU / MSS (tw. http-Server über VPN nicht erreichbar)

[bnice]

Hi,

und wieder einmal kämpfe ich mit Problemen, die allem Anschein nach auf nicht passende MTU/MSS-Einstellungen zurückzuführen sind.

Folgende Randbedingungen:
VPN zwischen zwei Standorten, Standort 1 mittels PPPoE (ADSL, feste IP) Standort 2 mit SDSL, feste IP.

- VPN steht, alle Rechner via ICMP erreichbar
- RDP von 1 nach 2 funktioniert
- RDP von 2 nach 1 funktioniert nicht
- http-Server 1 (Linux) am Standort 1 von 2 erreichbar
- http-Server 2 (Windows, VMWare) am Standort 1 von 2 nicht erreichbar
- http/hfs-Server 3 (Windows native) am Standort 1 von 2 nicht erreichbar
- wird von 2 nach 1 eine Verbindung mittels Cisco VPN-Client aufgebaut, sind alle Server erreichbar

MTU-Size (WAN) an Standort 2 auf 1400 eingestellt

ip mtu 1400

MSS (WAN) an Standort 2 auf 1360 eingestellt

ip tcp adjust-mss 1360

Anschließend per

clear crypto session

den Tunnel neu aufgebaut und mittels

show crypto ipsec sa

die neuen Werte verifiziert.

Rechnerseitig habe ich noch mit DrTCP auf den beteiligten Rechnern die MTU-Size bis auf 1300 heruntergedreht.
Alles bisher ohne Erfolg.
Ist es realistisch, dass die Werte noch niedriger sein müssen? Oder gibt es evtl. doch noch andere Quellen für dieses Fehlerbild (aber warum komme ich z.B. auf den Linux Web-Server?) ...?
Liefert mir der Test mit

ping -f -l <size> <IP-Adresse>

zuverlässige Werte? Und wenn ja, kann ich die ermittelten max. Werte dann als MSS oder MTU-Size auf dem Interface eintragen?

[Wordo]

Lass die MTU's wie sie sind (nicht 1400) und mach die adjust-mss auf 1300. Danach musst du reconnecten.

[bnice]

Hi Wordo,

ping -f -l <size> <IP-Adresse>

ergibt von 2 nach 1 allerdings einen Wert von 1200 Byte - stelle ich den dann für die MSS ein, oder muss ich da noch 40 Byte abziehen?

Gibt es evtl. irgendwo mal eine Liste mit Erfahrungswerten zu den Größen?

[hegl]

Bei ´ner PIX mit V6.x hatte ich auch Probleme beim RDP, hatte auch mit den MTU´s "experementiert" und bin zu keiner Lösung gekommen.

Seit dem Umstieg auf ´ne ASA habe ich dieses Problem durch Setzen des DF-Bit von "Copy" auf "Clear" in den Griff bekommen.

Da Du nicht schreibst, was für ein VPN-Gateway Du nutzt, weiß ich natürlich nicht, ob´s dieses feature bei Dir gibt.

[bnice]

Zitat von hegl Da Du nicht schreibst, was für ein VPN-Gateway Du nutzt, weiß ich natürlich nicht, ob´s dieses feature bei Dir gibt.

Oops, ganz vergessen, sind jeweils zwei Cisco 871 Router... Muss ich mal recherchieren, ob es dieses Feature da auch gibt

[UPDATE]
Das Feature gibts scheinbar seit 12.2:
DF Bit Override Functionality with IPSec Tunnels
Hat jemand diesbezüglich positive Erfahrungen sammeln können?

[Wordo]

Ja, ueber ne route-map.

[hegl]

ups , da waren andere schneller

[Wordo]

Wenn du das DF-Bit weglaesst wird fragmentiert, das ist an sich schon mal schlecht, funktioniert aber. Fragmentierung sollte eigentlich gar nicht stattfinden.

[bnice]

Zitat von Wordo Wenn du das DF-Bit weglaesst wird fragmentiert, das ist an sich schon mal schlecht, funktioniert aber. Fragmentierung sollte eigentlich gar nicht stattfinden.

D.h. "Best-Practice" wäre erstmal der Weg über

ip tcp adjust-mss

und nur wenn das nicht fruchtet ein

crypto ipsec df-bit clear

?

Ich hoffe, dass ich das mal in einem Wartungsfenster testen kann... Irgendwie taucht dieses Problem alle Jahre mal wieder auf...

[hegl]

Zitat von Wordo Wenn du das DF-Bit weglaesst wird fragmentiert, das ist an sich schon mal schlecht, funktioniert aber. Fragmentierung sollte eigentlich gar nicht stattfinden.

Hast ja Recht, aber z.B. ein WTS brachte mich damals in die unglückliche Lage das DF-Bit zu "clearen" nachdem ein MS-Patch auf dem WTS eingespielt wurde.
Die Serverheinis waren sich natürlich keiner Schuld bewusst, als RDP plötzlich nicht mehr lief und als Netzwerker ist man dann Schuld, weil wir das Problem auch im Netzwerkbereich lösen konnten.