09.03.2024, aktualisiert am 10.03.2024

4430

Sophos XGS116 sperrt willkürliche Websites

Mahlzeit zusammen.

Wir haben eine wirklich kuriose Situation an einer Außenstelle.

Gegeben sind eine Sophos XGS116 (neueste Firmware) und ein 250 MBit Glasfaser Anschluss, symmetrisch mit statischer IP.

Die Sophos ist direkt am ONT mittels RJ45 angeschlossen und übernimmt die PPPoE Einwahl (VLAN 7).

Es gibt zum Testen eine Any to Any Regel.

Keine zusätzlichen Lizenzen für Webfiltering, IDS/IPS, Geoblocking oder andere Dienste vorhanden.

Es gibt nur die Default NAT Regel für den Internetzugriff.

Sobald man beispielsweise https://duckduckgo.com oder https://datevsmartit.cloud.com aufruft, wird man nach ein paar Versuchen die Site zu laden mit einer Zeitüberschreitung begrüßt.

Andere Websites wie Google, Bing, Datev.de, Wikipedia.de, Synology.com, etc. öffnen sich.

Ein Draytek 2860 mit Any to Any Regel am selben Glasfaser Anschluss mit konfigurierter PPPoE Einwahl lässt alle Websites problemlos ansteuern.
Auch geht der Aufruf aller Websites gefühlt 50 % schneller.

Stöpsele ich die Sophos wieder an > gleiches Bild wie vorher, ohne Möglichkeit die genannten Websites zu öffnen und alle anderen sind zäh.

Ändere ich die MTU auf dem WAN Interface der Sophos auf 1420 und MSS auf 1360, geht es für ca. 60 Sekunden, danach ist gar keine Internet-Konnektivität möglich, bis ich die MTU Einstellungen wieder ändere.
Dann geht es wieder ca. 60 Sekunden und verreckt dann erneut.

Packe ich die Sophos in eine Kaskade mit einem anderen Internet Router an einen anderen Internetanschluss, geht der Aufruf der Websites ohne Probleme an der Stelle und das pfeilschnell.

Das Firewall Log weist bei dem Verbindungsaufruf der betreffenden Websites "Invalid Traffic - Could not associate packet to any connection" aus.

Der Kabelhai zeigt das im folgenden Sophos Forum Thread beschriebene Verhalten.

https://community.sophos.com/sophos-xg-firewall/f/discussions/103574/tro ...

Das Verhalten ist beständig, auch nach Neustarts der Firewall und Clients. NSLookup und Ping auf die Websites werden anstandslos beantwortet.

Als DNS Server werden der primäre und sekundäre server von Quad9 verwendet (9.9.9.9, 149.112.112.112). Auch andere DNS Server (Cloudflare, Google, Umbrella, Provider DNS) lieferten keinen Unterschied.

Aktuell kann ich keine weiteren Tests durchführen, da die Leute, warum auch immer, gerne arbeiten wollen

Danke fürs Miträtseln.

Falls Infos fehlen, gerne fragen.

Gruß
Marc

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 13924138514

Url: https://administrator.de/forum/sophos-xgs116-sperrt-willkuerliche-websites-13924138514.html

Ausgedruckt am: 25.12.2024 um 07:12 Uhr

56 Kommentare

Neuester Kommentar

Mit rätseln hat das, wie üblich in der IT, nichts zu tun!
Klingt eher nach der üblichen MTU / MSS Problematik auf dem PPPoE WAN Port was du vermutlich im Eifer des Gefechts nicht beachtet hast?! 🤔
https://www.cisco.com/c/de_de/support/docs/long-reach-ethernet-lre-digit ...
1500 - <PPPoE Overhead> - <VLAN Tag> = 1488
Ein Ping Check hilft:
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/de/19863/Ping-Test-zur-Ermittlung-der-optimalen-M ...

Zitat von @aqui:
Mit rätseln hat das, wie üblich in der IT, nichts zu tun!

Klingt eher nach der üblichen MTU / MSS Problematik auf dem PPPoE WAN Port was du vermutlich im Eifer des Gefechts oder aus Unwissenheit nicht beachtet hast?! 🤔

Wie oben geschrieben, mit der MTU habe ich herumgespielt und es kam keine Besserung zustande.

Da der Draytek keinerlei Anpassung benötigte und ohne Probleme lief, habe ich dem Thema zunächst keine Bedeutung beigemessen.

Ein Ping Check hilft:
https://blog.boll.ch/basic-stuff-mtu-groesse-mit-ping-testen/
https://kb.netgear.com/de/19863/Ping-Test-zur-Ermittlung-der-optimalen-M ...

Schaue ich mir nochmal genauer an.

Danke.

Gruß
Marc

Da der Draytek keinerlei Anpassung benötigte und ohne Probleme lief,

Einige Hersteller machen die MTU / MSS Anpassung automatisch bei PPPoE WAN Ports andere aber nicht, deshalb ist es immer ratsam nachzusehen um nicht rätseln zu müssen.

Danke @aqui. Gehe ich nächste Woche mal im Detail nach.

Im Draytek gibt es einen "Detect" Knopp. Eventuell wird der "automatisch gedrückt", sobald man die Einstellungen speichert. Die Anzeige der MTU bleibt jedenfalls auf 1500.

Gruß
Marc

Die Anzeige der MTU bleibt jedenfalls auf 1500.

Das wäre zumindestens für den PPPoE Port falsch oder irreführend, denn 1500 als MTU führt dort dann gesichert zu Fragmentierungsproblemen.
Hier ein Beispiel eines Cisco Router PPPoE Ports:

Dialer0 is up, line protocol is up
  Description: PPPoE Dialin VDSL
  Internet address is x.y.20.224/32
  MTU 1488 bytes, BW 50 Mbit/sec, DLY 20000 usec,
     reliability 255/255, txload 255/255, rxload 255/255
  Encapsulation PPP, LCP Closed, loopback not set
  Keepalive set (10 sec)
  DTR is pulsed for 1 seconds on reset 

