Paketverluste im RED-Tunnel

Hello Markus Rubin,

Vielen Dank, dass Sie sich an die Community gewendet haben. Für den betroffenen Standort können Sie die folgenden Protokolle überprüfen:
> system.log & red.log – während der Zeit der Trennung
https://docs.sophos.com/nsg/sophos-firewall/19.0/Help/en-us/webhelp/onlinehelp/AdministratorHelp/Logs/LogFileDetails/index.html

Vielen Dank für die schnelle Rückmeldung. Beide genannten Logs zeigen keine Fehler zum Zeitpunkt des Fehlers an.

Können Sie die Ausgabe der Protokolldatei während des Problems teilen? Damit wir unsere Ergebnisse überprüfen und Ihnen zur Verfügung stellen können.

Hier der Auszug aus dem RED.log:

Wed Jun 1 09:15:39 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:20:40 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:25:41 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:30:42 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:35:43 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:40:44 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Reading REDv2 key from STDIN:
Reading REDv2 key from STDIN:
Reading REDv2 key from STDIN:
Wed Jun 1 09:45:45 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0
Wed Jun 1 09:50:46 2022Z REDD INFO: Red devices: Connected: 3 Disconnected 0 Enabled: 3 Disabled: 0

Im System Log melden sich, sobald wieder Pakete durch den Tunnel gehen, die WLAN APs mit folgendem Hinweis:

2022-06-01 11:51:35
Wireless Protection
Successfully sent config to AP [YYYYYYYY].
18007
SYSTEM
2022-06-01 11:51:34
Wireless Protection
Successfully sent config to AP [XXXXXXXX].
18007
SYSTEM
2022-06-01 11:51:19
Wireless Protection
Successfully sent config to AP [YYYYYYYY].
18007
SYSTEM
2022-06-01 11:51:17
Wireless Protection
Successfully sent config to AP [XXXXXXXX].

Richtig, da ist nichts Verdächtiges, zufällig wenn der ISP geschwankt hat?

SD-RED 20 & SD-RED 60 TCP 3400 + UDP 3410
Können Sie überprüfen, ob der ISP, der mit dem RED verbunden ist, die Ports ordnungsgemäß geöffnet hat?
Sie können dies mit Hilfe der folgenden Website überprüfen:

www.ipfingerprints.com/portscan.php

Wenn Sie nach dem UDP-Protokoll suchen, verwenden Sie advance und aktivieren Sie den UDP-Scan.

Überprüfen Sie auch, ob die RED-Firmware von den Musteraktualisierungen auf dem neuesten Stand ist.

Das externe Monitoring auf den ISP zeigt keine Fehler an.

Hier das Ergebnis des Portscans:

3400/udp filtered csms2
3410/udp filtered networklenss

Die Firmware ist die 3.0.007

Die Firmware sieht aktuell aus.

3400 ist ein TCP-Port, sodass Sie im Abschnitt „Erweitert“ keine UDP-Scan-Option benötigen.

Beide sind als gefiltert markiert.

Ein Port wird als "gefiltert" markiert, wenn die Pakete an diesen Port gesendet werden, jedoch verhindert die Paketfilterung (z. B. eine Firewall), dass die Pakete diesen Port erreichen.

Die Firmware sieht aktuell aus.

3400 ist ein TCP-Port, sodass Sie im Abschnitt „Erweitert“ keine UDP-Scan-Option benötigen.

Beide sind als gefiltert markiert.

Ein Port wird als "gefiltert" markiert, wenn die Pakete an diesen Port gesendet werden, jedoch verhindert die Paketfilterung (z. B. eine Firewall), dass die Pakete diesen Port erreichen.

Ich habe die Abfrage nochmals gestartet:

hier das Ergebnis:

3400/tcp open csms2
3410/udp open|filtered networklenss

Sieht gut aus, und die Situation für Sie ist zufällig oder tritt nach einem bestimmten Zeitintervall auf?

Hast du schon versucht den ISP zu wechseln?

Der Fehler tritt sporadisch auf. Hier ist keine Regelmäßigkeit erkennbar.

Den ISP können wir nicht wechseln. Es gibt nur diesen einen Anschluss beim Kunden.

Wenn ISP flimmert, wird dies unter system.log für die rote Verbindung und unter dgd.log erfasst

Haben Sie darüber hinaus eine Zunahme der Bandbreitenauslastung oder der Anzahl der Benutzer während des Problems festgestellt?

Zum Zeitpunkt der Fehler sind keine Meldungen im System.log und im DGD.log erkennbar.

Die Bandbreitenauslastung bleibt konstant.

In diesem Fall können Sie jetzt eine Wireshark-Paketerfassung von einem Computer hinter der roten Appliance ausführen und warten, bis das Problem erneut auftritt, um die Ursache weiter zu ermitteln.

Was genau soll mit dem Wireshark geprüft werden?

Aktuell überwachen wir die Leitung mittels PING.

Ping sollte in Ordnung sein oder die Pakete für TCP 3400 und UDP 3410 herausfiltern

Die Ping Pakete kommen im Fehlerfall nicht mehr an.

Den erweiterten Wireshark können wir Ende der Woche beim Kunden vor Ort einrichten.

Also gut, das wäre der nächste Aktionsplan.