Aufschaukelnder Traffic von WAN zu sich selbst

[SarpeTronic]

Ich habe ein Problem, ich habe die aktuelle OPNsense Version installiert, seit 2 Versionen schaukelt sich der Traffic von WAN0 zu WAN0 auf, ich hatte so ein Problem schon mal vor einem ca. 1,5 Jahren, da hatte sich eine DNS Abfrage irgendwie kurzgeschlossen und nach 2-3 Tagen die volle Bandbreite belegt.
Jetzt ist direkt nach dem Neustart des Routers 100-150Mb Traffic auf WAN0 in und out, aber 0 auf den anderen Schnittstellen.

[meyergru]

Dann wirst Du einen tcpdump auf dem WAN-Interface machen müssen und schauen, was das verursacht. Falls es DNS-Abfragen sind, wäre es interessant, zu sehen, was die abfragen und warum es schiefgeht bzw. wie solche Loops entstehen.

Beispielsweise:

"tcpdump -i pppoe0 -X -vvvv port 53", wenn Du normalen DNS nutzt.

Der eingesetzte DNS-Server und dessen Einstellungen sind ggf. auch relevant. Loops dieser Art sind eigentlich ungewöhnlich und entstehen bei korrekter Konfiguration eigentlich nicht. Was mal passieren kann, sind Mail-Loops.

[SarpeTronic]

Es war diesmal nicht der DNS-Server, ich verweise auf meine internen DNS-Server und hoste dort die Kopie der B-Root Zone.
Ich habe jetzt mal an vielen Stellen "rumgespielt", um zu sehen, was eine Auswirkung auf dieses Aufschaukeln hat.
Nachdem ich den errechneten MTU (war leer) von 1492 eigegeben habe, ist die Last verschwunden.

[meyergru]

Oder so: https://forum.opnsense.org/index.php?topic=45658.0

[SarpeTronic]

Das bei zu großem MTU fragmentiert werden muss ist mir klar, aber warum führt das dazu, dass die WAN-Schnittstelle sich selbst 200Mb sendet und empfängt?

[meyergru]

Weil es zu Retries kommt, wenn das Paket wegen zu großer Länge gedroppt wird, wenn die path MTU discovery nicht funktioniert, das ist ja gerade der Punkt, weshalb ich die MTU vorzugsweise auf 1500 Bytes anhebe. Das ist alle im verlinkten Artikel erklärt.

Oder was meinst Du mit "sich selbst sendet"? Hast Du einen Paket-Mitschnitt?

[SarpeTronic]

Eine Weile war Ruhe, jetzt ist es wieder da. 01WAN (ppoe-Telekom) in und out jeweils (im Moment) 80 MB/s, kann auch bis auf 400 MB/s hochgehen.
der erste Rechner ist eine alte IPv6 meines Office Arbeitsplatz aus meinem lokalen Netz X:X:X:fa00 an der Netzwerkkarte 1, der Zweite ist ein DC in einem zweiten Netz X.X.X:fa40::1, an einer Netzwerkkarte 2, bei im selben IPv6 56er Subnetz.
Das Netz X.X.X:fa40 ist über Port 3389 erreichbar, aber selbst wenn ich alle Ports in das Netz öffne, bleibt die Last bestehen.
Wenn ich die Schnittstelle 01WAN (ppoe) kurz deaktiviere, ist die Schleife erst einmal weg, das kann auch ein paar Tage ohne weitere Last-Probleme laufen.

Ein Paketmitschnitt liefert folgenden immer wiederkehrenden Wert:

01WAN
pppoe0   2025-09-02
13:44:00.672215         length 225: (flowlabel 0x5dd4c, hlim 47, next-header UDP (17) payload length: 181) X:X:X:fa00:f679:1639:1cdd:d1e7.50485 > X.X.X:fa40::1.389: [udp sum ok] UDP, length 173

[meyergru]

Ist es nun Port 3389 oder 389? Wahrscheinlich ist es Port 3389, also Microsoft RDP.

Aber egal, was den Verkehr auslöst: Der Traffic sollte wohl inter-VLAN Traffic sein, der von einem lokalen Netzwerkinterface mit der IPv6 X:X:X:fa00::Y zu einem anderen Interface mit der IPv6 X:X:X:fa00::Z geroutet wird, um dann vom PC zum DC zu kommen.