Moin @aqui,

1500 - <PPPoE Overhead> - <VLAN Tag> = 1488

dir ist da fürchte ich ein kleiner Fehler unterlaufen.

Ohne V-LAN:
1518 Bytes - <Ethernet Header & Trailer (18 Bytes)> - <PPPoE-Header (8 Bytes)> = MTU 1492

Mit V-LAN:
1522 Bytes - <Ethernet Header & Trailer (18 Bytes)> - <V-LAN TAG (4 Bytes)> - <PPPoE-Header (8 Bytes)> = MTU 1492

Sprich, ein V-LAN Tag hat auf die MTU normalerweise überhaupt keine Auswirkung, weil beim Einsatz vom VLAN, die gesamte Ethernet-Framegrösse von 1518 Bytes auf 1522 Bytes erhöht wird.

Ein Ping über PPPoE sollten bei korrekter Konfiguration ...

1518 Bytes - <Ethernet Header & Trailer (18 Bytes)> - <PPPoE-Header (8 Bytes)> - <IP Header (20 Bytes)> - <ICMP Header (8 Bytes)> = 1464 Bytes Max. ICMP Payload.

... somit im Normalfall mit 1464 Bytes möglich sein und zwar mit oder ohne VLAN.

Gruss Alex

Moin Marc,

Falls Infos fehlen, gerne fragen.

baut die XGS die WAN Verbindung eventuell per Dual Stack, sprich mit IPv4 und IPv6 auf?

Gruss Alex

Zitat von @MysticFoxDE:

Falls Infos fehlen, gerne fragen.

baut die XGS die WAN Verbindung eventuell per Dual Stack, sprich mit IPv4 und IPv6 auf?

Morschen.

Nope. Ist ein reiner IPv4 Anschluss.

Gruß
Marc

Moin Marc,

Nope. Ist ein reiner IPv4 Anschluss.

🤔 ... sehr interessant.

Einer unserer Kunden hat übrigens mit seinen XGS's dasselbe Problem und hat deshalb auch schon ein Supportticket bei Sophos geöffnet. Wie da der Stand ist weis ich jedoch nicht, da seine XGS's von einem anderen Dienstleister betreut werden. Ich frag aber mal am Montag nach, ob sich bei denen diesbezüglich etwas bewegt hat.

Was für ein Gerätchen hängt den genau noch zwischen der XGS und dem WAN?

Gruss Alex

Zitat von @MysticFoxDE:
Einer unserer Kunden hat übrigens mit seinen XGS's dasselbe Problem und hat deshalb auch schon ein Supportticket bei Sophos geöffnet. Wie da der Stand ist weis ich jedoch nicht, da seine XGS's von einem anderen Dienstleister betreut werden. Ich frag aber mal am Montag nach, ob sich bei denen diesbezüglich etwas bewegt hat.

Das ist sehr interessant. Zum Support von Sophos habe ich momentan keine gute Meinung. Als letztes Jahr für zwei Wochen das Cloud Portal wegen einer Migration seitens Sophos unten war, konnte das Registrieren eben jener XGS116 nicht durchgeführt werden. Der Support war überhaupt keine Hilfe an der Stelle.

Was für ein Gerätchen hängt den genau noch zwischen der XGS und dem WAN?

