Messages

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)

Hallo Franco,

supervielen Dank dafür, aber ist das ein Plugin, ein Update, ein Script?

Wie sag ich es meiner Mutter und, vor allem, der OPNSense?

Gruß

Uwe

Edit:

Wer lesen kann, der lese. Das war auch zu einfach um Verständlich zu sein 🤣

<13>1 2024-08-23T03:14:29+02:00 ********** opnsense 20718 - [meta sequenceId="126"] /usr/local/etc/rc.newwanipv6: plugins_configure newwanip (execute task : dhcrelay_ensure_running(,lan,inet6))

So far so good, es schaut so aus, als ob mein Problem damit gelöst wäre.

Vielen lieben dank

PS: gibt es einen grund warum die PFSense bei IPV6 DHCP möchte, anstatt PPPoEv6?

so ähnlich:

<13>1 2024-08-22T00:03:52+02:00 ****** opnsense 292 - [meta sequenceId="316"] /usr/local/etc/rc.bootup: plugins_configure bootup (execute task : dhcrelay_configure_do(1))
<12>1 2024-08-22T00:03:52+02:00 ****** opnsense 292 - [meta sequenceId="317"] /usr/local/etc/rc.bootup: dhcrelay_configure_do() found no suitable IP address for lan(igc0)
<13>1 2024-08-22T12:38:06+02:00 ****** opnsense 292 - [meta sequenceId="318"] /usr/local/etc/rc.bootup: plugins_configure bootup (execute task : dhcrelay_configure_do(1))
<12>1 2024-08-22T12:38:06+02:00 ****** opnsense 292 - [meta sequenceId="319"] /usr/local/etc/rc.bootup: dhcrelay_configure_do() found no suitable IP address for lan(igc0)

Wenn ich den Dienst neu starte kommt kein Fehler

Halo Franco, danke für Deine Antwort, aber Services: DHCRelay: Log File ist jungfräulich.

Hallo,

mein Problem ist nicht so kritisch, aber bei einer Firewall möchte man eigentlich, dass diese perfekt funktioniert.
DHCPv6 Relay (lan) wird nach einem Neustart nicht automatisch gestartet, manuell lässt sich der Dienst aber starten und bleibt stabil.

Ich glaube, es begann mit der Version 24.7.
Aktuell habe ich OPNsense 24.7.2-amd64
CPU ist eine N400 4C, Netzwerkkarten sind von Realtek, das Plugin os-realtek-re ist installiert

Ich habe eine feste IP's bei der Telekom und eine 5G Flat bei O², nur IPv4, diese aus dem Internet erreichbar

Interfaces: [WAN0]
IPv4 Configuration Type = PPPoE
IPv6 Configuration Type = DHCPv6
Use IPv4 connectivity = Yes
Request prefix only =    Yes
Send prefix hint =         Yes

Interfaces: [WAN1]
IPv4 Configuration Type = DHCP

Interfaces: Point-to-Point: Devices
pppoe0
Link Type = PPPoE
Die üblichen Telekom Zugangsdaten

Interfaces: [LAN]
IPv6 Configuration Type = Track Interface
Manual configuration = Yes Allow manual adjustment of DHCPv6 and Router Advertisements

Services: DHCRelay: Configuration
Destinations = jeweils einen Eintrag für IPv4 & IPv6 Adressen mit je 4 IP-Adressen
Relays die beiden o.a. Destinations auf Interface LAN auf Enabled

Ich hoffe, ich habe nichts vergessen und finde jemanden, der mir eventuell helfen kann und möchte.

Gruß

Uwe Sarpe