Das setzt natürlich voraus, dass die beiden Interfaces für die VLANs auch wirklich die richtigen 8-Bit-Präfixe verwenden, also per "Track Interface" genau den entsprechenden /64er Präfixe. Insbesondere darf kein Interface den selben Präfix verwenden wie ein anderes.

Das eine Interface hat offenbar den Präfix 00, das andere 40, zusammen mit dem WAN-Präfix X:X:X:fa00::/56 bildet das dann die Subnetzmaske für die jeweiligen (V)LANs. Ich würde mal prüfen, ob das WAN-Interface eventuell auch den Präfix 00 verwendet. Das dürfte zwar eigentlich nicht möglich sein, aber weil die Lösung für die Verwendung des IA_PD-Präfixes auf dem WAN-Interface noch recht frisch und eigentlich ein Hack ist, würde ich nicht ausschließen, dass man das falsch machen kann.

Wenn Dein Traffic auf dem WAN Interface pppoe0 sichtbar wird oder dieses durchläuft (bei mir wird er das nicht!), dann müssen entweder Routen verbogen sein oder die Präfixe sind nicht richtig vergeben oder Du benutzt unsinnigerweise DHCPv6 und hast dort Gateways oder Routen falsch konfiguriert.

Wie das alles korrekt geht, steht hier.

[SarpeTronic]

Der Port ist 389, also LDAP. Die IPv6 Präfixe sind sauber getrennt, siehe vor Post.
Ich habe mich gefragt, warum ich das nur ab und zu aufschaukelt. Heute habe ich dazu eine Idee bekommen. Der Client hat seine IPv6 erneuert, die  X:X:X:fa00:f679:1639:1cdd:d1e7 ist also gar nicht mehr erreichbar. Warum verwirft der die Pakete nicht mit einem Timeout, sondern dupliziert diese?

[meyergru]

Dein vorangehender Post behandelt nur zwei Interfaces, nicht alle - insbesondere nicht das, was ich explizit genannt habe und das man leicht übersieht: WAN. Das kann nämlich auch einen Präfix annehmen und wenn man ihn nicht explizit <> 0 setzt, würde er sich mit einem Deiner Interfaces überschneiden.

Du sagst auch nichts dazu, wie Du die IPv6 lokal vergibst - per DHVPv6 oder SLAAC?

Und zur Erklärung des Verhaltens beim Erneuern von IPv6: Ein Client kann jeweils mehrere IPv6 verwenden, auch mit dem selben Präfix. Das passiert beispielsweise, wenn man IPv6 Privacy Extensions verwendet. Dabei wird typischerweise eine verworfene IPv6 noch eine Zeitlang aufrecht erhalten, damit verspätet eingehende Verbindungen noch funktionieren. Das müsstest Du auf den Clients mit ipconfig sehen können.

Wenn allerdings sogar der Präfix wechselt (manche ISPs machen das), dann werden Pakete an den alten Präfix eben ins Internet geschickt, weil die OpnSense dann den Präfix nicht mehr selbst inne hat. Folglich muss sie solche Pakete ins Internet schicken, deshalb siehst Du sie auf dem WAN.

Mein Verdacht hier ist, dass:

a. Dein ISP regelmäßig den Präfix ändert. Blöd, weil dann IPv6 noch schlechter als normalerweise im internen Netz nutzbar ist.

b. Du IPv6 per DHCPv6 vergibst und dabei sogar den verwendeten Hostnamen in Deinen DNS eintragen lässt. Unter dieser Bedingung würden Namensauflösungen im LAN auf die IPv6 laufen - nicht auf IPv4. Dann passieren solche Dinge eben. In meinem Artikel empfehle ich deswegen SLAAC und IPv6 auch nur für externe, ausgehende Verbindungen zu verwenden. Wenn überhaupt, nutzt man die aus der MAC abgeleitete EUI-64 zur Freigabe von Services ins Internet, besser ist aber die Verwendung von IPv4 intern und IPv4/IPv6 extern mittels eines Reverse Proxies, weil dann die OpnSense den Traffic terminieren kann und auch den DynDNS bei wechselnden Präfixen.

Kurz gesagt: Sorge dafür, dass sich die Geräte nicht mehr untereinander per IPv6 unterhalten. Vermutlich stehen sie aber mit IPv6 im DNS (oder was immer Windows für einen Namensdienst verwendet, die haben ja etwas eigenes). Wie auch immer, offenbar finden sie sich per IPv6, was immer vor IPv4 priorisiert wird, wenn die Möglichkeit besteht.