Hallo,
ich versuche mein Glück mal hier, da mit englissprachigen Forum keine Antwort kommt.
Ich betreibe meine OPNSense als Router hinter einem Zyxel-Modem an einem Business-Anschluss der Telekom. Statische IPv4-Adresse, statisches /56 Präfix.
Ich immer kürzer werdenden Abständen verlieren alle meine Clients im Netzwerk die IPv6-Verbindung ins Internet. Kein Ping, kein Traceroute mehr möglich, Clients auch von außen nicht mehr erreichbar.
Die OPNSense behält ihre IPv6-Konnektivität ins Internet. Intern funktioniert weiterhin alles. RA läuft, Clients bekommen globale Adressen und können untereinander über ihre ULAs kommunizieren.
Prevent Release ist aktiviert.
Wenn ich die OPNSense neu starte, funktioniert alles wieder. Für ein paar Stunden, bis es urplötzlich wieder ausfällt.
Welche Infos werden benötigt, um das Problem zu beheben?
ich betreibe zwar IP6 über NAT aber das Problem betrifft mich auch.
WAN deaktivieren und Aktivieren löst das Problem für eine bestimmte Zeit, ich habe da aber keine Regelmässigkeit gemerkt.
Hatte hierzu mal Issue aufgemacht, bin aber auf Community verwiesen worden.
Bei mir hilft nur der komplette Reboot.
So ist das leider kaum produktiv zu betreiben.
Folgendes ist mir noch aufgefallen: Wenn ich "Restart all Services" wähle, werden alle Interfaces rekonfiguriert. Danach sind aber alle Clients offline.
Wenn ich dann einen Reboot mache, ist kurz (also beim Beginn des Shutdowns) wieder Internet da für die Clients. Wer kann das erklären?
Es ist bekannt, dass bei einem Stopp und Neustart des RADVD ein RA mit einer Lifetime von 0 gesendet wird, wenn in den Advanced Einstellungen nicht ausdrücklich AdvDeprecatePrefix=off gesetzt ist. Das dient normalerweise dazu, beim Wechsel des Prefixes den alten Präfix zu invalidieren.
Wenn aber der Prefix der selbe bleibt, wird er dann nicht mehr genutzt.
Der Nachteil beim Setzen auf "off" ist, dass bei einem echten Präfixwechsel die Clients erst nach einer Weile (Ablauf der normal eingestellten Lifetime) den neuen Präfix nutzen. Man sollte diese Zeit also nicht zu lang einstellen. Noch schlechter ist es bei Nutzung von DHCPv6, weil dann die Clients erst selbst nachfragen müssen, um den neuen Präfix zu erfahren.
Ich habe einen Business Anschluss bei der Telekom mit fester IP-Adresse. Mein Präfix ändert sich nie.
DHCPv6 verwende ich nicht, nur SLAAC und RA im Modus Unmanaged.
Ich versuche es mal mit AdvDeprecatePrefix=off.
AdvRemoveRoute dann auch gleich auf off?
Ich würde sagen: ja.
Hat leider nicht geholfen, ich bin schon wieder offline.
Von einem Client aus:
root@pve:~# ping6 opnsense.org
PING opnsense.org(2001:1af8:2050:a001:1::1 (2001:1af8:2050:a001:1::1)) 56 data bytes
^C
--- opnsense.org ping statistics ---
11 packets transmitted, 0 received, 100% packet loss, time 10262ms
root@pve:~# traceroute6 opnsense.org
traceroute to opnsense.org (2001:1af8:2050:a001:1::1) from 2003:a:327:1a00:5a47:caff:fe7b:44a0, port 33434, from port 8058, 30 hops max, 60 bytes packets
1 2003:a:327:1a00::1 (2003:a:327:1a00::1) 0.315 ms 0.180 ms 0.453 ms
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
[...]
Von der OPNSense aus:
root@OPNsense:~ # ping6 opnsense.org
PING(56=40+8+8 bytes) 2003:a:37f:a71a:227c:14ff:fef5:9cfb --> 2001:1af8:2050:a001:1::1
16 bytes from 2001:1af8:2050:a001:1::1, icmp_seq=0 hlim=251 time=117.804 ms
16 bytes from 2001:1af8:2050:a001:1::1, icmp_seq=1 hlim=251 time=117.307 ms
16 bytes from 2001:1af8:2050:a001:1::1, icmp_seq=2 hlim=251 time=117.448 ms
^C
--- opnsense.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 117.307/117.519/117.804/0.209 ms
root@OPNsense:~ # traceroute6 opnsense.org
traceroute6 to opnsense.org (2001:1af8:2050:a001:1::1) from 2003:a:37f:a71a:227c:14ff:fef5:9cfb, 64 hops max, 28 byte packets
1 2003:0:1001:6418::1 6.558 ms 5.227 ms 5.889 ms
2 2003:0:1001:6410::2 7.994 ms 7.300 ms 7.989 ms
3 *
dtag-ic-387338.ip.twelve99-cust.net 116.366 ms 112.639 ms
4 ash-b2-link.ip.twelve99.net 114.989 ms 115.002 ms 114.936 ms
[...]
Mir bleibt wieder nur der OPNSense Reboot.
Noch irgendwelche Ideen?
Ein Neustart des RA Daemons bringt gar nichts. Meine Clients können RA's empfangen, bleiben aber offline.
root@jellyfin:~# rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : high
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Prefix : 2003:a:327:1a00::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 7200 (0x00001c20) seconds
Pref. time : 3600 (0x00000e10) seconds
Prefix : fda6::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 7200 (0x00001c20) seconds
Pref. time : 3600 (0x00000e10) seconds
Recursive DNS server : fda6::e04a:a1ff:fe1f:315
DNS server lifetime : 180 (0x000000b4) seconds
DNS search list : home.arpa
DNS search list lifetime: 180 (0x000000b4) seconds
MTU : 8952 bytes (valid)
Source link-layer address: 20:7C:14:F5:9C:FE
from fe80::227c:14ff:fef5:9cfe
root@jellyfin:~# ping6 golem.de
PING golem.de(golem.de (2a00:13c8:f5::f:4b3d:148)) 56 data bytes
^C
--- golem.de ping statistics ---
46 packets transmitted, 0 received, 100% packet loss, time 46086ms
Die OpnSense hat offensichtlich eine IA_NA, die nicht aus dem /56er Präfix stammt. Man sieht das daran, dass die ersten 56 Bits nicht gleich sind.
Wahrscheinlich kommt es darauf an, wie das WAN- und das LAN-Interface konfiguriert sind. Eventuell bleibt ja der Präfix (IA_PD) gleich, aber die IA_NA eventuell nicht. Je nachdem, was dann als Gateway per RADVD annonciert wird, kann das falsch sein. Bei festen IPv6 kann man ja theoretisch alles statisch konfigurieren, dann ändert sich auch nichts mehr.
Also sowohl auf dem WAN-Interface als auch auf den (V)LANs statisches IPv6. Falls das schon so ist, dann auf DHCPv6.
OMG: Wann wolltest Du eigentlich mitteilen, dass Du einen Proxmox betreibst? Solche Kleinigkeiten sind wichtig, siehe hier, Punkt 16 (https://forum.opnsense.org/index.php?topic=42985.0)!
Die Lösung steht eventuell hier (https://forum.opnsense.org/index.php?topic=44159.0):
QuoteWhen you use bridging with vtnet, there is a known Linux bug with IPv6 multicasting, that breaks IPv6 after a few minutes. It can be avoided by disabling multicast snooping in /etc/network/interfaces of the Proxmox host like:
auto vmbr0
iface vmbr0 inet manual
bridge-ports eth0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094
bridge-mcsnoop 0
Aha, Du nutzt also auch noch ULAs? Man kann es auch kompliziert machen. Ich betreibe das so (https://forum.opnsense.org/index.php?topic=45822.0).
Ich habe den Proxmox nur als Beispiel-Client verwendet. Warum spielt das eine Rolle? Es ist nur ein Mini-PC in meinem LAN.
Das Problem betrifft meinen Laptop, meinen Windows-PC, meine Mini-PCs mit Linux sowie alle Container auf dem Proxmox.
OPNSense läuft Baremetal auf eigener Hardware.
Ja, ich nutze ULAs im LAN. Und das funktioniert auch vollkommen zuverlässig. Alle Geräte können über die ULAs miteinander kommunizieren. Auch jetzt gerade, wo das IPv6-Internet für alle Clients wieder tot ist.
O.K., die ULAs würde ich aus der Gleichung mal entfernen. Ich hatte oben schon angefangen, etwas zu schreiben (durchgestrichen) - das würde ich checken.
Und falls Du auf dem WAN-Anschluss DHCPv6 nutzt, solltest Du entweder auf statische Konfiguration gehen oder "Request Prefix Only" nutzen. Nur so würdest Du den /56er Präfix für OpnSense selbst und Deine Clients nehmen - anderenfalls ist das unterschiedlich. Wenn sich dann die IA_NA ändert, kann es sein, dass Dein per RA verteiltes Gateway nicht mehr stimmt (oder die ULA-Adresse des Gateway genommen wird).
Du müsstest das über die Zeit mal verfolgen, ob die WAN-IPv6 der OpnSense und/oder das Gateway wechseln.
Vom Laptop (Ubuntu) aus:
root@laptop:~# ping6 opnsense.org
PING opnsense.org (2001:1af8:2050:a001:1::1) 56 data bytes
^C
--- opnsense.org ping statistics ---
12 packets transmitted, 0 received, 100% packet loss, time 11241ms
root@laptop:~# traceroute6 opnsense.org
traceroute to opnsense.org (2001:1af8:2050:a001:1::1), 30 hops max, 80 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * *^C
Welche Rolle spielt hier mein Proxmox? Der macht überhaupt keine Netzwerk-Dinge.
Vergiss den Proxmox, wenn er nicht als Host für die OpnSense dient.
Du kannst auf Deinen Linux-Clients mit radvdump auch anschauen, welche RAs gesendet werden und dann checken, was sich ändert, wenn es nicht mehr funktioniert. Meine Vermutung ist, dass die Routen nicht mehr funktionieren.
Quote from: meyergru on June 05, 2025, 10:44:12 PMDu müsstest das über die Zeit mal verfolgen, ob die WAN-IPv6 der OpnSense und/oder das Gateway wechseln.
Also ich bekomme bei der Telekom ein /56 Präfix. Da ich im Netzwerk MTU 9000 nutze, habe ich "Static IPv6" konfiguriert. Denn mit "Track Interface" erbt das Interface die MTU vom PPPoE Interface und dann läuft IPv6 im LAN auf MTU 1500.
Das Ganze hat so monatelang völlig problemlos funktioniert. Erst seit ein paar Wochen (evtl. nach einem OPNSense-Update) verlieren die Clients ihre IPv6-Verbindung ins Internet. Etwa 2x täglich.
Auf den Clients kannst Du mit "ip -6 r s" die Routen ansehen. Bei ULAs kenne ich mich nicht aus, würde aber vermuten, dass Du die Routen dafür separat im RADVD eintragen müsstest. Wie gesagt, ich würde das als Fehlerursache dadaurch ausschließen, dass ich es rausnehme - zudem Du aufgrund eines festen Präfix ja überhaupt keine ULas brauchst, Du kannst doch direkt die GUAs verwenden.
Ich weiß, dass sich im Bereich IPv6 beim DHCP etwas getan hat mit 25.1.x, da hat @Franco ein paar Änderungen durchgeführt.
Und wir sehen ja, dass Deine OpnSense den /56er Präfix nicht selbst verwendet, deswegen: Request Prefix Only.
Das hier kommt auf einem Client:
root@jellyfin:~# radvdump
#
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::227c:14ff:fef5:9cfe
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference high;
AdvLinkMTU 1492;
AdvSourceLLAddress on;
prefix fda6::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS fda6::e04a:a1ff:fe1f:315
{
AdvRDNSSLifetime 180;
}; # End of RDNSS definition
DNSSL home.arpa
{
AdvDNSSLLifetime 180;
}; # End of DNSSL definition
}; # End of interface definition
Route auf dem Client:
root@jellyfin:~# ip -6 r s
::1 dev lo proto kernel metric 256 pref medium
fda6::/64 dev eth0 proto ra metric 1024 expires 7169sec pref medium
default via fe80::227c:14ff:fef5:9cfe dev eth0 proto ra metric 1024 expires 1769sec mtu 1492 pref high
root@jellyfin:~# ping fe80::227c:14ff:fef5:9cfe
PING fe80::227c:14ff:fef5:9cfe(fe80::227c:14ff:fef5:9cfe) 56 data bytes
64 bytes from fe80::227c:14ff:fef5:9cfe%eth0: icmp_seq=1 ttl=64 time=0.633 ms
64 bytes from fe80::227c:14ff:fef5:9cfe%eth0: icmp_seq=2 ttl=64 time=0.305 ms
64 bytes from fe80::227c:14ff:fef5:9cfe%eth0: icmp_seq=3 ttl=64 time=0.159 ms
64 bytes from fe80::227c:14ff:fef5:9cfe%eth0: icmp_seq=4 ttl=64 time=0.253 ms
Ich habe die OPNSense jetzt rebooted und sofort sind alle Geräte wieder online. Für ein paar Stunden, dann bimmelt mein Handy wieder los mit den Alarmen aus dem Monitoring, weil alle IPv6-Adressen offline sind. Ich bin mit meinem Latein völlig am Ende.
Quote from: meyergru on June 05, 2025, 10:55:45 PMzudem Du aufgrund eines festen Präfix ja überhaupt keine ULas brauchst, Du kannst doch direkt die GUAs verwenden.
Alle meine Geräte hier haben eine IPv6-ULA und sind auch so mit Hostnamen im Unbound eingetragen. Sonst müsste ich das ja alles ändern, wenn ich mal den Provider wechsle.
Nach dem Reboot:
root@jellyfin:~# rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : high
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Prefix : 2003:a:327:1a00::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 7200 (0x00001c20) seconds
Pref. time : 3600 (0x00000e10) seconds
Prefix : fda6::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 7200 (0x00001c20) seconds
Pref. time : 3600 (0x00000e10) seconds
Recursive DNS server : fda6::e04a:a1ff:fe1f:315
DNS server lifetime : 180 (0x000000b4) seconds
DNS search list : home.arpa
DNS search list lifetime: 180 (0x000000b4) seconds
MTU : 8952 bytes (valid)
Source link-layer address: 20:7C:14:F5:9C:FE
from fe80::227c:14ff:fef5:9cfe
root@jellyfin:~# radvdump
#
# radvd configuration generated by radvdump 2.18
# based on Router Advertisement from fe80::227c:14ff:fef5:9cfe
# received by interface eth0
#
interface eth0
{
AdvSendAdvert on;
# Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
AdvManagedFlag off;
AdvOtherConfigFlag off;
AdvReachableTime 0;
AdvRetransTimer 0;
AdvCurHopLimit 64;
AdvDefaultLifetime 1800;
AdvHomeAgentFlag off;
AdvDefaultPreference high;
AdvLinkMTU 8952;
AdvSourceLLAddress on;
prefix 2003:a:327:1a00::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
prefix fda6::/64
{
AdvValidLifetime 7200;
AdvPreferredLifetime 3600;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr off;
}; # End of prefix definition
RDNSS fda6::e04a:a1ff:fe1f:315
{
AdvRDNSSLifetime 180;
}; # End of RDNSS definition
DNSSL home.arpa
{
AdvDNSSLLifetime 180;
}; # End of DNSSL definition
}; # End of interface definition
^C
gestern hatte ich wieder so ein Fall:
Wan zeigt ip4 & 6 an, test besagt ich hätte keine funktioniremde IP6 Adresse! egal welche seite.
Habe an Wan interface rumprobiert und Promiscous Modus eingeschaltet und siehe da Test sagt ich hätte eine? Zufall?
dabei hatte ich das interface nicht deaktiviert / aktiviert.
....keine Ahnung was da läuft oder auch nicht.
Seltsam kann die OPNsense weiterhin IPv6 endpoints erreichen, nicht aber deine clients dahinter.
Edit: Habe gerade bemerkt, dass zwei User betroffen sind.
Leider kann ich auch nichts direkt zu deiner Problemlösung beitragen, nur paar Ideen.
Dein Setup ist ein bisschen komplex, was die Fehlersuche eventuell erschwert.
- Ist es möglich das Zyxel Gerät mit der OPNsense zu ersetzten? Die machen immer Ärger, machen es unnötig kompliziert, brauchen Strom usw.
- MTU: ich habe viel zu wenig Ahnung von MTU und vermutlich hat es nix mit deinem Problem zu tun, aber wäre es möglich das zu ändern? Ist mir nur in den Sinn gekommen, weil mit PPPoE Mit PPPoE musst ich auch schon normalization rules für WireGuard anwenden.
Keine Ahnung wie das bei einem DMZ Aufbau aussieht, aber vielleicht auch dort ein Problem?
- ISPs die PPPoE anstelle von DHCPv6 einsetzten sind Käse. Daran erkennt man IMHO schlechte ISPs. Würde ich persönlich mich nach Alternativen umsehen. Was hat das jetzt mit deinem Problem zu tun? Nun, solche schlechten ISPs verwenden schlechte Router und haben häufig auch so "neumodische" Dinge wie IPv6 nicht im Griff. Eventuell ist dein Problem auch beim Router oder deinem ISP?
Quote from: Zapad on June 06, 2025, 07:51:25 AMgestern hatte ich wieder so ein Fall:
Wan zeigt ip4 & 6 an, test besagt ich hätte keine funktioniremde IP6 Adresse! egal welche seite.
Habe an Wan interface rumprobiert und Promiscous Modus eingeschaltet und siehe da Test sagt ich hätte eine? Zufall?
dabei hatte ich das interface nicht deaktiviert / aktiviert.
....keine Ahnung was da läuft oder auch nicht.
Test-ipv6.com and ipv6-test.com both don't really work reliably in my experience.
I suggest using three different URLs instead. These URLs will return you the IP you used to reach the site.
https://checkipv4.salzmann.solutions is IPv4 only. If you can't reach this site, your IPv4 is broken or missing.
https://checkipv6.salzmann.solutions is IPv6 only. If you can't reach this site, your IPv6 is broken or missing.
https://checkip.salzmann.solutions is both. This is a good way to find out if your browser prefers IPv6 over IPv4 (which it should).
Hier scheint die Firewall dazwischenzufunken?
block drop in log quick on pppoe0 reply-to (pppoe0 fe80::200:ff:fe00:0) inet6 proto tcp from any to (lagg0:network) port = http label "a19e6f0e7fc93150f8f6df2d8f873997" [ Evaluations: 2140 Packets: 74 Bytes: 5888 States: 0 ]
block return in log quick on pppoe0 reply-to (pppoe0 fe80::200:ff:fe00:0) inet6 proto tcp from any to (lagg0:network) port = ssh label "66313a1041031e76c4a5fcbdbabed844" [ Evaluations: 2066 Packets: 1 Bytes: 64 States: 0 ]~
Aus Verzweiflung habe ich jetzt mal mein ganzes Netzwerk zurück auf MTU 1500 gestellt und die IPv6-Konfiguration auf "Track Interface" statt static. So wie es in der Anleitung vorgesehen ist. Das hat funktioniert, danach waren meine Geräte online.
Aber auch wieder nur ein paar Stunden lang. Danach war wieder alles offline. Diesmal aber mit anderem Fehlerbild. Meine Geräte haben gar kein öffentliches Präfix mehr bekommen:
root@jellyfin:~# rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : high
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Prefix : fda6::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 86400 (0x00015180) seconds
Pref. time : 14400 (0x00003840) seconds
Recursive DNS server : fda6::e04a:a1ff:fe1f:315
DNS server lifetime : 1800 (0x00000708) seconds
DNS search list : home.arpa
DNS search list lifetime: 1800 (0x00000708) seconds
MTU : 1492 bytes (valid)
Source link-layer address: 20:7C:14:F5:9C:FE
from fe80::227c:14ff:fef5:9cfe
Neustart des Interfaces, der PPPoE-Verbindung, des RA Daemons hat alles nicht geholfen. Keine Chance.
Erst nach einem Reboot geht es nun wieder:
root@jellyfin:~# rdisc6 eth0
Soliciting ff02::2 (ff02::2) on eth0...
Hop limit : 64 ( 0x40)
Stateful address conf. : No
Stateful other conf. : No
Mobile home agent : No
Router preference : high
Neighbor discovery proxy : No
Router lifetime : 1800 (0x00000708) seconds
Reachable time : unspecified (0x00000000)
Retransmit time : unspecified (0x00000000)
Prefix : 2003:a:327:1a00::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 86400 (0x00015180) seconds
Pref. time : 14400 (0x00003840) seconds
Prefix : fda6::/64
On-link : Yes
Autonomous address conf.: Yes
Valid time : 86400 (0x00015180) seconds
Pref. time : 14400 (0x00003840) seconds
Recursive DNS server : fda6::e04a:a1ff:fe1f:315
DNS server lifetime : 1800 (0x00000708) seconds
DNS search list : home.arpa
DNS search list lifetime: 1800 (0x00000708) seconds
MTU : 1492 bytes (valid)
Source link-layer address: 20:7C:14:F5:9C:FE
from fe80::227c:14ff:fef5:9cfe
Was ist hier kaputt? Das kann doch nicht sein.
Das zeigt eindeutig, dass der GUA-Präfix 2003:....) verloren geht und durch Deinen ULA-Präfix fda6:... ersetzt wird - und genau dann geht es nicht mehr. Wenn der GUA-Präfix wieder da ist, geht es.
Das zeigte sich ja auch in den RADVDUMPs. Wenn es nicht mehr geht, wird offenbar nur noch der ULA-Präfix verteilt. Damit klappt es natürlich nicht, selbst, wenn das Gateway (meist eine Link-Local-IPv6) korrekt ist, weil die ULA-Absenderadresse nicht geroutet werden kann.
Du kannst Dir ja in beiden Zuständen mal die /var/etc/radvd.conf ansehen. Bei mir stehen da jeweils nur die GUAs drin. Ändern müsste sich der Inhalt, wenn das WAN einen Präfix bekommt, eventuell auch, wenn der sich ändert oder, wenn die Leasezeit abläuft (selbst, wenn sich der Präfix nicht ändert).
Wie ich schon sagte, das kannst Du wahrscheinlich verhindern, indem Du Deine OpnSense-Interfaces statisch mit den GUAs konfigurierst. Die sollten dann in die /var/etc/radvd.conf übernommen werden und sich dann auch nicht mehr ändern.
Wie meinst du das, ersetzt? Der ULA Präfix ist doch immer da. Der funktioniert auch immer. Im Fehlerfall verschwindet nur das GUA-Präfix. Was ja jetzt auch ein völlig neues Fehlerbild ist mit der geänderten Konfiguration. Der ursprüngliche Fehler war, dass die Clients trotz GUA keine Verbindung mehr ins Internet hatten. Da gab es auch absolut keine Unterschiede in der Routingtabelle.
Die ULA- und GUA-Adressen errechnen sich bei mir aus den MAC-Adressen. So steuere ich das ganze auch.
Und wie gesagt, das ganze hat seit Jahresbeginn monatelang funktioniert. Vor den Ausfällen hatte ich an meiner funktionierenden Konfiguration nichts geändert.
Ich werde mir mal die radvd.conf und Routing-Tabelle anschauen, wenn es wieder ausfällt. Danke dir auf jeden Fall schon mal für die Hilfe bis hierhin.
EDIT:
Kann es sein, dass du die Code-Blöcke nicht ausgeklappt hast? Das ULA-Präfix ist in beiden Code-Blöcken zu sehen. Es ist immer da und funktioniert immer einwandfrei. Da wird nichts ersetzt.
Ich meinte den Wegfall der GUA in den router advertisements. Nur habe ich das so noch nie gesehen, wenn keine ULA im Spiel ist.
Ich will nicht ausschließen, dass geändertes Handling im DHCPv6 Client die Ursache ist. Deswegen würde ich den ja weglassen, wenn ich feste IPs hätte. Ob das der Fall ist, müsstest Du am Inhalt der radvd.conf sehen.
Du meinst, ich soll meinen ~50 Geräten hier im Netzwerk manuell IPv6-Adressen zuweisen? Ich glaube das ist nicht wirklich umsetzbar. Zudem ich hier in meinem Homelab viel bastle und oft neue Maschinen und Container hochziehe. So kann das ja auch nicht gedacht sein, dafür ist RA doch da.
Nein, Du missverstehst mich. Du sollst dem WAN der OpnSense die GUA fest eintragen und nicht per DHCPv6 Client konfigurieren. Das Problem entsteht doch offenbar genau dann, wenn (k)ein neuer Präfix geholt wird und dann Dein RADVD neu gestartet wird (wahrscheinlich mit anderer Konfiguration).
Ergo: Verhindere, dass der RADVD neu gestartet wird, indem Du keinen DHCPv6 Client auf dem WAN nutzt.
Dazu musst Du Deinen /56er Präfix auf dem WAN mit 8 Bits ergänzen - genau wie auf den (V)LAN-Interfaces, nur müssen sich die Werte halt unterscheiden.
BTW: Wie vergibst Du eigentlich die ULAs auf den (V)LANs? Als Virtual IPs?
Ich hab ja auch einen Business-Anschluss der DTAG, bzw. deren mehrere.
Ich benutze DHCPv6 auf WAN, aber konfiguriere LAN und alle anderen Interfaces statisch. Damit hat der radvd natürlich immer dasselbe stabile Prefix anliegen.
Benutzt du am Ende "Track Interface"? Ist doch bei einem statischen Prefix nicht nötig.
Sorry, wenn am Thema vorbei - ich steige verspätet ein und habe zugegebenermaßen nicht den ganzen Thread gelesen.
Grüße
Patrick
Bedeutet, ich nehme die IPv6-GUA, die mein LAN-Interface via "Track Interface" bekommen hat und trage die als "Static IPv6" beim WAN-Interface ein? mit /64 Präfix?
Nein. Die ersten 56 Bits sind gleich, dann musst Du 8 Bits selbst - aber anders - setzen, als auf dem LAN-Interface, dann die EUI-64 des WAN-Interfaces. Und ja, mit /64er Netzmaske. Oder eben, wie Patrick sagt: DHCPv6 auf dem WAN, aber die (V)LANs mit statischer Konfiguration. Da gilt dann das selbe, jedes Interface muss die 8 Bits anders gesetzt haben.
Die Clients bekommen dann die IPs vom RADVD - dem ist es eigentlich egal, woher die (V)LAN-IP kommt.
Und, ja, Patrick, das ist genau das Problem. Bei Track Interface und gleichzeitigem Einsatz von ULAs fällt beim Ablauf der WAN-Lease offenbar die GUA in den RAs weg. Und dann ist es Essig mit Internet-Zugriff.
Quote from: Patrick M. Hausen on Today at 12:28:47 AMBenutzt du am Ende "Track Interface"? Ist doch bei einem statischen Prefix nicht nötig.
Nein, als ich diesen Thread begonnen habe, habe ich die IPv6-Adresse auf dem LAN-Interface statisch konfiguriert. Das war auch nötig, da ich im LAN MTU 9000 genutzt habe und das hätte mit "Track Interface" nicht für IPv6 funktioniert, da damit die MTU des PPPoE-Interface übernommen wird.
Jetzt habe ich im Laufe der Fehlersuche MTU 9000 über den Haufen geworfen und "Track Interface" konfiguriert. So wie es hier steht https://docs.opnsense.org/manual/how-tos/ipv6_dsl.html
Damit ist das neue Fehlerbild entstanden, dass jetzt sogar das Präfix auf den Clients verloren geht.
Dann probier mal statisch mit der Standard-MTU. Absolut keine Probleme damit an mehreren Standorten seit Jahren. Und verschiedene Modems - Zyxel, Draytek, Telekom Glas-ONT, ...
Ja, ich bin jetzt wieder auf MTU 1500. Das bedeutet massiv viel mehr Last für den Router. Wenn ich da mit 10G Daten raufschiebe (im LAN), kommen mit MTU 1500 etwa 2,5 Gbit/s an, mit MTU 9000 kommen 8,5 Gbit/s an. Aber ich lasse das jetzt mal so. War sowieso alles fummelig mit der PMTUD und den fragmentierten Paketen von nicht kompatiblen Geräten.
Eine statische Konfiguration auf dem LAN (bei mir ein failover-lagg) hatte ich ja bisher. Das war der Stand, als ich diesen Thread eröffnet habe.
Ja, nur nicht auf dem WAN. Und da liegt das Problem: Trotz statischer Adressen nehme ich an, dass Die Telekom begrenzte Lease-Zeiten hat. Und wenn diese abläuft, wird Dein RADVD neu konfiguriert und gestartet. Ich nehme eben an, dass danach nur die ULAs erhalten bleiben und somit alle Clients die Verbindung verlieren. Und wie gesagt: Das wäre natürlich ein OpnSense-Fehler, der wahrscheinlich früher nicht bestand.
Eine andere Möglichkeit wäre, dass wirklich die OpnSense die Verbindung verliert, aber das hast Du im Eingangspost ausgeschlossen.
P.S.: Ich verwende die Standard-MTU und kann ohne weiteres 10 GBit/s zwischen den VLANs routen, habe allerdings kein LAGG.
Richtig, die OPNSense behält ihre IPv6-Verbindung ins Internet. Da kann ich beliebige Hosts auflösen, anpingen, tracerouten. Nur auf den Clients geht plötzlich nix mehr.
Quote from: meyergru on Today at 12:54:33 AMDas wäre natürlich ein OpnSense-Fehler, der wahrscheinlich früher nicht bestand.
Also möglicherweise durch ein Update passiert? Ich installiere ja alle Updates immer sofort, wenn sie angeboten werden. Daher kann ich das auch nicht auf ein bestimmtes Update zurückführen. Lohnt es sich, dafür ein Issue aufzumachen?
Heute schaffe ich hier nichts mehr, aber ich werde mich spätestens am freien Montag mal mit der WAN-Konfiguration und meinem Präfix beschäftigen und versuchen, das ganze statisch zu konfigurieren. Nochmals Danke für eure Hilfe bis hierhin.
Na klar lohnt sich ein Bugreport, aber dafür müsstest Du den Fehler in die Wunde legen können. Im Idealfall würde man dann ggf. sehen, was nach dem Lease-Ablauf schiefgeht. Meine Theorie wäre eine geänderte radvd.conf.
Noch besser wäre es, wenn Du wüsstest, welche Version noch funktioniert hat.
EDIT:
Quote from: meyergru on Today at 12:54:33 AMP.S.: Ich verwende die Standard-MTU und kann ohne weiteres 10 GBit/s zwischen den VLANs routen, habe allerdings kein LAGG.
Hat gar nichts mit dem LAGG zu tun. Das ist ja auch nur Active/Backup mit 10G DAC /2,5G RJ45. Der Prozessor schafft einfach nicht mehr. Es ist ein Intel Atom C3808 mit 12 Kernen @ 2.00GHz. Die sind dann auch alle auf 100% :)
Quote from: meyergru on Today at 12:54:33 AMTrotz statischer Adressen nehme ich an, dass Die Telekom begrenzte Lease-Zeiten hat. Und wenn diese abläuft, wird Dein RADVD neu konfiguriert und gestartet.
Das ist dann das, was hier als pltime und vltime zu sehen ist?
pppoe0: flags=10088d1<UP,POINTOPOINT,RUNNING,NOARP,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1492
description: WAN_Telekom (opt1)
options=0
inet 87.128.39.65 --> 62.156.244.46 netmask 0xffffffff
inet6 fe80::227c:14ff:fef5:9cfb%pppoe0 prefixlen 64 scopeid 0x10
inet6 2003:a:37f:a71a:227c:14ff:fef5:9cfb prefixlen 64 autoconf pltime 1800 vltime 14400
nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
schau dir mal diese Beiträge an:
https://forum.opnsense.org/index.php?topic=46194.0
Damit habe ich das Problem mit 10Gbe über Sense gelöst.
Ausserdem lasse ich IPv6 über NAT Laufen.
Das Problem mit Verlust der IP6 im Wan ist zwar da, aber rein sporadisch vllt. 1x die Woche oder seltener aber ich
konfiguriere/ändere Sense fast jeden tag.... :D
Quote from: bamf on Today at 01:40:54 AMDas ist dann das, was hier als pltime und vltime zu sehen ist?
Ja. Du kannst das Logging dafür auch hochdrehen: Interfaces : Settings -> IPv6 DHCP -> Log Level.
Ich würde davon ausgehen, dass nach Ablauf der Leasetime (oder der Hälfte davon?) /usr/local/etc/rc.newwanipv6 aufgerufen wird.