Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 33 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 20145 views
  • Users 0 members are here
Options
Suggested
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

XG Firewall - Wifi MTU nach Update 17.1.3

Pascal G

Hallo Zusammen,

 

wir hatten bei einem Kunden die letzte Woche auf die hälfte seiner XG Firewalls (Insgesamt 15 Stk.) das Update 17.1.3 ausgerollt da wir im Vorfeld Verbindungsabbrüche im WLAN hatten und hofften das dies mit dem Update behoben wurde.

Jetzt ist auf den WLAN Schnittstellen aufgefallen das die MTU von 1500 auf 1450 umgestellt ist und der MSS Wert mit 1460 garnicht dazu passt.

Nach ein paar Prüfungen hat man auch schnell festgestellt dass WLAN extrem langsam ist (Pingzeiten auf Clients bis 225 ms). Habe das auch sicherheitshalber auf den XGs geprüft die noch in der Grundinstallation mit Firmware 17.0.0 sind. Hier ist der Wert noch korrekt.

Habe danach auf einer XG erstmal die MTU manuel auf 1500 gesetzt. Jetzt habe ich wieder Pingzeiten von 5 ms auf die Clients jedoch ist das auf dauer leider keine Lösung da bi einem Neustart die MTU natürlich wieder auf die 1450 umgestellt wird.

 

Hat jemand noch dieses Phänomen und eventuelle Ideen?

 

Also WLAN löschen, AP löschen und alles neu anlegen bringt auch nichts. Sobald man das WLAN einem AP zuweist wird die MTU wieder runter gestellt von 1500 auf 1450. Eventuell Fehler im AP Update?

 

 

Danke schon mal im Voraus

 

Grüße



This thread was automatically locked due to age.
Parents
  • 0

    Dank  haben wir mittlerweile eine Lösung die wohl Boot- und Update-sicher ist:

    Wir haben die MTU wieder auf Standard gesetzt und dafür TCP Segmentation Offloading deaktiviert. Damit erzielen wir dieselbe Performance, wie mit angepasster MTU.

     

    Hier seine Anleitung:

    Console>  system diagnostics interface-driver-settings set <interface_name> offload tso off

    To show: Console> system diagnostics interface-driver-settings show <interface_name> offload

    • tcp-segmentation-offload: off
      tx-tcp-segmentation: off
      tx-tcp-ecn-segmentation: off
      tx-tcp6-segmentation: off

    To revert back, simply:

    Console>  system diagnostics interface-driver-settings set <interface_name> offload tso on

  • 0 in reply to dja

    Das hört sich gut an und ich werde es bei Gelegenheit auch testen.

    Frage: was passiert konkret beim Deaktivieren des Offloadings? Oder besser gesagt: wann fällt mir diese Änderung wieder auf die Füße? Es hat ja vermutlich einen Grund, dass es standardmäßig aktiviert ist?

  • 0 in reply to Jelle

    Jelle said:
    Frage: was passiert konkret beim Deaktivieren des Offloadings? Oder besser gesagt: wann fällt mir diese Änderung wieder auf die Füße?

    Wie ich es verstehe, kann es wohl für eine höhere Last auf der CPU sorgen. Der Wikipedia-Artikel dazu: de.wikipedia.org/.../TCP_segmentation_offload

    Jelle said:
    Es hat ja vermutlich einen Grund, dass es standardmäßig aktiviert ist?

    Das habe ich mich auch gefragt. Laut  ist diese Einstellung unkritisch und es wird gar überlegt, ob nicht sogar off die neue Standardeinstellung sein sollte in zukünftigen SFOS-Releases.

     

    Wir haben TCP Segmentation Offloading seit einigen Tagen deaktiviert und bisher keine Probleme feststellen können.

  • 0 in reply to dja

    also ich teile dazu mal den Beitrag:

    https://blog.ip-projects.de/sophos-utm-problem-intel-82579lm-chipsatz/

    Diese Funktion dient dazu in schnellen Netzwerken die CPU Last von TCP/IP Paketen zu reduzieren indem Teilsegmente auf die Netzwerkkarte ausgelagert werden.

     

    Bei uns auch keine Probleme bisher. Denke das wird eher kritisch wenn die FW schon vor der Einstellung auf 80-90% CPU Last steht

  • 0 in reply to Pascal G

    Danke für Euer Feedback dazu. Dann werde ich das wohl auch mal testen.

    Wie sieht das aus bei einem HA-Cluster (A-P)? Muss ich das auf beiden Appliances machen und zwischendurch einen Wechsel durchführen?

  • 0 in reply to Jelle

    Ist das Problem zufällig noch bei jemandem aktuell?

     

    Ich bin bei meiner Fehlersuche auf dieses Thema gestoßen, bei mir ist die Performance der Seperaten Zone seit ich die XG installiert habe ziemlich schlecht.

    Betrifft aber nur den Download, der liegt bei ca. 0,5MBit - Upload ist mit 5 MBir ok. Im zweiten WLAN (Bridge to AP) passt es aber.

    MTU ist bei mir ebenfalls 1450, MSS 1460. Das offloading hab ich bereits deaktiviert, keine Besserung. Auch ohne IPS, WebProxy usw. wird es nicht schneller.

    Ich benutze übrigens die aktuellste SFOS Version.

    Hier noch mein Thema, das hab ich auf Englisch eröffnet, bevor ich dieses hier entdeckt habe:

    community.sophos.com/.../408386

  • 0 in reply to Andreas Leopold

    Soweit ich es verfolgt habe wurde das Offloading mit 17.5.4 automatisch deaktiviert und mit 17.5.5 und ggf. auch 17.5.6 dann aber nicht mehr. Einer der Gründe warum ich aktuell weiter 17.5.4 verwende. Aber das hast Du ja bereits selber deaktiviert. Allerdings muss die MSS doch 40 Byte unter der MTU liegen wenn ich mich recht entsinne? Also MSS auf 1410 stellen?

  • 0 in reply to Jelle

    Hallo!

    Ich habe gerade getestet - die MTU in der Konsole ist anscheinend doch 1500 - nur das Webinterface zeigt 1450 an. Auch bei einem neuen WLAN - ifconfig sagt immer 1500 - ich denke, das sollte dann so passen?

  • 0 in reply to Andreas Leopold

    Hab jetzt die MTU testweise auf 1300 eingestellt - keine Ahnung, wie ich darauf gekommen bin. Die IPS hat neu gestartet und die Performance war plötzlich OK.

    Ich werde das mal ein paar Tage beobachten. Kann es wirklich sein, dass diese Einstellung was bewirkt hat?

