[gelöst] VDSL und PPPoE: MTU-Size, MSS-Clamping mit iptables fehlerhaft

[lspci]

Hallo liebe Leute,

ich habe ein seltsames Problem mit meinem Rechnerzoo zu Hause .

Internet <-> Router <-> Switch ----------- PC1, PC2 epp

Als Router verwende ich einen Rechner mit Debian Jessie (iptables, ppp, dnsmasq)
Egal ob ich meine iptables Regeln verwende oder ob ich nur die einfachste Variante mache

Code: Alles auswählen

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
echo "1" > /proc/sys/net/ipv4/ip_forward

es funktioniert alles perfekt, aber so nach 10-12h aufgebauter ppp Verbindung können manche Webseiten nicht mehr von PC1, PC2 usw. erreicht werden.
Vom Router selbst kann ich die Webseiten aber weiterhin erreichen wget .. nur von den Rechner die hinter dem Switch hängen nicht mehr.
Trenne ich die ppp Verbindung mit poff und baue sie wieder neu mit pon auf, geht alles wieder perfekt für x Stunden.

- DNS ist nicht das Problem
- MTU auch nicht meine ich ppp0 1492, eth0 Device 1500 für ppp Verbindung
- iptables Regeln auch nicht, da selbes Problem bei obiger Basisvariante

Es ist halt seltsam das es nur bestimmte Webseiten betrifft und nicht alle. Nach der 24h automatischen Trennung durch DTAG Problem auch weg, klar im Prinzip das gleiche wie poff/pon.

Ich Moment schaue ich mir die Sache etwas mit tcpdump an vielleicht finde ich was. Aber irgendwie scheine ich Tomaten auf den Augen zu haben ... hilfe

[BenutzerGa4gooPh]

Hallo und willkommen im Debian-Forum!

Vom Router selbst kann ich die Webseiten aber weiterhin erreichen wget ..

Da der Router dazu PPPoE nutzen muss, wird es entweder nicht den Protokollen zwischen Router und Provider liegen oder der Router baut die Verbindung neu auf. Aufgrund der wenigen Angaben kann ich nicht mehr helfen.
wireshark könnte dein Freund werden ...

Es ist halt seltsam das es nur bestimmte Webseiten betrifft und nicht alle.

Spricht ebenfalls nicht für deine Vermutung.

Ich würde mal einen Host direkt an den Router anschließen und diesen mit einer Live-Iso booten. Vielleicht vorher den Host anstelle des Routers?! Welche Fehler man damit ausschließt/eingeengt, kannst du selbst überlegen.

Hinweis: Der Netzwerkmanager kann PPP einfach, fix und grafisch: https://wiki.ubuntuusers.de/NetworkManager/

Per Modem und dessen Manual hast du VDSL-Fehler natürlich ausgeschlossen ...
Mal testweise auf dem Modem VDSL und PPPoX terminiert?

Edit: Ich weiss nicht, ob VDSL-Anschluesse per PPPoA (VPI/VCI) und gar nicht per PPoE terminiert werden .... müsstest du wissen.

[lspci]

Hallo und Danke für die Antwort

Der Rechner (Router) hängt einem Vigor 130 pppoe passthrough (modem Betrieb) eingeschaltet. Eine gui hat der Router nicht, weder web noch gtk noch x, alles über ssh. Im Log vom Vigor selbst sehe ich keine Probleme bezüglich Sync. Ja das Problem hängt irgendwo zwischen Router <-> Switch <-> X Pcs und nicht beim ISP. Ich hatte gedacht vielleicht gibt es ein Problem mit dem Connection tracking

Code: Alles auswählen

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max

43/65536 eher nicht *g*

Wenn ich nachher nach Hause komme werde ich wie vorgeschlagen mal ein Gerät direkt an den Router hängen ohne Switch, muss nur warten bis der Fehler wieder besteht . Welchen Fehler ich damit ausschließe?

- Probleme mit dem Switch
- fehlerhafte Konfiguration der Rechner hinter dem Switch
- doch was am Router
?

- subnet 192.168.1.0/24
- router ip 192.168.1.1
- adressen für das subnet static und ein kleiner Bereich für dhcp

ip route vom einem der Rechner hinter dem Switch

Code: Alles auswählen

default via 192.168.1.1 dev eno1 onlink 
192.168.1.0/24 dev eno1 proto kernel scope link src 192.168.1.3

cat /etc/resolv.conf

Code: Alles auswählen

nameserver 192.168.1.1

ping auf heise.de wegen mtu, max. 1464 mehr geht nicht sonst 100% packet loss

