Messages

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.

Das ist dann das, was hier als pltime und vltime zu sehen ist?

Code Select Expand

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>

EDIT:

P.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% :)

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.

Das 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.

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.

Benutzt 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.

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?

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.

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.

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

Code Select Expand

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:

Code Select Expand

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.

Hier scheint die Firewall dazwischenzufunken?

Code Select Expand

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 ]~

Nach dem Reboot:

Code Select Expand

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

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.

zudem 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.

Route auf dem Client:

Code Select Expand

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

Code Select Expand

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

Das hier kommt auf einem Client:

Code Select Expand

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

Du 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.