IP-R "Pass on TCP SYN and ACK packets preferentialy"

[Henri]

Hallo,

bei mir schlägt die FW recht of bei Bitdefener Nimbus an. Ich habe einmal vor dem Router einen Trace gemacht, hier ist zu sehen dass die Pakete 19/20 in falscher Reihenfolge übertragen werden. Ich habe die o.g. Option ausgeschaltet, damit scheint es besser zu funktionieren.
Ist das so "works as designed" oder verstehe ich hier etwas falsch?

Danke

Henri

17 2.177480127 kube-nimbus-471965604.us-west-2.elb.amazonaws.com Router TLSv1.2 85 Encrypted Alert
18 2.177492267 kube-nimbus-471965604.us-west-2.elb.amazonaws.com Router TCP 60 443 → 32183 [FIN, ACK] Seq=3460 Ack=704 Win=31088 Len=0
19 2.178300203 Router kube-nimbus-471965604.us-west-2.elb.amazonaws.com TCP 60 [TCP Previous segment not captured] 32183 → 443 [ACK] Seq=705 Ack=3461 Win=5560 Len=0
20 2.178324248 Router kube-nimbus-471965604.us-west-2.elb.amazonaws.com TCP 60 [TCP Out-Of-Order] 32183 → 443 [FIN, ACK] Seq=704 Ack=3460 Win=5560 Len=0
21 2.367338157 kube-nimbus-471965604.us-west-2.elb.amazonaws.com Router TCP 60 443 → 32183 [ACK] Seq=3461 Ack=705 Win=31088 Len=0
22 2.889237252 kube-nimbus-471965604.us-west-2.elb.amazonaws.com Router TCP 60 [TCP Retransmission] 443 → 32183 [FIN, ACK] Seq=3460 Ack=705 Win=31088 Len=0
23 3.945280031 kube-nimbus-471965604.us-west-2.elb.amazonaws.com Router TCP 60 [TCP Retransmission] 443 → 32183 [FIN, ACK] Seq=3460 Ack=705 Win=31088 Len=0

[GrandDixence]

Die bevorzugte Behandlung von TCP-Steuerpakete (SYN, ACK) im QoS-Mechanismus des LANCOM-Routers sollte man eingeschaltet belassen. Hat in meinen Augen nur Vorteile.

Offenbar bricht die verschlüsselte Verbindung aus irgendeinem Grund zusammen (Meldung "TLS: Encrypted Alert" vom Webserver an den Client => Mangel Nr. 1), vorauf der Webserver ordnungsgemäss die TCP-Verbindung mit einem "FIN+ACK" (443 -> 32183) trennen möchte. Im ordnungsgemässen TCP-Verbindungsabbau muss der Client die Verbindungstrennung mit einem "ACK" "FIN" UND/ODER "FIN+ACK" bestätigen, was auch geschieht (32183 -> 443), aber aus irgendeinem Grund nicht erfolgreich ist (Mangel Nr. 2):

https://de.wikipedia.org/wiki/Transmiss ... dungsabbau

Deshalb versucht der Webserver wiederholt, ohne Erfolg, mit dem erneuten Versenden von "FIN+ACK" die TCP-Verbindung zu trennen ([TCP Retransmission] 443 -> 32183).

Den Meldungen [TCP Previous segment not captured] und [TCP Out-Of-Order] würde ich nicht zu grosse Beachtung schenken. Deren Ursache könnte sein, dass die Netzwerkkomponente oder das Programm zur Aufzeichnung des Netzwerkverkehrs nicht genügend schnell beim Aufzeichnen des Netzwerkverkehrs ist und somit Datenpakete in der Aufzeichnung fehlen oder die Reihenfolge der aufgezeichneten Datenpakete nicht der Realität entspricht!

Für die Aufzeichnung des Netzwerkverkehrs mit einem PC/Laptop unter Windows/Linux/UNIX/BSD siehe bitte:
http://www.lancom-forum.de/fragen-zum-t ... cap#p93972

Bei grossen Datenübertragungsraten > 50 MBit/s sollte ein Switch mit "Mirror Port"-Unterstützung eingesetzt werden. Ein leistungsfähiger Laptop, dessen Netzwerkkarte per Gigabit-Ethernetkabel mit dem Mirror-Port des Switches verbunden ist, zeichnet den Netzwerkdatenverkehr auf dem speziell konfigurierten, rückwirkungsfreien Port/Anschluss des Switches auf. Siehe bitte:

https://community.swisscom.ch/t5/Intern ... 737#M51081

https://www.youtube.com/watch?v=UCi9n5FcdQY

https://community.swisscom.ch/t5/Intern ... 572#M51118

Hier ein Beispiel einer TCP-Verbindung nach einem "TLS Encrypted Alert":

TLS_Ende_Beispiel.png

Man beachte die SEQ- und ACK-Laufnummern und vergleiche mit Abbildung Nr. 4 des TCP-Wikipedia-Artikels!

In meinen Augen ist Paket Nr. 19 überflüssig und Paket Nr. 20 hat die falsche ACK-Laufnummer (korrekt:=3461, falsch:=3460)?!

[Henri]

Hallo GrandDixence,

