Falsche MTU Grösse bei IKEv2 VPN

[v.mueller]

Hallo zusammen,

ich habe eine merkwürdiges Problem.
wir betreiben eine großes VPN Netz in einem MAN eine Providers.
VPN Gateway ist auf der einen Seite eine Lancom UF-760 FW und an den jeweils anderen Seiten Lancom 1900EF.
Am Hauptstandort, wo auch die FW steht gibt es mehrere Server unter anderem auch mit einem SQL-Server. Zur DB gibt es immer mal wieder Paketverluste bzw. Timeouts in der Verbindung. Bei den anderen Servern auch. Allerdings fällt es da nicht so auf.

Ich bin dem ganzen jetzt mal auf den Grund gegangen und habe mir die Kommunikation mal genauer angeschaut.
Der 1900er handelt mit der UF-760 einen MTU von 1443 auf der Router Seite aus. Die MTU der VPN Verbindung auf der FW ist allerdings 1446.
Äußert sich dadurch das ein Ping bis 1415 Bytes funktioniert, 1416 1417 1418 nicht und bei bei 1419 kommt eine DF Meldung.
1415 + 28 Bytes Header gleich 1443 Bytes, also genau die Größe der MTU des VPNs des Routers.

Trenne ich das VPN von Seiten der FW durch deaktivieren und lasse es neu aufbauen, zeigt auch der Router 1446 als MTU im Status.
Dann funktionieren alle Pings einwandfrei bis zum nächsten Neuaufbau vom Router. Danach sind es wieder 1443 und die 3 Bytes fehlen im MTU.
Auch ein manuelles Festlegen der MTU im Router bringt leider nichts. Nicht in der VPN Config und auch nicht unter Kommunikation.
Der Router springt immer wieder auf MTU 1443, vermutlich durch das RFC 7383.
Auch eine Änderung der MTU in der UF-760 bringt leider nichts.
Gibt es irgendeine andere Möglichkeit den MTU manuell festzunageln auf Seiten des Routers?

Gruß
Volker

[Dr.Einstein]

Das wird eher am ESP-Padding liegen. Das LCOS nimmt aus der MTU-Liste nur Werte, die kleiner sind als das errechnete Maximum der Verbindung. Du kannst nicht über die Physik hinaus vergrößern. Versuche also eher andersrum zu konfigurieren, auf beiden Seiten z.B. fest auf 1440 Byte.

Nutzt du AES-CBC? Kannst du auf AES-GCM umstellen? Da sollte das Padding ausbleiben.

[v.mueller]

Ich nutze AES-GCM mit 128bit. Habe es extra schon umgestellt von CBC und von 256bit.
Paketgrößen änderungen ändern leider gar nichts. Es bleibt immer bei 1443 auf der Router Seite.
Habe auch schon auf 1300 runter gedreht ohne irgendwelche Änderungen.

[v.mueller]

Ich habe es ja auch nicht vergrössert. Die Werte sind ausgehandelte Werte. Die MTU der Physischen Verbindung ist 1500.

[Frühstücksdirektor]

Das IKEv2, besser gesagt das IPsec, im LCOS macht eine PMTU und setzt die MTU dynamisch runter sobald ein Packet-Too-Big empfangen wurde.
Das ganze ist also dynamisch.
Tipp: Ab LCOS 10.90 kann man ein Tracepath auf der CLI machen, da wird die PMTU dann angezeigt: z.B. ping -m 8.8.8.8
Das vereinfacht die MTU-Suche und man muss nicht mehr sich manuell vortasten und umrechnen...

Für diese und weitere Analysemöglichkeiten liebe ich das LCOS! Das wird auch immer erweitert.

[v.mueller]

Das IKEv2, besser gesagt das IPsec, im LCOS macht eine PMTU und setzt die MTU dynamisch runter sobald ein Packet-Too-Big empfangen wurde.
Das ganze ist also dynamisch.
Tipp: Ab LCOS 10.90 kann man ein Tracepath auf der CLI machen, da wird die PMTU dann angezeigt: z.B. ping -m 8.8.8.8
Das vereinfacht die MTU-Suche und man muss nicht mehr sich manuell vortasten und umrechnen...

Muss ich das irgendwo aktivieren? Der Lancom zeigt mir immer die gleiche MTU der Verbindung an.
Gibt es einen PMTU Cache den ich auslesen kann.

Vor dem FW Disconnect.

Screenshot 1443.png

Nach dem FW Disconnect

Screenshot 1446.png

Für diese und weitere Analysemöglichkeiten liebe ich das LCOS! Das wird auch immer erweitert.

Das stimmt. Dafür ist das super.

[Frühstücksdirektor]