Code: Alles auswählen

ping -M do -s 1464 heise.de

+ 28 = 1492 für den router

Naja mal schauen das ich den Fehler am Wochenende finde

Danke nochmal

[BenutzerGa4gooPh]

VDSL wird wohl doch so gekapselt: PPPoE->ATM->VDSL.

1492 für den router

PPPoE: MTU-Size = 1492 und TCP MSS = 1452!
https://www.cisco.com/c/en/us/support/d ... r-mtu.html

Könnte für xDSL ungünstig sein, ICMP komplett (alle Pakettypen) zu droppen, vorgesehene "Automatik" funktioniert nicht mehr:

Um in IPv4-Netzen die maximale Größe zu bestimmen, die ein Datenpaket haben sollte, muss die Stelle des Pfades gefunden werden, die die kleinsten Datenpakete zulässt. Dazu wird ein IPv4-Paket versendet, bei dem das DF-Bit (Don’t Fragment) gesetzt ist und das die Größe der lokal eingestellten Maximum Transmission Unit hat. Kommt das Paket an eine Stelle im Netz, an dem nur eine kleinere MTU verarbeitet werden kann, wird ein ICMP-Error Typ 3 Code 4 (Destination Unreachable Fragmentation Needed, DF Set) zurückgeschickt, der auch die eigene MTU enthält. Der lokale Rechner erhält dieses ICMP-Paket und kann die Größe seiner Nachrichten nun an die zurückgeschickte MTU anpassen. Dies wird so lange wiederholt, bis die Paketgröße gering genug gewählt wurde, damit das Paket den gesamten Pfad ohne Fragmentierung durchlaufen kann.

https://de.m.wikipedia.org/wiki/Path_MTU_Discovery
ICMP-Pakettypen: https://de.m.wikipedia.org/wiki/Interne ... e_Protocol

Wenn ich nachher nach Hause komme werde ich wie vorgeschlagen mal ein Gerät direkt an den Router hängen ohne Switch

Auch mal anstelle Router einen PC/Laptop mit Linux-Live-Iso testweise anschließen.

Netzwerk-Test-Tool im Fehlerfall: https://www.linux-tips-and-tricks.de/de/schnellstart
Kannst du bei Bedarf nach pastebin/ posten. Eventuell letzte Stellen öffentlicher IPs "xxx-eln". MAC-Adressen kann man lassen.

Viel Spaß bei den Hausaufgaben!

[lspci]

Ich glaub für Hausaufgaben bin ich zu alt, eher Bildung der Freude wegen . Hmm jetzt heißt es auf den Fehler warten, derweil schreibe ich dann mal mein iptables Script neu. Hatte das die letzten 5 Jahre im Dauerbetrieb . Und sobald der Fehler gefunden wurde setzte ich auch gleich mal den Router auf Stretch. Wegen der MTU ich dachte immer kleinstes Paket von einem Rechner aus dem Subnet, was nicht fragmentiert also z.B. von PC 192.168.1.13, ist bei mir 1464, 1465 ist zuviel

Code: Alles auswählen

ping -M do -s 1464 heise.de

Und für die WAN Schnittstelle am Router die obige Zahl + 28?

Kein Problem ich lerne gerne was neues , immer her mit dem INPUT

uahh Asterisk wollte ich auch noch neu aufsetzen, das wird ein langes Wochenende

[BenutzerGa4gooPh]

Wegen der MTU ich dachte immer kleinstes Paket von einem Rechner aus dem Subnet, was nicht fragmentiert also z.B. von PC 192.168.1.13, ist bei mir 1464, 1465 ist zuviel

Erklärung und Unterschiede MTU vs. MSS (mit Overhead/Kapselung):

I now am confident in 1492 as the MTU and 1452 for the TCP MSS, and I understand why they work.

https://samuel.kadolph.com/2015/02/mtu- ... g-pppoe-2/

[lspci]

Wegen der MTU ich dachte immer kleinstes Paket von einem Rechner aus dem Subnet, was nicht fragmentiert also z.B. von PC 192.168.1.13, ist bei mir 1464, 1465 ist zuviel

Erklärung und Unterschiede MTU vs. MSS (mit Overhead/Kapselung):

I now am confident in 1492 as the MTU and 1452 for the TCP MSS, and I understand why they work.

https://samuel.kadolph.com/2015/02/mtu- ... g-pppoe-2/