Ein Nokia 7368 ISAM G-010G-A ONT, wie der auf dem Bild (aber ohne die Chinesischen Zeichen

Gruß
Marc

Moin Marc,

na ja, für die Migration und die damit verbundenen Problemchen, kann der Support nicht wirklich etwas.
Ich habe die letzten Monate extrem viel mit diesem zu tun gehabt und muss sagen, dass sich dieser definitiv gebessert hat.
Habe nach Jahren sogar mal wieder einen deutschen Supportler dran gehabt. 🤪

OK, zurück zum Wesentlichen, ich denke die XGS haben gerade ein generelles Problem. 😔

Ich habe nämlich soeben bei einem Kunden bei dem ich gerade ein par neue RDS-SH's aufsetzen muss, einen Speedtest über seinen 1000/50 Anschluss drüber laufen lassen und bekomme aktuell das folgende zu sehen.

😭 🤢🤮

Ich habe zum Testen übrigens auch für den entsprechenden Host eine HOST to ANY mit ANY Regel ohne jegliche Filterung angelegt.

Zu den RDS-SH's ist nun wohl die nächste Aufgabe/Problem dazugekommen. 😩

Melde mich, sobald ich was gefunden habe.

Gruss Alex

na ja, für die Migration und die damit verbundenen Problemchen, kann der Support nicht wirklich etwas.

Uns hat der Support zwei Wochen vorgegaukelt uns bei der Registrierung zu unterstützen.

Es waren immer Antworten, welche mit einem Link versehene waren, welcher zu einem Tutorial führte, welcher die Registrierung bei funktionalem Cloud Portal zeigte.

OK, zurück zum Wesentlichen, ich denke die XGS haben gerade ein generelles Problem.

Sind die eventuell unterdimensioniert? Oder gibt es ein Firmware Problem?

Da unsere XGS bereits drei Firmware Updates erhalten hat, darf man weitere Aktualisierungen nur mit gültiger Lizenz installieren.

Ist aber erst einmal vor Ort nicht geplant dort Lizenzen einzubauen.

Melde mich, sobald ich was gefunden habe.

Danke.

Gruß
Marc

Moin Marc,

Sind die eventuell unterdimensioniert?

Ich, respektive der entsprechende Kunde, hat in dem Fall eine XGS 2100 unter dem Hintern, die sollte die 1G eigentlich locker packen.

Die CPU ist es auf jeden Fall nicht.

Oder gibt es ein Firmware Problem?

Das schon eher.
Habe die letzten Monate ja nicht wirklich ohne Grund duzende Male mit dem Support telefoniert. 😔
Die sollten aber nicht wirklich etwas mit diesem Problem zusammenhängen.

Ich mache später mal einen Support Case auf, muss mich jetzt aber erstmal um die RDS-SH's kümmern.

Gruss Alex

Ich mache später mal einen Support Case auf, muss mich jetzt aber erstmal um die RDS-SH's kümmern.

Bonne chance und einen schönen Restsonntag trotz Maloche

Gruß
Marc

Moin Marc,

Bonne chance und einen schönen Restsonntag trotz Maloche

ähm, ich habe soeben die etwa zweistündige Session mit dem Sophos Support beendet. 😩
Der gute L1 Sportler hat nun mind. 3 BUG's aufgenommen und morgen um 7:00 soll ich einen Anruf vom L2/L3 bekommen.

Sobald ich die MSS am WAN Interface ändere, sei es auch auf denselben Wert, habe ich für einen kurzen Augenblick wieder volle Geschwindigkeit und nach einer Weile bricht diese wieder ein. 😭

Gruss Alex

Morschen Alex.

Das deckt sich mit meiner Erfahrung

Welche Lizenzen / Subscriptions sind bei deiner / deinen Sophos im Zugriff hinterlegt?

Ich würde leicht bis schwer säuerlich werden, wenn es an der neuesten Firmware und fehlenden Lizenzen in Kombination liegt.

Frei nach dem Motto: "Du hast unser Produkt gekauft? Schön. Aber ohne Lizenzen geht das Teil nicht."

Gruß
Marc

Moin Marc,

ne, mit der Lizenz hat das Ganze nichts zu tun, den die XGS bei der ich gestern das Problem beobachtet habe,
ich mit sämtlichem Schnickschnack lizenziert.

Ich habe bei dem Test übrigens keines der Layer 7 Schutz-Features der XGS benutzt, sondern habe für den Testclient nur eine CLIENT mit ANY to ANY Regel angelegt + NAT. Ich sehe im tcpdump jedoch, dass auf jeden Fall irgend ein Layer 7 Filter/Engine, in den Datenfluss eingreift. 😬

Gruss Alex

Ich sehe im tcpdump jedoch, dass auf jeden Fall irgend ein Layer 7 Filter/Engine, in den Datenfluss eingreift. 😬

Das ist es, was ich bisher vermute und nicht verstehe.

Selbst nach kompletter Zurücksetzung auf Werkseinstellungen scheint immer etwas aktiv zu sein, auch ohne Lizenz dafür.

Aber willkürlich selektiv in meinem Fall. Auch nach einem Neustart, niemand anders im Netzwerk angeschlossen, bleibt das Verhalten dasselbe.

Die MTU wird bei mir nicht das Problem sein. Warum sollte alles Mögliche an Websites gehen, nur (aktuell vier Websites bekannt) ein paar nicht?

Werde bei mir auch nochmal einen TCPDump anlegen und dann ebenfalls ein Ticket bei Sophos aufmachen.

Gruß
Marc

Moin Marc,

ich habe soeben ein Erlebnis der dritten Art hinter mir.

Vorhin hat sich der L2 Support gemeldet und wir konnten heute die Probleme von Gestern, überhaupt nicht mehr nachvollziehen, die ich gestern diverseste Male mit dem L1 Support nachstellen konnte. 😭

Der tcpdump sieht aber heute auch noch stellenweise sehr gruselig aus ...

23:59:37.340848 PortMGMT, IN: In a4:bf:01:64:xx:xx ethertype IPv4 (0x0800), length 5896: xxx.xxx.xxx.xxx.62775 > 62.245.181.54.8080: Flags [.], seq 7986432:7992272, ack 3668, win 1023, length 5840: HTTP

... . 😖

Ich muss jetzt mal kurz eine neue VM Aufsetzen und Wireshark auf dieser installieren, damit Sophos direkt am Client/Quell-Host sehen kann, dass dieser selbst keine Ethernet Pakete mit einer Grösse von 5840 Bytes versendet. 🙃

Gruss Alex

Zitat von @MysticFoxDE:
ich habe soeben ein Erlebnis der dritten Art hinter mir.

Vorhin hat sich der L2 Support gemeldet und wir konnten heute die Probleme von Gestern, überhaupt nicht mehr nachvollziehen, die ich gestern diverseste Male mit dem L1 Support nachstellen konnte. 😭

Ist das nicht immer so

Der tcpdump sieht aber heute auch noch stellenweise sehr gruselig aus ...

Wat?!?! Da scheint etwas massig daneben zu laufen.

Welche Firmware ist bei deinen Sophos Kisten gerade aktiv?

Gruß
Marc

Moin Marc,

Wat?!?! Da scheint etwas massig daneben zu laufen.

🙃 ich denke ich habe gerade rausgefunden was es ist, muss es aber noch genauer durchtesten.

Welche Firmware ist bei deinen Sophos Kisten gerade aktiv?

20.0.0

Gruss Alex

🙃 ich denke ich habe gerade rausgefunden was es ist, muss es aber noch genauer durchtesten.

Die Spannung steigt

Gruß
Marc

Moin Marc,

Die Spannung steigt

musst dich noch etwas gedulden.
Ich kann die entsprechenden Features auf den NIC's per Advanced Shell leider nicht wirklich deaktivieren und warte nun auf das Feedback vom Support.

Ich kann das Problem übrigens mittlerweile wieder teilweise reproduzieren, zumindest auf einem der beiden eigentlich absolut identischen WAN Anschlüsse. 🙃

Gruss Alex

Absolut kein Problem.

Dass da vermutlich ein Layer 7 Filtering aktiv ist ohne eine Einstellung vorgenommen zu haben, finde ich befremdlich.

Ich weiß nicht, ob ich morgen dazu komme von meinem Patienten einen TCPDump anzufertigen.

Aktuell ist viel los mit Audit, neuem Firewall Cluster und dem Tagesgeschäft.

Aber wer will sich schon beklagen

Allemal besser als Langeweile.

Danke für deine forensische Dokumentation und dem Teilen der Infos.

Das wird einigen Leuten sicher weiterhelfen.

Gruß
Marc

Moin Marc,

Aber wer will sich schon beklagen

Allemal besser als Langeweile.

👍👍👍

ich hatte heute übrigens eine längere Supportsession mit dem Sophos Support und es hat sich bei dieser herausgestellt, dass die XGS an diesem Problem überhaupt nicht schuld ist, sondern eher der ISP Router der davor hängt und oder das Transit-Netz der Vodafone danach. 😒

Denn solange ich den ISP Router selbst mit der vollen Payload (1472Bytes) anpinge ...

... werden alle Pakete sauber quittiert.

Sobald ich jedoch ein Ziel im Internet mit der vollen Payload (1472Bytes) anpinge, bekomme ich das folgende zu sehen ...

... 😭

Nun muss ich als nächstes, wohl der Vodafone in die Wade beissen. 😋

Denn über den zweiten absolut identischen WAN Anschluss des entsprechenden Kunden ...

... geht der Ping Richtung Internet mit der vollen Payload (1472Bytes) ohne Probleme.

By the Way, dass bei diesem Anschluss ein Ping mit 1472 Bytes nach "aussen" möglich ist, hängt damit zusammen, dass die entsprechenden Anschlüsse keine PPPoE Anschlüsse sind, sprich, man beim Transfer keine 8Bytes für den PPPoE Header verliert.

Na ja, auf jeden Fall schon mal ein Stück weiter und der Vodafone Support braucht mir nun auch nicht mehr zu erzählen, dass das Problem bestimmt am internen Securitygateway liegt.

Melde mich wieder, sobald ich was neues habe.

Gruss Alex

Moin Marc,

ich habe mich bei meinem Problem etwas weiter durchgegraben.

Folgend zuerst die tracert Infos betreffend des gestörten Anschlusses Richtung 1.1.1.1.

Und bereits der erste Routing-Hop (82.82.7.233) ...

... macht bei einer ICMP Payload von > 1432Bytes bereits dicht. 😬

Na ja, habe soeben ein Ticket bei Vodafone aufgemacht, mal schauen was dabei herauskommt.

Vielleicht ist bei dir auch nicht die XGS direkt schuld an deinem Problem, sondern einer der Hops dahinter.

Gruss Alex

Nabend Alex.

Das sind absolut interessante Erkenntnisse.

Was mir nur vollkommen meine am oberen Ende meines Körpers sitzende Murmel kreisen lässt, warum ein Draytek 2860 mit einer MTU von 1492 am selben WAN Anschluss mittels RJ45 am selben ONT keinerlei Probleme macht.

Der erwähnte Autodetect Knopf beim Draytek ermittelt als optimale MTU die 1492.

Ich muss schauen, ob ein hartes Eintragen der MTU auf 1492 einen Unterschied macht oder nicht. Ich meine die Einstellung suksessive heruntergeschraubt, aber nie auf 1492 gesetzt zu haben.

Der ISP wird hier wohl an diesem Anschluss etwas anders machen, als am quasi identischen Anschluss unseres Hauptstandortes.

Nochmals vielen Dank für die Forensik!!!

Ich berichte, sobald ich mal die Gelegenheit des Tests bekomme.

Gruß
Marc

Moin Marc,

Was mir nur vollkommen meine am oberen Ende meines Körpers sitzende Murmel kreisen lässt, warum ein Draytek 2860 mit einer MTU von 1492 am selben WAN Anschluss mittels RJ45 am selben ONT keinerlei Probleme macht.

Der erwähnte Autodetect Knopf beim Draytek ermittelt als optimale MTU die 1492.

die XG(S) müsste die MTU der PPPoE Schnittstelle, eigentlich ebenfalls automatisch auf 1492 setzen.

Siehe ...
https://support.sophos.com/support/s/article/KB-000036093?language=en_US

Ich muss schauen, ob ein hartes Eintragen der MTU auf 1492 einen Unterschied macht oder nicht. Ich meine die Einstellung suksessive heruntergeschraubt, aber nie auf 1492 gesetzt zu haben.

Wie oben geschrieben, sollte die MTU der PPPoE Schnittstelle automatisch auf 1492Bytes stehen.
Kannst aber wie im oberen Artikel beschrieben, sicherheitshalber über die Advanced Shell dennoch mal überprüfen.

Der ISP wird hier wohl an diesem Anschluss etwas anders machen, als am quasi identischen Anschluss unseres Hauptstandortes.

Ja, das Routing innerhalb des Vodafone Netzes, sieht beim Anschluss A fast komplett anders aus, als beim Anschluss B.
Na ja, OK, ich hätte vielleicht noch erwähnen sollen, dass der Anschluss A noch ein automatisches LTE Backup seitens Vodafone hat, wahrscheinlich ist auch deshalb das Routing etwas anders.

Habe vorhin übrigens um kurz vor 23 Uhr noch einen Rückruf von einem Vodafone Techniker bekommen.
Als ich diesem jedoch versucht habe zu erklären, dass zwischen deren Router beim Kunden und dem Internet, also in deren Netz, eine Komponente keine Ethernet-Pakete > 1478Bytes verarbeiten kann, obwohl 1518Bytes (Ohne VLAN) durchgehen müssten, ist dieser wohl geistig etwas ausgestiegen, was ich ihm um diese Uhrzeit aber auch gönne. Denn anstelle nach dem Problem intern zu suchen, hat mir der gute für morgen einen Termin für einen vor Ort Techniker zugesagt. 🙃

Das wird morgen bestimmt lustig.

Nochmals vielen Dank für die Forensik!!!

Sehr gerne!
Wir Admins, Feldtechniker, Systemintegratoren, sitzen am Ende des Tages doch eh alle im selben und immer verrückter und immer grösser werdendem IT-Boot. 😁

So, jetzt muss ich aber schnell in mein Fuchsbau kriechen und die eigenen Akkus für morgen per Quick-Charge mal kurz nachladen. 🤪

Gruss Alex

Moin Marc,

kleines Update von meiner Seite.
Wie ich schon geschrieben habe, habe ich vorgestern Abend noch ein Support Ticket bei Vodavone aufgemacht und versucht dem Supportler, das Problem zu schildern, sprich, dass auf dem Weg von deren ISP-Router der beim Kunden steht zum nächsten Hop, bei einer Schnittstelle die MTU wahrscheinlich mit 1460Bytes anstelle 1500 Bytes konfiguriert ist. Ich hatte jedoch nicht das Gefühl, dass der entsprechende Supportler auch nur eine Silbe verstanden hat.

Gestern Mittag sind dann zwei Vodafone Techniker vor Ort eingeschlagen. Ja OK, es waren nicht wirklich Techniker von der Vodafone selbst, sondern nur von ihn beauftragte. 🙃
Einer der entsprechenden Techniker hat dann den Anschluss durchgemessen und gemeint, er habe eventuell den Fehler gefunden. Der Stecker am Koaxkabel war seiner Ansicht nach nicht fest genug angezogen, wodurch seiner Meinung nach die Dämpfungswerte nicht optimal waren, er habe nun den Stecker nachgezogen und ich soll bitte nochmals testen. 😬

Ich habe mir in diesem Augenblick ganz fest auf die Zunge gebissen damit ich ja nichts falsches sage und habe einfach den Test wiederholt und zurückgemeldet, dass das Problem damit leider nicht behoben ist.
Danach sind die Techniker zum nächsten Outdoor DSLAM verschwunden und haben dort irgendwas durchgemessen.

Kurze Zeit später meldete sich ein Vodafone Supportler aus einem Callcenter und meinte, er möchte gerne einen Workaround probieren und ob ich danach nochmals testen könnte. Ich fragte ihn daraufhin, welchen Workaround er den genau machen möchte und bekam dann als Antwort, dass er die MTU der WAN Schnittstelle des vor Ort stehenden ISP-Routers, gerne testweise mal auf !!! 1700 !!! Bytes stellen würde. 🙃
Ich habe ihn daraufhin mehrfach gebeten diese Änderung ja nicht zu machen, da das die Sache höchstens verschlimmern würde.

Kurz darauf hat er sich wieder gemeldet und gemeint, dass die Techniker Outdoor DSLAM auch ein Problem gefunden und beseitigt hätten, ich soll doch bitte nochmals testen.
Wahrscheinlich haben die Techniker am Outdoor DSLAM auch nur irgendwelche Stecker festgezogen um die Dämpfung zu verbessern oder haben den Anschluss einfach auf einen anderen Port umgeklemmt, geholfen hat das alles jedoch nichts.

Für heute haben Techniker dann einen weiteren Termin vor Ort geplant, bei dem die über mehrere Stunden den wichtigsten WAN Anschluss des Kunden lahmlegen möchten um dessen Dämpfung noch genauer durchzumessen. 😭

Und ja, ich habe es der Vodafone Hotline mehrfach versucht zu erklären, dass dieses Problem niemals von einer schlechten Anschlussdämpfung kommen kann, sondern eher von einer falschen Konfiguration einer der beteiligten Komponenten. Ich habe jedoch noch nicht das Gefühl gehabt, dass sich auch nur einer der bisher beteiligten Vodafone Techniker, wenigstens ansatzweise auch mit Routing auskennen würde. 😔

Na ja, ich lass mal den Fall heute eskalieren, mal schauen was danach passiert.

Wie kommst du bei dir voran?

Gruss Alex

Ich kann mir entsprechende Entgleisungen deines Gesichts lebhaft vorstellen.

Beim Lesen sträuben ich sogar die Haare der Katze der Nachbarn.

Das mit der 1700er MTU finde ich eine gute Lösung und sollten wir überall so machen. Ich meine mehr ist doch immer besser oder

Nochmals danke für die Dokumentation des Ganzen, ein schönes Wochenende und starke Nerven für die zukünftigen "Experten-Besuche"

Gruß
Marc

Moin Marc,

Nochmals danke für die Dokumentation des Ganzen, ein schönes Wochenende und starke Nerven für die zukünftigen "Experten-Besuche"

der vor Ort Techniker war heute nochmals da und hat einen Signalverstärker getauscht,
weil der bisherige anscheinend über 8 Jahre alt war und seiner Aussage nach nicht mehr ganz ordentlich funktioniert hat. Danach hat er mich angerufen und gebeten zu Testen ob das Problem dadurch nicht schon behoben wäre.

Ich habe die Messung gemacht und natürlich hat das ganze nichts geholfen und dieses mal habe ich mirt auch nicht auf die Zuge gebissen, sondern dem Techniker so freundlich ich konnte gesagt, dass egal wieviel er an der an der Signalqualität des Anschlusses schrauben würde, er damit das Problem nicht lösen würde, weil es mit der Signalstärke überhaupt nichts zu tun hat. Dann habe ich ihm auch in ruhe erklärt warum das so ist, er hat daraufhin seinen Chef angerufen, dem ich per Mail noch ein paar Zusatzinfos geschickt habe und seit dem habe ich von den beiden nichts mehr gehört. Danach habe ich jedoch einen Anruf von dem Callcenter Supportler bekommen, mit der Nachricht, dass das Problem nun gefunden und behoben sein und ich soll doch bitte nochmals Testen. Das tat ich auch und meldete zurück, dass welches Problem bisher auch immer behoben wurde, es nicht wirklich das richtige gewesen ist, da das Problem bei unserem Kunden noch nach wie vor bestehe.

So langsam werde ich jedoch richtig sauer.
Sprich, nu Vodafone, nu pagadi! 😡

Für Insider:
Ja, OK, der Wolf hat den Hasen ja nie wirklich erwischt, aber ich bin ja auch kein Wolf und Vodafone ist ja auch kein niedlicher Hase. 🤪

Für Nichtinsider:
https://www.youtube.com/watch?v=UYtqSfheVNs

Gruss Alex

Moin Marc,

kleine Zwischeninfo, das Problem ist fast pünktlich zum WE gelöst. 😁
Die Kurzfassung ... der Anschluss hat tatsächlich nur eine MTU von 1460Bytes. 🙃
Die Langfassung mache ich morgen, den ohne eine anständige Zeichnung/Skizze, werden sonst meine Erklärung wahrscheinlich nur die wenigsten wirklich verstehen.

Kleiner Spoiler.
Es ist wegen einem L2TP dazwischen und zwar auf der ISP Seite. 😔

So, jetzt muss ich aber schnell meine beiden Hausdrachen füttern, sonst werde ich noch selbst gefressen. 🤪

Gruss Alex

Es ist wegen einem L2TP dazwischen

Autsch... Der Dativ ist dem Genitiv sein Tod! 😉
Ich hatte ja gehofft es sind doch noch die 4 Bytes vom VLAN Header...! 🤣

Moin @aqui,

Ich hatte ja gehofft es sind doch noch die 4 Bytes vom VLAN Header...! 🤣

mir wäre ein zusätzlicher Overhead durch die 4Bytes des VLAN-Header, auch wenn diese normalerweise auf die MTU keine Auswirkung haben, in den Fall viel lieber gewesen, wie jetzt der zusätzliche 40Bytes Overhead durch den L2TP-Tunnel. 😔😭

Vor allem bin ich auf die Vodafone sauer, weil sie ein Produkt mit einer "besonderen Eigenschaft" anbieten, über die jedoch weder der Kunde informiert wurde, noch die eigenen Techniker die diesen Anschluss dem Letzt umgestellt haben und auch nicht die eigene L1 und L2 Hotline. 😡

Gruss Alex

Vor allem bin ich auf die Vodafone sauer

Hattest du von Vodkafön ernsthaft etwas anderes erwartet?? Aber das mit dem verschwiegenen L2TP Tunnel ist schon echt frech... Besonders wenn es ein Business Anschluss ist und man dem Endkunden das nicht mitteilt. Ohne Worte...

Ohne beizutragen vermocht zu haben: Ich habe mit Freude hier mitgelesen. Großartig, Alex, wie Du die Sache verfolgt und zur Lösung gebracht hast. Und nebenher noch das Drachenrudel bekocht. Respekt!
Full ACK zu

Wir Admins, Feldtechniker, Systemintegratoren, sitzen am Ende des Tages doch eh alle im selben und immer verrückter und immer grösser werdendem IT-Boot. 😁

Allerdings sind wir nicht ganz unschuldig, weil Admins zu oft diejenigen belohnen, die uns pseudokomfortable - aber von Standards abweichende - Lösungen servieren deren Komfort dann später in Abhängikeit und mangelnder Administrierbarkeit verpufft.

Vodafone wurde einmal mehr seinem Ruf gerecht.
Immerhin haben sie zur Lösung beigetragen - aber zum Erfolg nur Deinem beharrlichen Engagement sei Dank. Otto Normalkunde wäre fraglos auf halber Strecke gestorben.

Hoffentlich klärt sich das nun auch für den TO @radiogugu. Ich werde im übrigen (am nächsten Freitag) mal Easybell bitten, die MTU von einigen Kunden auf 1700 zu setzen (auf Empfehlung von Vodafone)

Viele Grüße, commodity

Moin @aqui,

Hattest du von Vodkafön ernsthaft etwas anderes erwartet??

ja, ich habe definitiv was anderes erwartet, vor allem weil es sich um einen Buisiness-Anschluss handelt!

Aber das mit dem verschwiegenen L2TP Tunnel ist schon echt frech... Besonders wenn es ein Business Anschluss ist und man dem Endkunden das nicht mitteilt. Ohne Worte...

Na ja, böswillig haben diese Info die entsprechenden Supportler ja auch nicht verschwiegen.
Genaugenommen haben die beteiligten Supportler, die vor Ort Techniker und auch der, respektive die Technikerin, die diesen Anschluss dem Letzt um das LTE/5G Backup erweitert haben, schlichtweg nicht die entsprechenden Informationen gehabt, weil diese ja ach so unwichtige Änderung gegenüber einem "normalen" Anschluss, schlichtweg nirgends dokumentiert ist und mit nirgends meine ich auch nirgends, sprich auch nicht bei der Vodafone intern. 🤢🤮

Denn anstelle, dass der entsprechende Kunde vor Vertragsabschluss auf dieses wichtige Detail hingewiesen wurde, musste dieser, respektive ich an seiner Stelle, mich nun Tagelang mit diversesten Hotlines rumquellen, bis man durch Reverse-Engineering herausgefunden hat, woran es wirklich gehapert hat. 😔

Und nein, ich gebe hierbei primär ganz sicher nicht der "outgesourcten" L1-Hotline die Schuld und auch nicht der "outgesourcten" L2-Hotline und auch nicht den "outgesourcten" vor Ort Technikern und auch nicht der Technikerin die den Anschluss eingerichtet hat, die wie die anderen zuvor genannten natürlich ebenfalls "outgesourct" ist.
Aber, auf die oberen Etage von Vodafone, die für diesen ganzen Outsourcing-Schwachsinn und vor allem auch für die absolut schlechte Abstimmung dazwischen, in meinen Augen hauptsächlich verantwortlich ist, auf die bin ich sehr wohl sauer und zwar so richtig, weil sie diesen ganzen selbstverbockten Outsourcing-Zoo, überhaupt nicht mehr im Griff haben. 😡

Gruss Alex

Moin Marc,

sorry übrigens, dass ich deinen Post etwas gekapert habe.
Ich habe dein Problem jedoch nicht aus dem Blickwinkel verloren, denn die XGS läuft unter V20.0.0 definitiv nicht ganz rund, daher stehe ich mit dem Sophos Support auch noch nach wie vor in Verbindung.

Gruss Alex

Zitat von @MysticFoxDE:
sorry übrigens, dass ich deinen Post etwas gekapert habe.

Überhaupt kein Problem. Wie schon bemerkt, ist das gier ein wichtiger Thread, damit andere sich ihre Nudeln nicht weichkochen, wegen einem ähnlichen Dilemma.

Ich habe dein Problem jedoch nicht aus dem Blickwinkel verloren, denn die XGS läuft unter V20.0.0 definitiv nicht ganz rund, daher stehe ich mit dem Sophos Support auch noch nach wie vor in Verbindung.

Ich muss dringend den abschließenden Test bei meiner Sophos durchführen, komme nur absolut nicht dazu

Sobald das fertig ist, wird der Thread auch auf "gelöst" gesetzt werden

Nochmals ein DICKES Danke Alex.

Gruß
Marc

Weiche Nudeln machen aber nicht gierig. Das machen nur al dente Nudeln.

wegen einem ähnlichen Dilemma.

Autsch... Der Dativ ist dem Genitiv sein Tod!

Moin Marc,

Überhaupt kein Problem. Wie schon bemerkt, ist das gier ein wichtiger Thread, damit andere sich ihre Nudeln nicht weichkochen, wegen einem ähnlichen Dilemma.

ich habe jetzt einen eigenständigen Beitrag mit der Lösung für das Vodafone spezifische Problem gepostet,
damit ähnlich geplagte diese schneller finden können.

VODAFONE - "Business Internet Pro Cable" plus "Mobile Backup" gleich "MTU-Desaster"

Nochmals ein DICKES Danke Alex.

Sehr gerne.
Wie schon geschrieben, meiner Ansicht nach sitzen wir alle (IT-Techniker/Admins/Integratoren) +- im selben IT-Boot, mit dem wir irgendwie durch ein immer ungemütlicher werdendes Fahrwasser durchkommen müssen und je besser wir zusammenhalten umso eher kommen wir da auch gemeinsam alle durch. 😁

Gruss Alex

Moin @commodity,

Ohne beizutragen vermocht zu haben: Ich habe mit Freude hier mitgelesen. Großartig, Alex, wie Du die Sache verfolgt und zur Lösung gebracht hast.

danke, aber so ganz ist das Problem ja noch nicht gelöst, zumindest nicht das vom TO.

Und nebenher noch das Drachenrudel bekocht. Respekt!

Das ist halb so wild wie es sich bei mir vielleicht anhört, da meine Hausdrachen eher Richtung Disney gehen, sprich,
ja hin und wieder fauchen die schon rum und spucken auch mal Feuer, meistens ist sowohl der kleine als auch der grosse jedoch sehr friedlich.

Otto Normalkunde wäre fraglos auf halber Strecke gestorben.

Definitiv, daher finde ich den Sachverhalt auch besonders schlimm.😔

Hoffentlich klärt sich das nun auch für den TO @radiogugu.

Ich drücke @radiogugu auch kräftig die Daumen, jedoch habe ich bei seinem Problem eher die Befürchtung,
dass dieses weniger etwas mit der MTU zu tun hat, sondern eher mit den Wehwehchen der XGS V20.0.0.

Ich werde im übrigen (am nächsten Freitag) mal Easybell bitten, die MTU von einigen Kunden auf 1700 zu setzen (auf Empfehlung von Vodafone)

😂🤣😂🤣 👍👍👍

Vielleicht gönne ich mir in ca. 14 Tagen (01.04.2024) den Spass und bitte den Support, die zuvor offerierten Little-Jumbo-Frames doch mal testweise zu aktivieren. 🙃

Gruss Alex

Mahlzeit zusammen.

Das Martyrium ist vorbei

Ich habe die Sophos noch einmal komplett neu aufgesetzt.

Bei der Konfiguration der WAN Schnittstelle ist mir, eher zufällig, aufgefallen, dass man auf einer als der Zone "WAN" zugehörigen Schnittstelle etwas weiter unten ein kleines Untermenü "DSL Settings" hat. Dahinter verbirgt sich schlicht nur das Tag für VDSL.

Also habe ich dort alles konfiguriert und siehe da, es geht alles wie erwartet. Die betroffenen Websites können aufgerufen und es kann mit hoher Geschwindigkeit im restlichen Internet Surfing betrieben werden

Mein Fehler war anscheinend, dass ich ein VLAN erstellt und dieses an die physische Schnittstelle gebunden hatte wo der ONT angeschlossen ist.

Der Sophos Support war keine Hilfe an der Stelle. Hier kam kein entsprechender Hinweis., dass das so zu Problemen führt. Zumal das für mich bis dato immer der Weg der Wahl bei eine PFSense beispielsweise war.

Nach wie vor ist nicht geklärt, warum es dann so halb funktioniert hat und warum einige, spezielle Websites nicht aufrufbar waren.

Danke an euch @aqui und @MysticFoxDE für eure Mithilfe.

Gruß
Marc

Verstehe ich nicht ganz. Du hattest doch eingangs geschrieben:

Die Sophos ist direkt am ONT mittels RJ45 angeschlossen und übernimmt die PPPoE Einwahl (VLAN 7).

Kann man das Tag auch noch woanders setzen?

Viele Grüße, commodity

Zitat von @commodity:
Verstehe ich nicht ganz. Du hattest doch eingangs geschrieben:

Die Sophos ist direkt am ONT mittels RJ45 angeschlossen und übernimmt die PPPoE Einwahl (VLAN 7).

Kann man das Tag auch noch woanders setzen?

Hatte ein VLAN 7 Interface erstellt und dieses dann mit den PPPoE Daten gefüttert.

Das scheint die XGS116 nicht so dolle zu finden.

Gruß
Marc

Moin Marc,

Das scheint die XGS116 nicht so dolle zu finden.

die Erklärung scheint mir nicht ganz schlüssig zu sein, den trotz deiner nicht ganz üblichen WAN Konfiguration,
hat der Anschluss ja grundsätzlich funktioniert.

Ich denke, dass du durch das Neuaufsetzen, wahrscheinlich eher ein anderes Problem beseitigt hast.

Gruss Alex

Moin @commodity,

Kann man das Tag auch noch woanders setzen?

ja, bei der Sophos XG(S), kann man ein VLAN Tag bei einem PPPoE-WAN-Anschluss, tatsächlich auf zwei unterschiedliche Arten einrichten.

Den Weg den Marc genommen hat, ist bei der XGS jedoch nicht wirklich "gewollt" und ist auch offiziell nirgends dokumentiert, sollte aber dennoch funktionieren, weil er unter dem Strich +- dasselbe Ergebnis liefern sollte.

Gruss Alex

Zitat von @MysticFoxDE:

Das scheint die XGS116 nicht so dolle zu finden.

die Erklärung scheint mir nicht ganz schlüssig zu sein, den trotz deiner nicht ganz üblichen WAN Konfiguration,
hat der Anschluss ja grundsätzlich funktioniert.

Korrekt. Wirklich zufriedenstellend ist die Lösung nicht, denn das Problem konnte ich reproduzieren.

Dem Support hatte ich alle geforderten Logs, Videos und auch TCP Dumps geliefert.

Mehr als ein digitales Schulterzucken via Mail kam nicht bei uns an

Ich denke, dass du durch das Neuaufsetzen, wahrscheinlich eher ein anderes Problem beseitigt hast.

Für mich ist auch zunächst primär, dass es läuft.

Gruß
Marc

Danke für die Erläuterungen. Der Weg von Marc klingt (auch wenn "nicht gewollt") an sich doch schlüssig.

Viele Grüße, commodity

Moin zusammen,

normalerweise bin ich stiller Leser, habe mir jetzt allerdings extra einen Account erstellt, um hier dieses Thema nochmal wieder hochzuholen. Vielleicht hilfts ja dem ein oder anderen mit den gleichen Symptomen.

Ich hatte bis vor 5 Minuten exakt dasselbe Problem mit meiner Sophos Home Appliance und war schon kurz davor, das Ding aus dem Fenster zu werfen. Wir haben vor einigen Monaten von EON Highspeed auf 1und1 gewechselt, dort musste ich dann PPPOE in der Sophos einrichten, was vorher nicht benötigt wurde. Ich habe es exakt so eingerichtet wie radiogugu es zu Anfang hatte, mit einem extra VLAN für die WAN-Verbindung. Dann gingen die Probleme los.

Da das meiste an für uns notwendigen Internetseiten funktionierte habe ich über Wochen immer wenn mal Zeit war rumprobiert, Firewall-Regeln geändert, MTUs ausprobiert, bei 1und1 bzgl. Dualstack nachgefragt und und und. Durch Zufall (oder besseres Googlen) bin ich jetzt auf diesen Thread gestoßen, und was soll ich sagen: Das war es.

Ich habe im Gegensatz zu radiogugu die Firewall nicht auf Werkseinstellungen zurückgesetzt, sondern nur das VLAN gelöscht und das WAN über die physikalische Schnittstelle neu eingerichtet. Ab diesem Moment funktioniert nun wieder alles. Für die Sophos scheint es also doch ein Unterschied zu sein, ob man ein zusätzliches VLAN anlegt, oder die VLAN-Einstellung in der physikalischen Schnittstelle verwendet.

Zitat von @NoCheatz:
Für die Sophos scheint es also doch ein Unterschied zu sein, ob man ein zusätzliches VLAN anlegt, oder die VLAN-Einstellung in der physikalischen Schnittstelle verwendet.

Hi.

So scheint es. Auch wenn die Konfiguration am Ende dasselbe sein sollte.

Gut, dass der Thread jemandem helfen konnte.

Gruß
Marc

Die Konfiguration an sich schon, aber mit VLAN ist ein weiterer virtualisierter Software Layer interne aktiv und was der wieder mit dem Paket Forwarding macht (oder auch nicht) weiss wohl nur Sophos.
Es ist aber eigentlich immer Usus für einen verantwortungsvollen Netzwerkadmin WAN Ports niemals auf ein virtuelles VLAN zu setzen sondern immer auf ein dediziertes Interface. Und das nicht allein nur aus Security Gründen.

Moin @aqui,

Es ist aber eigentlich immer Usus für einen verantwortungsvollen Netzwerkadmin WAN Ports niemals auf ein virtuelles VLAN zu setzen sondern immer auf ein dediziertes Interface. Und das nicht allein nur aus Security Gründen.

da hast du fürchte ich etwas falsch verstanden.
Denn die VLAN Konfiguration am WAN Anschluss des TO's, ist mit VLAN-ID 7, so von der Telekom vorgeschrieben und hat absolut nichts mit einer internen Netzsegmentierung oder ähnlichem zu tun.

Gruss Alex

Das ist zweifelsohne richtig aber dennoch muss man nur für einen VLAN Tag im Paket bei Routern oder Firewalls an dedizierten Routing Interfaces, die kein Memberport eines VLANs sind, üblicherweise kein extra VLAN anlegen sondern lediglich einen VLAN Tag mitgeben.
Noch besser ist es natürlich wenn man auch darauf verzichtet und dem embeddeten oder externen Modem diese Aufgabe zuteilt.