This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Genereller Paketverlust XG330

Hallo zusammen,

ich habe ein Problem in meinem Netz mit der Sophos XG330. Eventuell hat jemand ähnliche Symptome und eventuell einen Richtungsvorschlag für mich.

Ich verwende zwei XG330 im active-passive HA Cluster mit der Firmware 18.5.2 MR-2-Build380. Die gleich genannten Probleme treten auf, egal welche Firewall die aktive ist, somit schließe ich einen Hardware Defekt aus.
Der Prozessor und Arbeitsspeicher sind auch unterfordert, da ist noch deutlich Luft nach oben.
Die Probleme sind nicht direkt, aber binnen einer Woche nach dem Update auf 18.5.2 aufgetreten.

Aufgefallen ist der Paketverlust erstmalig bei RDP Verbindungen via SSL VPN aus dem Home Office auf den Client in der Firma. Die RDP Verbindungen brechen alle 5-10 Minuten ab und werden beim 1. Versuch wiederhergestellt. Die VPN Verbindung bleibt dabei aufrecht erhalten und wird nicht erneut aufgebaut.
Dieses Problem existiert bei IPSec-Usern nicht mehr.

Intern verwende ich mehrere Client Netze für unterschiedliche Abteilungen, die trotzdem mit den selben Terminalservern arbeiten.
Intern bricht die RDP Verbindung nicht ab sondern hakt gelegentlich mal für 5-10 Sekunden.

Auch Verbindungen zu den Exchange Servern über Outlook haben Anfälligkeiten, Outlook ohne Cache Modus friert zu dieser Zeit ein und fordert danach eine erneute Passworteingabe.

Ich führe nun Pings von meinem Admin Client bzw. auch von einem Client aus einem anderen Clientnetz aus.
Dabei werden zwei Terminalserver und die beiden Exchange Server gepingt. Über die Paketverfolgung im Sophos Web GUI ist zu sehen, dass die Pakete zwar ankamen, aber vom Ziel keine Echo Response gesendet wurde. Es gibt alle 20-30 Minuten immer ca. 4-6 Ping Aussetzer (20 Sekunden).
Genau in diesem Zeitfenster hakt dann auch die RDP Sitzung und Outlook. Somit sind sehr viele Verbindungen von den Client Netzen gleichzeitig für alle Clients gestört.

Von meinem Admin Client kann ich per RDP noch auf die Ziele zugreifen, eine ICMP oder HTTP Response gibt es in diesem Zeitfenster jedoch nicht.

Ich hatte vermutet, dass es an den IPS Regeln liegen könnte und habe IPS zu Testzwecken komplett deaktiviert. Dies hat jedoch nicht geholfen.

Das Problem tritt auch nur bei gewöhnlichen Arbeitszeiten auf, ab dem Nachmittag oder Nachts gibt es keine RDP Aussetzer oder Ping Verlust.

Es gibt wohl einige IP Adressen die SYN Flooding (Max 200 Pakete pro Sekunde pro Quelle) betreiben, wenn ich diese IP Adresse als Source im tcpdump anschaue, sind das jedoch nur Kerberos Pakete Port 88 und TCP RDP Pakete. Manche Clients nutzen UDP für RDP, andere irgendwie TCP obwohl UDP dort nicht via Windows GPO verboten ist.

Virenscan habe ich auf den "Floodern" schon durchgeführt, die haben sowieso keine Internetverbindung.

Hat jemand einen Ansatz den ich da weiter verfolgen könnte?