vielen Dank.

Ich habe den Trace via Port Mirroring an einem CICSO SG550XG 10G Switch erzeugt, hier hängt an den WAN Ports ein Wirkshark dran.

Im Trace sehe ich die Situation so,

Paket 18: Src: 52.27.23.144, Dst: 7100+ Transmission Control Protocol, Src Port: 443, Dst Port: 32183, Seq: 3460, Ack: 704, Len: 0 0x011 (FIN, ACK)
Paket 19: Src: 7100+, Dst: 52.27.23.144 Transmission Control Protocol, Src Port: 32183, Dst Port: 443, Seq: 705, Ack: 3461, Len: 0 0x010 (ACK)
Paket 20: Src: 7100+, Dst: 52.27.23.144 Transmission Control Protocol, Src Port: 32183, Dst Port: 443, Seq: 704, Ack: 3460, Len: 0 0x011 (FIN, ACK)
Paket 21: Src: 52.27.23.144, Dst: 7100+ Transmission Control Protocol, Src Port: 443, Dst Port: 32183, Seq: 3461, Ack: 705, Len: 0 0x010 (ACK)

Mindestens bzgl. der SEQ Nummern wäre alles gut, wenn zuerst 20 und dann 19 vom LANCOM gesendet würde (ich bin allerdings hier kein Experte).

Lt LCOS Ref Guide:

Durch die bevorzugte Behandlung einzelner Pakete wird die ursprüngliche Paketreihenfolge geändert. Obwohl TCP/IP keine bestimmte Paketreihenfolge gewährleistet, kann es in einzelnen Anwendungen zu Problemen kommen. Das betrifft nur Anwendungen, die abweichend vom Protokollstandard eine bestimmte Paketreihenfolge voraussetzen. Für diesen Fall deaktivieren Sie den SYN/ACK-Speedup.

Das kann ich bestätigen, nach dem ich die Option ausgeschaltet haben ist der Effekt weg. Ich gebe dir allerdings absolut recht, ich würde die Option gerne wieder einschalten, allerdings ohne von der FW zugemüllt zu werden.

Wenn man die Flags so sieht kommt die Vermutung auf, das im Code auf 0x010 geprüft wird und nicht "AND 0x010".

Vielen Dank

Henri

[GrandDixence]

Was für "Müll-Meldungen" liefert den die Firewall?

Wird auf dem LANCOM-Router ein LCOS 10.12 RU6 oder neuer betrieben? LCOS 10.12 RU5 oder älter hatte einen Programmierfehler in der TCP-Implementierung.

Ausschnitt aus der LCOS-Releasenotes:

Code: Alles auswählen

Cisco Kabelmodems der Typen 3208, 3212 und 3925 stellten aufgrund eines vom LANCOM nicht
korrekt zusammengesetzten TCP-Pakets den Betrieb ein und konnten erst nach einem Neustart
weiterbetrieben werden. Das falsch generierte TCP-Paket wird nun nicht mehr versendet.

Was liefert eigentlich "netstat -n" (oder netstat -tun) auf den betroffenen Clients?

[Henri]

Hallo GrandDixence,

der "Müll" sind einfach Firewall Meldungen, der SRCPort 443 (HTTPS Server) versucht mit TGTport xxxx (LANCOM) zu kommunizieren, das ist auch nicht weiter verwunderlich, da bereits ein FIN gesendet wurde und daher aus Sicht der StateFull FW eine Protokollverletzung vorliegt.
Leider schaukelt sich das hoch, ich habe dann ein paar Tausend halboffene Sessions in der FW.
Den CICSO Bug kenne ich kenne ich übrigens sehr sehr gut, ich war hier über mehrer Monate Opfer davon. Da die Leitung des ISVs instabil war (Störungen im Kabelnetz), gab es ca. 3-20 Probleme pro Woche damit.

Das Verhalten ist komplett weg, wenn ich die Option ausschalte, dann werden die Pakete in korrekter Reihenfolge übertragen.

Viele Grüße

Henri

[GrandDixence]

Gemäss Figure 13 von RFC 793:
https://tools.ietf.org/html/rfc793#page-37
stimmt die SEQ- und/oder ACK-Laufnummer von Paket 19, 20 und 21 nicht. Somit liegt ein Programmierfehler im Antivirus-Server- und Antivirus-Client-Modul vor. Siehe auch:
https://www.heise.de/security/artikel/E ... 09009.html

Grundsätzlich kann und darf der Fehler gar nicht bei einem IP-Router wie dem LANCOM-Router liegen. Netzwerkkomponenten wie IP-Router dürfen die Reihenfolge der IP-Pakete ändern, jedoch nicht den TCP-Teil ändern, wie zum Beispiel die Anpassung der SEQ- und/oder ACK-Laufnummern. Der LCOS-Konfigurationsparameter "Pass on TCP SYN and ACK packets preferentialy" (deutsch: "SYN/ACK-Speedup") darf nur die Reihenfolge der IP-Pakete ändern.

Eine Software oder Netzwerkkomponente die keine IP-Paketüberholungen verarbeiten kann, sollte deinstalliert oder im Elektroschrott entsorgt werden.