Keine Webabwendungen hinter KD-Router (IPv6?)

[cyberkeiler]

Haben einen WDR4300 seit Ende März hinter einem Kabel Deutschland Router im Einsatz. Das parallele private Netz ist ohne Probleme zu verwenden, über das Freifunk Netz war noch nie ein Aufruf einer Website möglich, Maliservices ebenfalls nicht erreichbar. - SSH und Ping funktionieren allerdings.

Zweiter Test´knoten mit WDR3600 zeigt gleiches Ergebnis.

Hitron Technologies CVE-30360
IPv6 only (IPv4 zumindest nicht in Routerconfig angezeigt)

[cyberkeiler]

Achja: /etc/config/fastd haben wir schon gemäß #46 angepasst. - Keinen Erfolg.

Beim Googeln stoße ich immer über gleiche Probleme, mit Hinweis auf MTU - mangels Fachkompetenz dürft Ihr entscheiden ob dies als Ursache in Frage kommt.
https://regensburg.freifunk.net/temporaerer-fix-fuer-kabeldeutschlandunitymedia-mtu-probleme/

http://lists.berlin.freifunk.net/pipermail/berlin/2015-January/026897.html

https://www.kunden-kabeldeutschland.de/questions/wie-kann-ich-verhindern-dass-udp-pakete-mit-einer-mtu-1370-rausgefiltert-werden?page=1#anchor_answer_232539

[cyberkeiler]

Achja: /etc/config/fastd haben wir schon gemäß #46 angepasst. - Keinen Erfolg.

Beim Googeln stoße ich immer über gleiche Probleme, mit Hinweis auf MTU - mangels Fachkompetenz dürft Ihr entscheiden ob dies als Ursache in Frage kommt.
https://regensburg.freifunk.net/temporaerer-fix-fuer-kabeldeutschlandunitymedia-mtu-probleme/

http://lists.berlin.freifunk.net/pipermail/berlin/2015-January/026897.html

https://www.kunden-kabeldeutschland.de/questions/wie-kann-ich-verhindern-dass-udp-pakete-mit-einer-mtu-1370-rausgefiltert-werden?page=1#anchor_answer_232539

[cyberkeiler]

Freifunk funktioniert wenn man den KD Router im Bridge Mode betreibt.
Ein manuelles setzen der MTU auf einen niedrigeren Wert als den Standardwert brachte sowohl im Bridge als auch in normalen Mode keine Besserung:

Sind die ffmd Gateway überhaupt kompatibel für diesen Lösungsansatz mit geringerer MTU (sh. Artikel Freifunk Regensburg oben?)

[cyberkeiler]

Freifunk funktioniert wenn man den KD Router im Bridge Mode betreibt.
Ein manuelles setzen der MTU auf einen niedrigeren Wert als den Standardwert brachte sowohl im Bridge als auch in normalen Mode keine Besserung:

Sind die ffmd Gateway überhaupt kompatibel für diesen Lösungsansatz mit geringerer MTU (sh. Artikel Freifunk Regensburg oben?)

[LeSpocky]

Das Problem scheint an Kabel Deutschland Anschlüssen mit DS Lite Konfiguration zu bestehen, wo man eine öffentliche IPv6-Adresse und eine private IPv4-Adresse bekommt, öffentlicher IPv4-Verkehr dann aber von KD über v6 getunnelt wird. Ich habe mich da mal bisschen durch die Links geklickt. Neben Anpassung der MTU oder Modem im Bridge-Modus könnte es auch helfen im Config-Modus IPv4 auf dem WAN-Port zu deaktivieren. Könnt Ihr das mal probieren?

[LeSpocky]

Das Problem scheint an Kabel Deutschland Anschlüssen mit DS Lite Konfiguration zu bestehen, wo man eine öffentliche IPv6-Adresse und eine private IPv4-Adresse bekommt, öffentlicher IPv4-Verkehr dann aber von KD über v6 getunnelt wird. Ich habe mich da mal bisschen durch die Links geklickt. Neben Anpassung der MTU oder Modem im Bridge-Modus könnte es auch helfen im Config-Modus IPv4 auf dem WAN-Port zu deaktivieren. Könnt Ihr das mal probieren?