This thread was automatically locked due to age.
Parents
  • Kannst du mal folgenden Befehl ausführen: 

    console> set vpn conn-remove-tunnel-up disable

    __________________________________________________________________________________________________________________

  • Hallo , vielen Dank für deine Antwort.

    Den Befehl hatte ich ausgeführt, aber die internen Aussetzer bleiben weiterhin. Es  sind immer noch 4-6 Ping Aussetzer in einem Intervall von 20-30 Minuten und dementsprechend auch RDP und HTTPS Aussetzer in diesem Zeitraum (PING kann ich nur gut per PowerShell loggen, bei RDP und HTTPs Aussetzern geben die Kollegen hin und wieder mal Bescheid, dennoch treten diese Aussetzer mehrfach in der Stunde auf).

    Die vorgegebenen Werte für SYN, TCP und UDP Flooding kommen mir ein bisschen gering vor. 100 TCP und UDP Pakete pro Sekunde pro Quelle werden bei einer Remotesitzung mit Tastatureingaben und Mausbewegungen deutlich überschritten. In anderen Foren habe ich als Schwellwert 1000 Pakete pro Sekunde pro Quelle gefunden, welche Werte lassen sich da empfehlen.
    Wenn TCP und UDP Flood mit einem Schwellwert von 200 pro Quelle aktiv ist, dann geht der Zähler sehr schnell sehr weit nach oben. Fast jeder Arbeitsplatz hat zusätzlich eine RDP Sitzung offen und oder noch Remote Apps, da kommt es nunmal zu mehreren Paketen pro Sekunde. Allerdings werden dann auch sehr schnell, sehr viele Quellen blockiert und haben dann viel öfter "Paketverlust" bzw. die Anfragen werden dann aufgrund von DoS Protection abgelehnt.

    Daher habe ich TCP und UDP Flood aktuell deaktiviert, ansonsten könnte hier niemand mehr arbeiten.

  • Ich bin kein Fan von DOS Protection auf einem Firewall Produkt. Der Mehrwert ist in der Regel nicht da. Ein Firewall Produkt kann das Bursting von DDOS Angriffen nicht stoppen. Es wird weiterhin die Leitung beeinträchtigen. So ein Service kann nur der ISP machen, um die Pakete bereits von der eigenen Internet Verbindung zu unterbinden.

    Kunden die bereits mit Standard Einstellungen Probleme mit Flooding bekommen, schalten das Feature sehr häufig komplett ab, da die erforderlichen Exceptions zu kompliziert sind, für den Benefit. 

    DOS (single packet attacks) sind weiterhin von der IPS geschützt, jedoch das pure Flooden von Paketen, um einen Kunden zu beeinträchtigen, kann eine Firewall nicht stoppen. 

    Es gibt eine Bug ID für das Thema mit "Ping aussetzern" aber meines Wissens nach beeinträchtigt das keine generelle Performance oder Themen. Es ist nur ICMP, dass manchmal von der Appliance "verschluckt wird". 

    Du könntest auch die Fastpath Technologie deaktivieren, ob das hilft: console> system firewall-acceleration disable

    __________________________________________________________________________________________________________________

Reply
  • Ich bin kein Fan von DOS Protection auf einem Firewall Produkt. Der Mehrwert ist in der Regel nicht da. Ein Firewall Produkt kann das Bursting von DDOS Angriffen nicht stoppen. Es wird weiterhin die Leitung beeinträchtigen. So ein Service kann nur der ISP machen, um die Pakete bereits von der eigenen Internet Verbindung zu unterbinden.

    Kunden die bereits mit Standard Einstellungen Probleme mit Flooding bekommen, schalten das Feature sehr häufig komplett ab, da die erforderlichen Exceptions zu kompliziert sind, für den Benefit. 

    DOS (single packet attacks) sind weiterhin von der IPS geschützt, jedoch das pure Flooden von Paketen, um einen Kunden zu beeinträchtigen, kann eine Firewall nicht stoppen. 

    Es gibt eine Bug ID für das Thema mit "Ping aussetzern" aber meines Wissens nach beeinträchtigt das keine generelle Performance oder Themen. Es ist nur ICMP, dass manchmal von der Appliance "verschluckt wird". 

    Du könntest auch die Fastpath Technologie deaktivieren, ob das hilft: console> system firewall-acceleration disable

    __________________________________________________________________________________________________________________