Der MTU-Status wird nur unter /status/wan/mtu/ für alle Gegenstellen angezeigt.

Ich würde vorschlagen:
- VPN Tunnel trennen
- MTU im Status prüfen
- VPN-Packet, VPN-Status und VPN-Debug-Trace laufen lassen
- ping -m auf einer interne IP-Adresse auf der Gegenseite machen

Dann sollte irgendwo im Trace erscheinen, dass das LCOS die MTU runtergesetzt hat, da ein ICMP Packet-too-Big empfangen wurde
Da kommt aber einiges an Daten im VPN-Packet-Trace...

Es gibt das Show-Kommando für den Desitnation-Cache (inkl. PMTU):

show ipv4-destination

[v.mueller]

Das ist doch die Ausgabe aus dem entsprechenden Status aus dem Trace Tool.
Zeigt das gleich wie auf der Console.

Hier mal die Pings von Seiten des Haupstandortes Lancom UF-760

gpadmin@fw01:~$ ping -I 192.168.99.1 -M do -c 4 -s 1415 172.19.72.14
PING 172.19.72.14 (172.19.72.14) from 192.168.99.1 : 1415(1443) bytes of data.
1423 bytes from 172.19.72.14: icmp_seq=1 ttl=127 time=1.33 ms
1423 bytes from 172.19.72.14: icmp_seq=2 ttl=127 time=1.15 ms
1423 bytes from 172.19.72.14: icmp_seq=3 ttl=127 time=1.24 ms
1423 bytes from 172.19.72.14: icmp_seq=4 ttl=127 time=1.22 ms

--- 172.19.72.14 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 6ms
rtt min/avg/max/mdev = 1.146/1.231/1.328/0.077 ms
gpadmin@fw01:~$ ping -I 192.168.99.1 -M do -c 4 -s 1416 172.19.72.14
PING 172.19.72.14 (172.19.72.14) from 192.168.99.1 : 1416(1444) bytes of data.

--- 172.19.72.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 76ms

gpadmin@fw01:~$ ping -I 192.168.99.1 -M do -c 4 -s 1417 172.19.72.14
PING 172.19.72.14 (172.19.72.14) from 192.168.99.1 : 1417(1445) bytes of data.

--- 172.19.72.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 73ms

gpadmin@fw01:~$ ping -I 192.168.99.1 -M do -c 4 -s 1418 172.19.72.14
PING 172.19.72.14 (172.19.72.14) from 192.168.99.1 : 1418(1446) bytes of data.

--- 172.19.72.14 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 81ms

gpadmin@fw01:~$ ping -I 192.168.99.1 -M do -c 4 -s 1419 172.19.72.14
PING 172.19.72.14 (172.19.72.14) from 192.168.99.1 : 1419(1447) bytes of data.
ping: local error: Message too long, mtu=1446
ping: local error: Message too long, mtu=1446
ping: local error: Message too long, mtu=1446
ping: local error: Message too long, mtu=1446


Das von Seiten des Routers.

> ping -a 172.19.72.1 -m 192.168.99.203
..-
1 Tracepath * .
Tracepath 192.168.99.203 pmtu=1443 seq.no=5 time=8.464 ms
pmtu found is 1443


Der MTU der VPN Verbindung wird auf der Router Seite nach Neuaufbau sofort auf 1443 gesetzt.
Der Trace der VPN Verbindung zeigt sonst nichts auffälliges.


Laut Lancom wird dafür bei IKEv2 das Protocol RFC 7383.
https://www.lancom-systems.de/docs/LCOS ... ation.html
Ich glaube damit gibt es zwischen Router und FW irgendein Problem

[backslash]

Hi v.mueller

Das von Seiten des Routers.

> ping -a 172.19.72.1 -m 192.168.99.203
..-
1 Tracepath * .
Tracepath 192.168.99.203 pmtu=1443 seq.no=5 time=8.464 ms
pmtu found is 1443


Der MTU der VPN Verbindung wird auf der Router Seite nach Neuaufbau sofort auf 1443 gesetzt.
Der Trace der VPN Verbindung zeigt sonst nichts auffälliges.

nun ja, ein Tracepath "durch" den Tunnel ist nicht sehr hilfreich, denn da siehst du nur das "Ergebnis" (nämlich, daß nur 1443 übrigbleiben) ... Aus Traceroute/Tracepath-Sicht ist der VPN-Tunnel schließlich nur ein Hop...

Du muß ein Tracepath schon auf der Internetverbindung zur IP der UF machen. Dann wird irgendwer auf der Stecke sagen sagen, daß die MTU "ungerade" ist - und das ist dann auch der Verursacher des Problems (zumal "ungerade" MTUs mmehr als merkwürdig sind) .