Vielen Dank gleich mal lesen, schade das ich meinen alten Account hier vom Forum nicht mehr finde. Aber ich habe wahrscheinlich nicht mal mehr die E-Mail Adresse von vor 7-10 Jahren keine Ahnung und wurde eh gelöscht wegen inaktivität. Noch eine andere Frage da ich nicht auf dem laufenden bin, gibt es eigentlich für Wireshark schon eine direkte Möglichkeit diesen zu installieren/nutzen ohne X libs auf dem Rechner zu haben z.B. so ne Art Wireshark-Agent?. Oder ist das immer noch so wie vor Jahren mit tcpdump capture im entsprechenden Format und dann weiterleiten und auswerten? Bzw. werde ich gleich mal selbst suchen, bin ja nicht faul oder nicht so faul

[BenutzerGa4gooPh]

Ich habe noch mal geschaut, wie andere Routerhersteller mit der MTU-MSS-Size bei DSL/PPPoE umgehen. Heutzutage wird ja eingehendes ICMP meist von der Firewall gedropt.
AVM nutzt MSS-Clamping mit MTU-Size = 1492.
https://avm.de/service/fritzbox/fritzbo ... -anpassen/
Funktioniert auch mit Linux/iptables:

The bad thing is that it's an obvious hack - it breaks 'end to end' by modifying packets. Having said that, we use this trick in many places and it works like a charm.

http://lartc.org/howto/lartc.cookbook.mtu-mss.html

Oder man setzt MSS=1452 per Default-Route:
http://www.itsyourip.com/redhat/set-max ... rks-hosts/

Wenn man einen schnellen DSL-Anschluss hast, genügt wohl auch die Methode, die MTU-Size auf 1464 zu verringern.
https://samuel.kadolph.com/2015/02/mtu- ... g-pppoe-2/

[lspci]

Hallo,

ich hab die Ursache für das Problem gefunden .

sitzt vor dem Monitor

es war doch die mtu, ich hatte in meinen iptables script eine FORWARD Regel auskommentiert und da suche ich drei Tage ...

Code: Alles auswählen

$IPTABLES -A FORWARD --source $subnet_LAN -i $interface_LAN -o $interface_PPP -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

hat sich aber trotzdem gelohnt durch das Lesen hab ich wieder was gelernt, der Router läuft jetzt auf Stretch und nen Account im debianforum.de hab ich auch wieder .
Danke also nochmal für die Hinweise und Links, jetzt werke ich mal weiter an meinem Asterisk. Wollte von chan auf pjsip umstellen.

[BenutzerGa4gooPh]

ich hab die Ursache für das Problem gefunden .

Mit der geposteten Regel nutzt du wieder MSS-Clamping.
Probiere dazu mal eine MTU-Size von 1492 für PPPoE. Dadurch müsste der Anschluss etwas schneller werden als mit einer kleineren, die du wohl bisher nutzt. Wenn es denn funktioniert.

Setzen MTU für PPPoE:
https://www.debian.org/doc/manuals/debi ... etting_mtu
(5.8.2 letzter Absatz)

Edit: Nochmal Thread gelesen, MTU-Size=1492 nutzt du wohl schon?!

Edit2: Vielleicht änderst du nochmal den Titel des Threads wegen besserer Auffindbarkeit für andere? Thread ist schön kurz und alles "beieinand", Tuts und Theorie verlinkt. Vorschlag: [gelöst] VDSL und PPPoE: MTU-Size, MSS-Clamping mit iptables fehlerhaft

[lspci]

ich hab die Ursache für das Problem gefunden .

Mit der geposteten Regel nutzt du wieder MSS-Clamping.
Probiere dazu mal eine MTU-Size von 1492 für PPPoE. Dadurch müsste der Anschluss etwas schneller werden als mit einer kleineren, die du wohl bisher nutzt. Wenn es denn funktioniert.

Setzen MTU für PPPoE:
https://www.debian.org/doc/manuals/debi ... etting_mtu
(5.8.2 letzter Absatz)

Edit: Nochmal Thread gelesen, MTU-Size=1492 nutzt du wohl schon?!

Edit2: Vielleicht änderst du nochmal den Titel des Threads wegen besserer Auffindbarkeit für andere? Thread ist schön kurz und alles "beieinand", Tuts und Theorie verlinkt. Vorschlag: [gelöst] VDSL und PPPoE: MTU-Size, MSS-Clamping mit iptables fehlerhaft

Ja mtu am wan interface ist und war 1492, genau die MSS-C hatte ich Jahre lang so im Betrieb und vor ein paar Tagen irgendwie auskommentiert und jetzt wieder aktiv. RFC 1191 ist ja nicht wirklich eine Lösung hab ich gelesen, aber mal schauen. Hab mich jetzt erstmal etwas im asterisk wiki verrannt ..