Reply Children
  • 0 in reply to Andreas Leopold

    Die MTU zu ändern war soweit ich mich entsinnen kann ein Lösungsvorschlag vor dem TCP Offloading und dem Patch dazu. Auch damals wurde schon festgestellt dass MTU in der Oberfläche und in der Konsole unterschiedlich sind.

    Am besten Du eröffnest dazu ein Ticket bei Sophos, da sie das offensichtlich immer noch nicht hinbekommen haben. Sowohl das Thema TCP Offloading welches anscheinend seit 17.5.5 wieder aktuell ist sowie auch das MTU-Verhalten bzw. die unterschiedlichen Werte.

  • 0 in reply to Jelle

    Okay, verstehe.

    Ich habe jetzt nochmals etwas getestet - das Ganze ist nicht so konstant, wie ich gedacht habe.

    Nach einiger Zeit sinkt der Speed wieder auf 1-2 MBit - mit MTU 1500 sind es 0,5 Mbit.

    Direkt nach dem Ändern ist es meistens wieder auf 16-17 MBit, das sinkt dann wieder langsam ab. Dafür hab ich nach dem Ändern sehr viel Packetloss und dropped Connections.

    Ich würde ja ein Ticket aufmachen, aber für meine Home-XG wird das wohl kaum jemanden interessieren. Ich bin XG Certified Architect und kenne die Support-Abläufe schon etwas.

    Aber ist nicht das erste Mal, dass ich bei einer XG Firewall ganz komische Dinge beobachten konnte, die sich dann meistens der Support auch nicht erklären konnte.

    Tut mir wirklich Leid, aber das bestärkt meine Meinung zu diesem Produkt,ich wollte es jetzt wieder einmal zu Hause verwenden, aber niemals würde ich eine XG Firewall produktiv zu einem Kunden stellen... :(

  • 0 in reply to Andreas Leopold

    Welche Drops siehst du?

    Wir brauchen den Drppkt von der Appliance. 

  • 0 in reply to LuCar Toni

    Leider gar keine. Was mich aber etwas wundert... Wenn ich auf der Shell drppkt eingebe, ohne Filter, sehe ich nur ein paar Broadcasts von Clients in dem Netz.

    Momentan komm ich aber remote nicht einmal mehr ins LAN, welches auch das AP LAN ist, die RDP Sitzung friert dauernd ein - sieht nach UDP Flood aus, aber die XG loggt auch dazu gar nichts....

    Ich greife über einen RED Tunnel von meiner UTM auf die XG zu, RDP ist momentan gar nicht möglich, alls anderen Dienste laufen soweit.

    Andere RDP Verbindungen sind aber problemlos möglich, in der UTM gibt es keine UDP Flood Drops.

     

    Ich habe jetzt 2 Rules gemacht für den gerade benutzten RDP, welche alle DDoS Checks auser Kraft setzt- jetzt läuft der RDP zumindest wieder.

    In der IPS wurde aber nichts geloggt, auch drppkt hat diese Pakete vom RDP nicht gezeigt.

    Um jetzt dien IPS für das WLAN auszuschließen - was müsste ich dort genau skippen? Alle DDoS Counter stehen auf 0.

  • 0 in reply to Andreas Leopold

    Eigentlich benötigst du nur die Haken zu entfernen in DOS Protection. 

    Jedoch klingt das nicht nach einem Problem der DOS Protection gegen das Separate Zone.

    Bridge to AP LAN läuft nun auch noch? 

  • 0 in reply to LuCar Toni

    So sieht es momentan bei mir aus. RDP geht erst, seit dem ich die unteren beiden Rules zwischen Server und Client erstellt habe, wieder flüssig.

    Das AP Lan funktioniert auch - auch über WLAN.

     

  • 0 in reply to Andreas Leopold

    Bridge to AP LAN lässt den Traffic direkt am AP Interface raus, das bedeutet die XG wäre in deinem Fall nicht im Traffic inkludiert, liege ich da richtig? 

    Wenn du Bridge to AP LAN verwendet, fließt der Traffic vom Client direkt über den AP zum Switch und zum Ziel Client? 

    Dadurch hat das denke ich auch nichts mit dem AP an sich zu tun - Eher mit dem Traffic Flow.

    Separate Zone Traffic zwingt den AP, den Traffic zur XG zu senden, diese macht etwas und sendet dann weiter zum Ziel Client. Somit kommst du immer über die XG.

    Es scheint so, als würde deine XG etwas mit dem Traffic zu unternehmen und somit drosseln. Es muss nicht zwangsläufig mit dem AP / Separate Zone zu tun haben. 

  • 0 in reply to LuCar Toni

    Hallo!

    Ich habe mich wohl nicht ganz korrekt ausgedrückt.
    Das AP LAN funktioniert nicht nur von Client zu Client. Ich kann aus anderen Netzen aufs AP LAN zugreifen, z.B der besprochene RDP Tunnel.
    Auch kopieren ins AP LAN über die XG funktioniert einwandfrei.
    Und auch die Speedtests ins Internet bringen den vollen Speed der Leitung.

    Nicht so in der Seperaten Zone - hier schaffe ich nur einen Bruchteil der Durchsatzrate - auch werden viele Connections einfach gedroppt, sodass ich beim Browsen Seiten mehrmals neu laden muss usw.
    Der Ping hingegen ist nicht wesentlich schlechter, als im AP LAN.

    Also würde ich schon meinen, es hat was mit dem WLAN zu tun... Hinzu kommt die Tatsache, dass ich der Meinung bin, meine IPS wäre inaktiv laut Screenshot und ich trotzdem die RDP Probleme mit der Flood Protection habe.
    Ich habe zu dem Problem weder im IPS log, noch mit drppkg etwas gesehen. Nachdem ich trotzdem eine Ausnahme erstellt habe, ging es komischerweise.
    Kann die XG Firewall Traffic droppen, ohne dass dies irgendwo aufscheint?
    Das wäre schon sehr sonderbar, aber ich habe wirklich kein großes Vertrauen in das Produkt, vor allem was die Nachvollziehbarkeit von Problemen anbelangt.

  • 0 in reply to Andreas Leopold

    Persönlich habe ich noch nie eine Appliance gesehen, die Ihre Drops nicht aufgezeichnet hat.

    Hast du mal einen Wireshark Dump durchgeführt? 

    https://community.sophos.com/products/community-chat/f/knowledge-base-article-suggestions/105811/how-to-tcpdump-on-xg

    Dump beides gleichzeitig in eine File und lad die File herunter. Öffne Sie via Wireshark und schau, was genau passiert. 

  • 0 in reply to LuCar Toni

    Hallo!

    Das geht mir etwas zu tief in die Materie, da blicke ich dann wahrscheinlich nicht mehr durch. Auf jeden Fall macht meine XG Dinge, die sie nicht machen sollte. Und Ändern der MTU beeinflusst die Performance nachweislich. Ich denke, irgendwas passt da bei WIFI Interfaces nicht.

    Ich werde jetzt aber einen VLAN Switch nehmen und das Guest WLAN in ein VLAN bridgen - mal sehen, ob ich das Problem damit umgehen kann... Ich hoffe jedoch sehr stark darauf.