Am Ende bleibt dir dennoch nichts anderes übrig, als für den VPN-Tunnel die MTU manuell auf 1440 oder niendriger zu setzen - und das sinnvollerweise auf beiden Seiten (wobei ich nicht weiß, wie man das an der UF einstellt)

Gruß
Backslash

[v.mueller]

Hi v.mueller

nun ja, ein Tracepath "durch" den Tunnel ist nicht sehr hilfreich, denn da siehst du nur das "Ergebnis" (nämlich, daß nur 1443 übrigbleiben) ... Aus Traceroute/Tracepath-Sicht ist der VPN-Tunnel schließlich nur ein Hop...

Du muß ein Tracepath schon auf der Internetverbindung zur IP der UF machen. Dann wird irgendwer auf der Stecke sagen sagen, daß die MTU "ungerade" ist - und das ist dann auch der Verursacher des Problems (zumal "ungerade" MTUs mmehr als merkwürdig sind) .

Die WAN Verbindung ist auf beiden Seiten 1500 Bytes.

ping -I 192.168.99.1 -M do -c 4 -s 1500 185.47.235.116
PING 185.47.235.116 (185.47.235.116) from 192.168.99.1 : 1500(1528) bytes of data.
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500
ping: local error: Message too long, mtu=1500

ping -a 172.19.72.1 -m 185.47.235.1

Tracepath 185.47.235.1 pmtu=1500 seq.no=0 time=0.372 ms
pmtu found is 1500

Am Ende bleibt dir dennoch nichts anderes übrig, als für den VPN-Tunnel die MTU manuell auf 1440 oder niendriger zu setzen - und das sinnvollerweise auf beiden Seiten (wobei ich nicht weiß, wie man das an der UF einstellt)

Das funktioniert leider nicht. Sämtliche Änderung bringen nichts. Bei der UF-760 sind es leider immer 1446. Bei dem Router kann ich nur nach unten ändern. Damit werden aber die nicht Verfügbaren Ping Bereiche einfach nur grösser 14..-1446

Gruß
Backslash

[backslash]

Hi v.mueller

ping -a 172.19.72.1 -m 185.47.235.1

Tracepath 185.47.235.1 pmtu=1500 seq.no=0 time=0.372 ms
pmtu found is 1500

dann baut da wohl die UF mist... und du mußt die MTU manuell heruntersetzen (und zwar auf beiden Seiten!)

Bei dem Router kann ich nur nach unten ändern. Damit werden aber die nicht Verfügbaren Ping Bereiche einfach nur grösser 14..-1446

Wenn du die MTU auf beiden Seiten gleich setzt, passiert das eben nicht.
Letztendlich sind aber doch "pings" eher egal... Wichtiger sind TCP-Sessions und da macht das LANCOM in jedem Fall ein MSS-Clamping, so daß es bei TCP-Verbindungen nicht zu Aussetzern kommen sollte - natürlich nur, wenn im LANCOM die MTU passend gesetzt ist.

Gruß
Backslash

[GrandDixence]

In älteren LCOS-Versionen wurde die MTU vom VPN-Tunnel standardmässig auf 1400 Byte gesetzt.
fragen-zur-lancom-systems-routern-und-g ... ml#p112809

Bei einer dynamischen Aushandlung der MTU vom VPN-Tunnel besteht die Gefahr, dass beim sogenannten Rekeying (Neuaushandlung des für die Verschlüsselung verwendeten Schlüsselmaterials des VPN-Tunnels) ein anderes Verschlüsselungsverfahren gewählt wird. Wächst nach dem ersten Rekeying der Verschlüsselungsanteil (overhead) durch das neue Verschlüsselungsverfahren, so könnte dies genau die beschriebenen MTU-Probleme auslösen. Hier sollte mit einer sehr kurzen Rekeying-Ablaufzeit von 5 bis 10 Minuten getestet werden, ob das Rekeying diese MTU-Probleme auslöst.

Vielleicht wurde vor dem Rekeying das platzsparende AES-GCM eingesetzt, nach dem ersten Rekeying kommt dann nur noch AES-CBC zum Einsatz. Wenn die Probleme erst nach dem ersten Rekeying beginnen, ist das besonders fies für die Störungssuche: Direkt nach dem VPN-Tunnelaufbau funktioniert alles einwandfrei und erst nach einigen Stunden, wenn das erste Rekeying erfolgte, beginnen die Probleme wie aus dem Nichts...

Was für eine Netzwerkverbindung kommt für die problematische Datenbank-Verbindung zum Einsatz? UDP oder TCP?