Children
  • Eigentlich möchten wir diese DoS Protection gar nicht nutzen, nur der Support besteht da bei jedem Telefonat drauf und aktiviert den dann mit dem Schwellwert von 100 Paketen pro Sekunde pro Quelle. Hinterher muss ich das schnell wieder abschalten weil sonst 90 Kollegen nicht mehr arbeiten können.

    Die suchen immer ein Gerät im Netzwerk was dieses Flooding betreibt. Interessant ist auch, dass diese Aussetzer nur während der normalen Arbeitszeit auftauchen. Wir haben schon einzelne Abteilungen komplett offline genommen um das Problem einzugrenzen, ob eines der Geräte dafür verantwortlich ist. Bisher alles ohne Erfolg.

    Wir hatten auch die Terminalserver Farm, die verwendet wird und wodurch eventuell UDP/TCP Flooding entstehen könnte (300-500 Pakete pro Sekunde pro Quelle wenn da hastig die Maus bewegt wird. Sind zwar nur kleine Datenpakete, aber dennoch viele), komplett abgeschaltet, sodass dort keine Pakete mehr gesendet werden konnten. Ebenfalls ohne Erfolg.

    Unsere Telefonie läuft nicht über die o.g. Sophos XG, daher hier auch kein erhöhter Traffic.

    Und generell werden hier sehr wenig Daten täglich übertragen, die PCs haben keine direkte Internetverbindung, wodurch auch keine Kommunikation mit diversen öffentlichen IP Adressen möglich wäre.

    Ich werde die Fastpath Technologie mal deaktivieren und prüfen ob das hilft. Vielen Dank für deine Unterstützung.

  • Noch als Ergänzung. Die Probleme aus dem VPN Netz haben wir gelöst, indem wir von SSL VPN auf IPSec (Sophos Connect) umgestiegen sind. Somit gibt es von außen bzw. per VPN keine Probleme mehr.

    Nur im internen Traffic haben wir eben noch diese massiven Aussetzer. Bei einem durchgehenden Ping ist in der Firewall in der Paketerfassung auch zu sehen, dass die Firewall das ICMP Paket von der Quelle erhalten hat und das Ziel auch wieder der Quelle antwortet. Bei einem Ausfall sind dann nur noch mehrere Anfragen der Quelle zu sehen und keine Antworten mehr des Ziels. Normalerweise würde ich da jetzt ansetzen das Ziel näher zu untersuchen, allerdings tritt das ja bei allen möglichen Zielen gleichzeitig auf.

    Die CPU und Ram Auslastung verhält sich in diesem Zeitraum auch ganz normal und von extern werden trotzdem noch ICMP Pakete beantwortet, nur von den diversen VLANs nicht mehr.

  • Verwendest du STAS? 

    __________________________________________________________________________________________________________________

  • Wir hatten STAS verwendet, aber jetzt aufgrund dieser Aussetzer das erstmal komplett deaktiviert. Wir hatten die Sorge, dass für diesen Zeitraum nicht verifiziert werden kann, dass die anfragende IP Adresse zu einem autorisierten Nutzer gehört.

    Allerdings müsste es dann ja Log Einträge in der Protokollansicht geben, dass diese Abgelehnt wurden. Diese Anfragen tauchen aber nie in der Protokollansicht auf. Ich werde jetzt nochmal die Live Ansicht in tcpdump ICMP von meiner IP zu einem der abbrechenden Ziele verfolgen, ob da zumindest die Anfragen ankommen, aber nicht beantwortet werden.

  • Wenn das passiert, schau bitte unter der Advanced Shell und Drop packet capture (drppkt) nach. Dort siehst du, warum die Appliance packete verwirft. 

    __________________________________________________________________________________________________________________

  • Ok, ich werde berichten. Danke

  • Gerade gab es wieder einen Aussetzer, zwar nur zwei Pings, aber die Logs sind interessant:

    tcpdump (tcpdump -nei any host 10.1.204.6 and host 10.1.220.2 and icmp)

    10:34:11.617124 Port11, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617124 Intern, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617124 Intern.1204, IN: In 1c:69:7a:69:f0:3d ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617157 Intern.1220, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617158 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617159 Port12, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20307, length 40
    10:34:11.617656 Port11, IN: In 00:0c:29:56:e5:6a ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:11.617656 Intern, IN: In 00:0c:29:56:e5:6a ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:11.617656 Intern.1220, IN: In 00:0c:29:56:e5:6a ethertype IPv4 (0x0800), length 76: 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:11.617670 Intern.1204, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:11.617671 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:11.617671 Port11, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20307, length 40
    10:34:12.636577 Port11, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:12.636577 Intern, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:12.636577 Intern.1204, IN: In 1c:69:7a:69:f0:3d ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:16.271232 Port11, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:16.271232 Intern, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:16.271232 Intern.1204, IN: In 1c:69:7a:69:f0:3d ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:20.273065 Port11, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20321, length 40
    10:34:20.273065 Intern, IN: In 1c:69:7a:69:f0:3d ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20321, length 40
    10:34:20.273065 Intern.1204, IN: In 1c:69:7a:69:f0:3d ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20321, length 40
    10:34:24.112974 Intern.1220, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:24.112978 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:24.112979 Port12, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20310, length 40
    10:34:24.113260 Intern.1220, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:24.113261 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:24.113261 Port12, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.204.6 > 10.1.220.2: ICMP echo request, id 27, seq 20316, length 40
    10:34:24.113318 Port11, IN: In 00:0c:29:56:e5:6a ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20310, length 40
    10:34:24.113318 Intern, IN: In 00:0c:29:56:e5:6a ethertype 802.1Q (0x8100), length 80: vlan 1220, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20310, length 40
    10:34:24.136554 Intern.1204, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20310, length 40
    10:34:24.136559 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20310, length 40
    10:34:24.136561 Port11, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20310, length 40
    10:34:24.136620 Intern.1204, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20316, length 40
    10:34:24.136621 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20316, length 40
    10:34:24.136621 Port11, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20316, length 40
    10:34:24.136645 Intern.1204, OUT: Out c8:4f:86:fc:00:03 ethertype IPv4 (0x0800), length 76: 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20321, length 40
    10:34:24.136645 Intern, OUT: Out c8:4f:86:fc:00:03 ethertype 802.1Q (0x8100), length 80: vlan 1204, p 0, ethertype IPv4, 10.1.220.2 > 10.1.204.6: ICMP echo reply, id 27, seq 20321, length 40

    drppkt  (drppkt 'host 10.1.204.6 and host 10.1.220.2')

    Keine Ausgabe, hier gab es wohl keine dropped packets, Syntax ist meines Wissens nach richtig.

    Der Ping um 10:34:11 wird vom Ziel (10.1.220.2) noch beantwortet (echo reply), der Ping um 10:34:12 wurde nicht mehr beantwortet, der nächste um 10:34:16 und 10:34:20 ebenfalls nicht mehr. Erst ab 10:34:24 wird von 10.1.2022.2 wieder echo reply zurück geschickt.

  • Der Sophos Support hatte jetzt nach Analyse eines tcpdump logs ebenfalls den Befehl "set vpn conn-remove-tunnel-up disable" vorgeschlagen. Das hatte bisher ja leider noch nicht geholfen. Hast du noch eine andere Idee?

  • Ich würde mir mal die Switche ansehen. Wird dort STP verwendet? Welche Switche nutzt ihr?

    Mit freundlichem Gruß, best regards from Germany,

    Philipp Rusch

    New Vision GmbH, Germany
    Sophos Silver-Partner

    If a post solves your question please use the 'Verify Answer' button.

  • Auf Spanning Tree hätte ich jetzt auch getippt. Evtl. mal die Topologie changes oder Root History anschauen.