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.
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.
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.
Oder so: https://forum.opnsense.org/index.php?topic=45658.0
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?
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?
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
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 (https://forum.opnsense.org/index.php?topic=45822.0).
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?
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 DHCPv6 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.
Die IPv6 vergebe ich bei den Servern manuell inklusive Set-NetIPInterface -Dhcp Disabled, bei den Clients per DHCPv6, ich habe jetzt als Workaround den Geräten, welches auf das andere Netz zugreifen dürfen eine feste IPv6 per DHCPv6 zugeordnet. nicht die Ursache
router advertisement steht auf managed und Do not send any DNS configuration to clients.
Beide internen Netzwerkkarten stehen bei IPv6 auf Track Interface und ziehen auch zuverlässig ihre Subnetze, welche sich nie ändern, da ich feste IPv4 und IPv6 Adressen gebucht habe und nein, ppoe bekommt keinen präfix aus dem /56er Netz, nur eine fe80::
Die Routen sind dem Router auch bekannt:
ipv6 A:A:A:fa00::/64 link#1 U 1500 igc0 01LANST
ipv6 A:A:A:fa40::/64 link#2 U 1500 igc1 02LANMM
Und ja, natürlich trage ich die IPv6 Adressen dynamisch in den DNS ein, darum ja managed. Ich verwende IPv6 bei meinen Kunden und mir seit über 10 Jahren ohne Probleme.
Gerade bei der Vielzahl an Netzen, welche ich betreue ist IPv6 die schnellere, modernere und unkompliziertere Variante und ich möchte dort auch nicht missioniert werden.
Die Anfrage X:X:X:fa00:x:x:x:x.50485 > X.X.X:fa40::1.389 sollte eigentlich gar nicht and 01WAN (ppoe) aufgelöst werden, da beide Subnetzte fa00 und fa40 sich auf internen Netzwerkkarten befinden.
Es sieht irgendwie so aus, als wenn der Router versucht, die Adresse extern aufzulösen, nachdem das Gerät (intern) nicht mehr zu erreichen ist.
Das war auch bei dem ersten Aufschaukeln merkwürdig, da war es ein DNS Paket auf Port 53, dabei dürfen ausschließlich die internen DNS Server über Port 53 nach extern. Ein (aktueller) Dump zeigt auch auf dem ersten Blick keine anderen DNS-Zugriffe.
Es fängt grade schon wieder an:
10:33:33.613843 IP6 (flowlabel 0xeb2dd, hlim 35, next-header UDP (17) payload length: 181) A:A:A:fa00:X:X:X:X.53413 > A:A:A:fa40::1.ldap: [udp sum ok] UDP, length 173
Wobei der sendende Rechner diesmal unter der IPv6 erreichbar ist.
O.K., keine Missionierung mehr - Du bist ja erfahren und kennst Dich bestens mit IPv6 aus.
Klar ist mir aber eins: Wenn die Routen aufgrund der korrekten Interface-Präfixe korrekt sind, dann werden auch alle darin enthaltenen IPv6 dorthin geroutet. Wenn die also auch dem WAN auftauchen, dann höchstwahrscheinlich, weil die Default-Route greift. Deshalb wäre ein Vergleich der Routen vorher und im Fehlerfall mit "netstat -rn -f inet6" auf der OpnSense für Dich hilfreich. Du hast bislang auch nicht beantwortet, ob der Präfix oder nur die EUI-64 wechselt, weil ersteres bei Nutzung von DHCPv6 den Effekt komplett erklärt, wie ich bereits erläuterte (denn dann verwenden die Geräte den alten Präfix weiter - im Gegensatz zu SLAAC, wo der neue Präfix sofort gepusht wird). Zur Klarstellung: Nur eine Feststellung, keine Missionierung - ich erläutere nur, warum DHCPv6 bei wechselnden Präfixen nicht funktioniert.
Falls sich OpnSense dann wider Erwarten doch falsch verhält, wie Du annimmst, schlage ich einen Bug-Report auf Github vor.
Viel Erfolg beim Lösen Deines Problems!
Danke für Deine Gnädigkeit ❤️, ich bin Dir dankbar für Deine Hilfe, aber eigentlich meine ich ja schon zu wissen was ich tue, ich denke dass verstehst Du.
Quoteob der Präfix oder nur die EUI-64 wechselt
QuoteBeide internen Netzwerkkarten stehen bei IPv6 auf Track Interface und ziehen auch zuverlässig ihre Subnetze, welche sich nie ändern, da ich feste IPv4 und IPv6 Adressen gebucht habe und nein, ppoe bekommt keinen präfix aus dem /56er Netz, nur eine fe80::
Ich habe seit Jahren das selbe Netz IPv6 A:A:A:fa/56 und dieselbe IPv4 bei der Telekom, das ich das als feste IP gebucht habe, ändert sich da nie etwas.
Im Moment eskaliert das gerade auf 500MBit, wobei ich noch keine Einschränkungen zum Internet feststellen kann.
netstat -rn -f inet6
A:A:A ist natürlich identischer Präfix
Internet6:
Destination Gateway Flags Netif Expire
default fe80::200:ff:fe00:0%pppoe0 UGS pppoe0
::1 link#7 UHS lo0
A:A:A:fa00::/64 link#1 U igc0
A:A:A:fa00::/56 link#7 USB lo0 ist hier eventuell das Problem?
A:A:A:fa00:X:X:X:X link#7 UHS lo0
A:A:A:fa02::/64 link#11 U wg0
A:A:A:fa02::1 link#7 UHS lo0
A:A:A:fa02::3 link#11 UHS wg0
A:A:A:fa02::4 link#11 UHS wg0
A:A:A:fa02::5 link#11 UHS wg0
A:A:A:fa02::7 link#11 UHS wg0
A:A:A:fa02::8 link#11 UHS wg0
A:A:A:fa02::9 link#11 UHS wg0
A:A:A:fa02::11 link#11 UHS wg0
A:A:A:fa02::13 link#11 UHS wg0
A:A:A:fa02::15 link#11 UHS wg0
A:A:A:fa40::/64 link#2 U igc1
A:A:A:fa40:aab8:e0ff:fe02:eae7 link#7 UHS lo0
A:A:A:fa41::/64 link#12 U wg1
A:A:A:fa41::1 link#7 UHS lo0
A:A:A:fa41::25 link#12 UHS wg1
A:A:A:fa41::41 link#12 UHS wg1
A:A:A:fa41::46 link#12 UHS wg1
A:A:A:fa41::122 link#12 UHS wg1
A:A:A:fa41::127 link#12 UHS wg1
A:A:A:fa41::128 link#12 UHS wg1
A:A:A:fa41::254 link#12 UHS wg1
2003:a:27f:b1fa::/64 link#13 U pppoe0
2003:a:27f:b1fa:aab8:e0ff:fe02:eae6 link#7 UHS lo0
2606:4700:4700::1111 fe80::200:ff:fe00:0%pppoe0 UGHS pppoe0
fe80::%igc0/64 link#1 U igc0
fe80::aab8:e0ff:fe02:eae6%lo0 link#7 UHS lo0
fe80::%igc1/64 link#2 U igc1
fe80::aab8:e0ff:fe02:eae7%lo0 link#7 UHS lo0
fe80::%lo0/64 link#7 U lo0
fe80::1%lo0 link#7 UHS lo0
fe80::%pppoe0/64 link#13 U pppoe0
fe80::aab8:e0ff:fe02:eae6%lo0 link#7 UHS lo0
root@OPNsense:~ #
Ich habe mal den Präfix auf 64 gesetzt und dann zurück gesetzt, jetzt ist Ruhe, ich werde das heute Abend mal nach einem Neustart beobachten.
Bei festen IPs kommt ein Präfixwechsel natürlich nicht in Frage, das hättest Du aber auch schon früher schreiben können - Du weißt das vielleicht, ich nicht.
Den Neustart brauchst Du wahrscheinlich nicht, denn das Problem sind anscheinend - wie vermutet - überlappende Präfixe:
A:A:A:fa00::/64 link#1 U igc0 -> perfekt: das /64 liegt auf igc0, wie erwartet.
Aber: A:A:A:fa00::/56 link#7 USB lo0 -> ein deutlich größeres Präfix (/56) ist als Route auf lo0 (loopback) installiert.
Außerdem gibt es Host-Routen (A:A:A:fa00:X:X:X:X link#7 UHS lo0) — einzelne Adressen sind als lokal auf lo0 registriert.
Das ist inkonsistent: die Delegation/Prefixverwaltun g gehört auf die Interfaces (Track → WAN/igc0), nicht auf lo0. Wenn das System Teile Deines IPv6-Bereichs auf lo0 bindet, entstehen seltsame Effekte bei Routing/Source-Selection und Neighbor-Auflösung — und es kann dazu führen, dass Pakete nicht wie erwartet lokal per NDP/Link auf igc0 behandelt werden, sondern die Routenlage durcheinandergerät und Traffic über die Default-Route/pppoe0 landet oder gespiegelt wird.
Wenn das wieder auftritt, könntest Du testweise mal folgendes machen:
route delete -inet6 A:A:A:fa00::/56
Offenbar wird irgendwo bei der IPv6-Präfix-Vergabe eine Route für den /56er Präfix über lo0 erzeugt, die da nicht hingehört - bei mir ist sie übrigens überflüssigerweise auch vorhanden. Bei mir wirkt sich das aber nicht aus, weil ich keinen inter-VLAN IPv6 Traffic erzeuge und schon gar keinen mit wechselnden IPs.
Gratulation! Offenbar hast Du wirklich einen Bug gefunden - jetzt kannst Du einen Github-Bug (https://github.com/opnsense/core/issues) für @Franco einstellen. Bitte verwende dafür unbedingt das Template, sonst wird der Report ignoriert.
P.S.: Ich würde drauf tippen, dass das im Rahmen des PPPoE-Verbindungsaufbaus schiefgeht. FreeBSD scheint bei allen Interfaces zusätzliche Host-Routen auf lo0 zu setzen, vielleicht, um das eigentliche Interface nicht zu behelligen. Bei PPPoE geht das wohl schief.
Du könntest allerdings das Problem bei Dir eventuell auch kurzfristig fixen, indem Du eben nicht "0" als Prefix für Dein igc0 nimmst, sondern einen anderen Präfix. Damit ist die /64er Route auf igc0 "spezieller" als die /56er lo0-Route und wird (hoffentlich) immer genommen. Sicher bin ich dabei aber nicht.
Ich würde bei einem fest zugewiesenen e.g. /56 vom Provider immer alle internen Interfaces statisch konfigurieren.
dead:beef:dead:be<VLAN ID>::1/64 benutze ich. 8 Bit - 1-255 - reicht für meine VLANs. 🙂
Das Problem ist hier wahrscheinlich nicht "Track Interface" vs. "statische Konfiguration" auf den LAN-Interfaces, sondern, dass der Zugang beim Telekom-Business immer noch über PPPoE kommt. Und der /56er Präfix wird dort per DHCPv6 geholt, was offenbar nebenbei dazu führt, dass /56 auf lo0 kommt.
Du hast aber Recht: man könnte das WAN auch mit einer statischen IPv6 versehen und gucken, ob die fehlerhafte Route dann verschwindet. Und dann eben die lokalen Interfaces auch statisch.
Quote from: meyergru on Today at 04:07:36 PMUnd der /56er Präfix wird dort per DHCPv6 geholt, was offenbar nebenbei dazu führt, dass /56 auf lo0 kommt.
Ist bei mir aber auch so:
dead:beef:deaf:be00::/56 link#6 USB lo0
Und so eine Route ist ja sinnvoll. Das ist ja ein Summary, also jeder longer match überschreibt das. Und wenn man mit OSPF oder BGP irgendwas weiterverteilt, ist es gut, wenn das eigene Prefix stabil an irgendeinem nicht physischen Interface anliegt.
Ich kann noch nicht ganz folgen, wie das zu Problemen führen soll. Die Route ist wie schon geschrieben ja maximal *un*spezifisch.
Gruß
Patrick
Das Problem liegt nicht bei der reinen Routenauswahl, sondern in den Host-Routen und der lo0-Bindung:
Routen auf lo0
Jede Adresse, die OPNsense auf lo0 ,,als Alias" einträgt, bekommt so eine lo0-Route.
Das sagt: diese einzelne Adresse gehört zu mir selbst.
- Pakete an diese IP werden niemals weitergeleitet, sondern lokal verarbeitet.
- Wenn so ein Alias zufällig im Prefix-Bereich der Clients liegt, sehen Clients ein Gateway, das eigentlich gar kein echtes Ziel ist.
/56 auf lo0
Das ist noch gefährlicher. Die Route bedeutet: ich selbst (lo0) bin zuständig für das ganze /56.
Das widerspricht der normalen Logik, wo nur die jeweils delegierten /64s auf den physischen Interfaces on-link sind.
- Für Adressen aus dem /56, die keiner /64-Route zugeordnet sind, greift diese lo0-Route.
- Der Kernel behandelt sie als ,,lokal", statt sie sauber als unreachable/off-link zu markieren.
- Ergebnis: Neighbor Discovery läuft ins Leere, Forwarding wird inkonsistent, manche Pakete landen trotzdem auf Default, weil die Adressauflösung auf dem gewählten Interface fehlschlägt.
Ich glaube auch, dass diese zusätzlichen lo0-Einträge so lange unproblematisch sind, wie sie auf nicht überlappende Präfixe angewendet werden.
Aber warten wir doch ab, was passiert, wenn @SarpeTronic die Route löscht - benötigt wird sie sicher nicht. Ich habe das bei mir getan und sie fehlt offenbar nicht, aber wie gesagt, ich habe das Problem aus verschiedenen Gründen nicht...