[v.mueller]

In älteren LCOS-Versionen wurde die MTU vom VPN-Tunnel standardmässig auf 1400 Byte gesetzt.
fragen-zur-lancom-systems-routern-und-g ... ml#p112809

Bei einer dynamischen Aushandlung der MTU vom VPN-Tunnel besteht die Gefahr, dass beim sogenannten Rekeying (Neuaushandlung des für die Verschlüsselung verwendeten Schlüsselmaterials des VPN-Tunnels) ein anderes Verschlüsselungsverfahren gewählt wird. Wächst nach dem ersten Rekeying der Verschlüsselungsanteil (overhead) durch das neue Verschlüsselungsverfahren, so könnte dies genau die beschriebenen MTU-Probleme auslösen. Hier sollte mit einer sehr kurzen Rekeying-Ablaufzeit von 5 bis 10 Minuten getestet werden, ob das Rekeying diese MTU-Probleme auslöst.

Vielleicht wurde vor dem Rekeying das platzsparende AES-GCM eingesetzt, nach dem ersten Rekeying kommt dann nur noch AES-CBC zum Einsatz. Wenn die Probleme erst nach dem ersten Rekeying beginnen, ist das besonders fies für die Störungssuche: Direkt nach dem VPN-Tunnelaufbau funktioniert alles einwandfrei und erst nach einigen Stunden, wenn das erste Rekeying erfolgte, beginnen die Probleme wie aus dem Nichts...

Was für eine Netzwerkverbindung kommt für die problematische Datenbank-Verbindung zum Einsatz? UDP oder TCP?

Guten Morgen,
es ist nur AES-GCM128 mit sha256 und DH Group 14 aktiviert und das auf beiden Seiten. Aushandelung sollte also immer gleich sein.
Bei SQL im Normalfall ja TCP. Allerdings scheint es da dann auch probleme zu geben.
Es sind aber nicht nur die SQL Verbindungen die Probleme machen. Die Probleme äussern sich auch bei anderen Verbindungen. Wie gesagt. Steht durch das deaktivieren und wieder aktivieren des Tunnels auf der FW der MTU auf 1446 beidseitig gibt es keine Probleme.

Gruß
Volker

[v.mueller]

Hi v.mueller

ping -a 172.19.72.1 -m 185.47.235.1

Tracepath 185.47.235.1 pmtu=1500 seq.no=0 time=0.372 ms
pmtu found is 1500

dann baut da wohl die UF mist... und du mußt die MTU manuell heruntersetzen (und zwar auf beiden Seiten!)

Bei dem Router kann ich nur nach unten ändern. Damit werden aber die nicht Verfügbaren Ping Bereiche einfach nur grösser 14..-1446

Wenn du die MTU auf beiden Seiten gleich setzt, passiert das eben nicht.
Letztendlich sind aber doch "pings" eher egal... Wichtiger sind TCP-Sessions und da macht das LANCOM in jedem Fall ein MSS-Clamping, so daß es bei TCP-Verbindungen nicht zu Aussetzern kommen sollte - natürlich nur, wenn im LANCOM die MTU passend gesetzt ist.

Gruß
Backslash

Guten Morgen,

ich denke auch das die UF-760 da misst macht. Die MTU in der VPN Verbindung ändert sich leider nicht, egal auf was ich die in der UF-760 setzte. Standardmässig steht die in der Verbindung auf 1400. Ich habe die schon auf 1300 gesetzt, nätürlich auf beiden Seiten. Ohne irgendeine Änderung. Auf dem Router ist sie dann 1300 aber auf der Firewall nicht. Das hat dann zur folge das Pakete mit einer Grösse von 1272 bis 1418 Bytes nicht mehr zugestellt werden.

Leider hat es wohl doch Auswirkungen. Wie ich oben erwähnt habe gibt es eine Möglichkeit die MTU auf beiden Seiten auf 1446 zu bringen. Das geht wenn ich von der FW Seite die Verbindung deaktiviere und wieder aktiviere. Dann ist sie bis zum nächsten Reconnect tatsächlich korrekt.
Im Netz funktioniert dann alles wunderbar. Übertragungsraten von 100 mbyte/s durchs VPN und superschnelle Antwortzeiten vom SQL Server. Ganz krass merkt man das beim öffnen von Word Dateien. Vor dem Reconnect öffnen die sich sofort, danach dauert es 30 sec.
Die SQL Verbindung bekommt of Timeouts. Ich werde mal Versuchen neben die FW noch nen ISG-5000 zu stellen und hoffe das das dann besser läuft. Nimmt mir nur dann leider die Redundanz.


Vielen Dank für die Unterstützung

Gruß
Volker