Messages

After Reboot it comes back

fa00::/56              link#7                        USB             lo0

At the moment here is no "wrong" traffic

Since yesterday I unchecked:
Send prefix hint   

Er verwirft das Paket aber nicht, sondern dupliziert das immer weiter

Um das nochmal klarzustellen, es immer ein einziges Paket aus dem 00er Netz im Portbereich >50.000 auf eine IPv6 Adresse, die es gibt oder gegeben hat.
Ich hatte bisher folgende Ports: 53 (DNS), Port 389 (LDAP), 443 (SSL)
Ich kann mit voller Bandbreite up- und downloaden, aber er sendet halt zigtausende Pakete auf der ppoe Schnittstelle, wo diese Pakete gar nicht sein dürften, da alle /56 Netze intern geroutet werden.

I deleted A:A:A:fa00::/56                     link#7                        USB             lo0
but at the moment, there is no loop

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.

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.

ob der Präfix oder nur die EUI-64 wechselt

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::

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:~ #

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.

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?

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

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?

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.

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.

os-etpro-telemetry (installiert)   1.7_5   50.3KiB   2   OPNsense   ET Pro Telemetry Edition
2025-04-24T11:25:22   Error   suricata   [100104] <Error> -- Just ran out of space in the queue. Please file a bug report on this

The Router is connected to a TELEKOM 250/40 DSL with fixed IPv4 and IPv6 and a O² 5G with dynamic IPv4, reachable over the Internet.
I configured 3 Gateways, one IPv6 and two IPv4 and created two Gateway Group, one with the single IPv6 and one with the two IPv4, all three set to Tier 1, to get the best load balancing, both lines are nearly the same bandwide, with a better quality of the DSL Line, what is monitored under System: Gateways: Configuration.
This worked fine till 24.7.6, the Gateway went first IPv6, than IPv4 DSL but also used reliable the 5G for adding bandwide, now my OPNsense uses nearly only the 5G line, even if it's lower quality and IPv6 is prefered by standard of the OS.

OPNSense natürlich, ich kannte das man bei DrayTek auch PPPoE bei IPv6 einstellt.

Danke für die Info und Deine Unterstützung

Ich habe heute schon wieder das Nächste gefunden, Asterisk über IPv6, ein lang gehegter Herzenswusch von mir.
Der verbindet sich mit SIPGATE (Trunk), ich kann raustelefonieren, aber ich kann nicht angerufen werden.
Aber jetzt ist erst einmal Wochenende  8)