IPv6: Clients verlieren Verbindung ins Internet

[meyergru]

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.

[bamf]

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.

[meyergru]

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.

[bamf]

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

[bamf]

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

[bamf]

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.

[bamf]

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

[Zapad]

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.

[JamesFrisch]

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?

[JamesFrisch]

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.

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

[bamf]

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

[bamf]

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.

[meyergru]

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.

[bamf]

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.

[meyergru]

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.