[eriu]

möglicherweise mit gluon 2015.1.2 gelöst
https://gluon.readthedocs.org/en/v2015.1.2/releases/v2015.1.2.html

[eriu]

möglicherweise mit gluon 2015.1.2 gelöst
https://gluon.readthedocs.org/en/v2015.1.2/releases/v2015.1.2.html

[LeSpocky]

Könnte mit freifunk-gluon/gluon#397 zu tun haben, was wie gesagt in gluon 2015.1.2 gelöst wurde. Dazu bitte mal die aktuelle experimental aufspielen und testen!

[LeSpocky]

Könnte mit freifunk-gluon/gluon#397 zu tun haben, was wie gesagt in gluon 2015.1.2 gelöst wurde. Dazu bitte mal die aktuelle experimental aufspielen und testen!

[RubenKelevra]

Setzt die MTU einfach auf 1312 runter sowohl auf den Servern als auch auf den Nodes.

Das Problem ist, dass die Kabelmodems IPv4 wie bei IPv6 behandeln und keine Hop-Fragmentierung machen, sondern sich auf Host-Fragmentierung verlassen. Darüber hinaus schicken sie aber keine Kontrollnachricht via ICMP die für die Signalisierung der zu groß gewählten MTU bei IPv4 aber zwingend erforderlich ist.

Diese beiden Bugs zusammen sorgen für ein Blackhole das einfach die Pakete verwirft wenn diese zu groß in den Tunnel geschickt werden.

Bitte beachtet außerdem, dass Batman-adv bis (aber nicht einschließend) 2015.1 einen Bug hat, der unterschiedliche MTUs beim Forward teilweise für Probleme sorgt.

Lg aus Leverkusen

[RubenKelevra]

Setzt die MTU einfach auf 1312 runter sowohl auf den Servern als auch auf den Nodes.

Das Problem ist, dass die Kabelmodems IPv4 wie bei IPv6 behandeln und keine Hop-Fragmentierung machen, sondern sich auf Host-Fragmentierung verlassen. Darüber hinaus schicken sie aber keine Kontrollnachricht via ICMP die für die Signalisierung der zu groß gewählten MTU bei IPv4 aber zwingend erforderlich ist.

Diese beiden Bugs zusammen sorgen für ein Blackhole das einfach die Pakete verwirft wenn diese zu groß in den Tunnel geschickt werden.

Bitte beachtet außerdem, dass Batman-adv bis (aber nicht einschließend) 2015.1 einen Bug hat, der unterschiedliche MTUs beim Forward teilweise für Probleme sorgt.

Lg aus Leverkusen

[christf]

Das ist eine Anpassung, die in Folge auf gateways und nodes stattfinden muss. Die Schrittfolge wäre:

• Erweiterung der gateway-Konfiguration, Einführung einer zusätzlichen fastd-Instanz mit MTU 1312, deren Interface in Batman eingehängt ist
• Wechsel der MTU in der Firmware auf 1312
• Rollout der Firmware ins gesamte Netz
• Deaktivierung der alten fastd-Instanzen

[christf]

Das ist eine Anpassung, die in Folge auf gateways und nodes stattfinden muss. Die Schrittfolge wäre:

• Erweiterung der gateway-Konfiguration, Einführung einer zusätzlichen fastd-Instanz mit MTU 1312, deren Interface in Batman eingehängt ist
• Wechsel der MTU in der Firmware auf 1312
• Rollout der Firmware ins gesamte Netz
• Deaktivierung der alten fastd-Instanzen

[penguineer]

Weitere Bearbeitung de Tickets in #121

[penguineer]

Weitere Bearbeitung de Tickets in #121