IPv6 fällt immer wieder aus

The_eagle · 23. Dezember 2024 um 18:00

Mir fällt gerade etwas ein. Bei der pfsense gibt es die Option:

Do not allow PD/Address release - dhcp6c will send a release to the ISP on exit, some ISPs then release the allocated address or prefix. This option prevents that signal ever being sent

Wenn es die bei der OPNsense auch gibt, solltest du die mal aktivieren.
Vielleicht passiert ja genau das bei dir und der DHCPv6-Client sendet genau so ein Release-Signal an die Telekom, mit der Folge, dass dann die IPv6-Adresse weg ist.

Bei der pfsense versteckt diese Option sich unter System → Advanced → Networking und da dann DHCP Options

neelix8200 · 23. Dezember 2024 um 18:24

Es gibt diese Einstellung:

Was anderes habe ich gerade nicht gefunden.

In Weirdness with IPv6 and DHCPv6... - Page 2 gibt es noch eine Diskussion, dass die vordefinierten IPv6-ICMP Regeln wohl nicht ganz korrekt sind.

Mal schauen, wie lange mein IPv6 nach der Umstellung auf PCI jetzt hält.

The_eagle · 24. Dezember 2024 um 06:57

Ja, ich denke das ist der richtige Punkt. Ich würde da bei Prevent Release mal ein Häkchen setzen. Schaden kann es nicht, insbesondere da es bei dir ja keine Zwangstrennung gibt.

neelix8200 · 24. Dezember 2024 um 13:45

So. Heute ist mein IPv6 wieder weg. Seit wann genau kann ich nicht sagen. Bin gerade erst an den PC.

Windows meldet:

   IPv6-Adresse. . . . . . . . . . . : 2003:c2:4f32:cb00:5be8:60b9:8bcb:2aff
   Temporäre IPv6-Adresse. . . . . . : 2003:c2:4f32:cb00:7135:aaa1:491b:1e7
   Verbindungslokale IPv6-Adresse  . : fe80::3640:c8c9:5747:d17c%9
   IPv4-Adresse  . . . . . . . . . . : 192.168.13.73
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::be24:11ff:fe7b:678e%9
                                       192.168.13.254

IPv6-Routentabelle
===========================================================================
Aktive Routen:
 If Metrik Netzwerkziel             Gateway
  9    281 ::/0                     fe80::be24:11ff:fe7b:678e
  1    331 ::1/128                  Auf Verbindung
  9    281 2003:c2:4f32:cb00::/64   Auf Verbindung
  9    281 2003:c2:4f32:cb00:5be8:60b9:8bcb:2aff/128
                                    Auf Verbindung
  9    281 2003:c2:4f32:cb00:7135:aaa1:491b:1e7/128
                                    Auf Verbindung
 25   5256 fe80::/64                Auf Verbindung
  9    281 fe80::/64                Auf Verbindung
  7    291 fe80::/64                Auf Verbindung
  7    291 fe80::23e:5081:d210:ec66/128
                                    Auf Verbindung
  9    281 fe80::3640:c8c9:5747:d17c/128
                                    Auf Verbindung
 25   5256 fe80::ea07:e056:b796:83b2/128
                                    Auf Verbindung
  1    331 ff00::/8                 Auf Verbindung
 25   5256 ff00::/8                 Auf Verbindung
  9    281 ff00::/8                 Auf Verbindung
  7    291 ff00::/8                 Auf Verbindung
===========================================================================

Die Interfaces:

Aber alle Seiten laden nur über IPv4.

neelix8200 · 24. Dezember 2024 um 13:48

C:\>nslookup
DNS request timed out.
    timeout was 2 seconds.
Standardserver:  UnKnown
Address:  2003:c2:4f27:6e01:be24:11ff:fe7b:678e

> www.heise.de
Server:  UnKnown
Address:  2003:c2:4f27:6e01:be24:11ff:fe7b:678e

DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
DNS request timed out.
    timeout was 2 seconds.
*** Zeitüberschreitung bei Anforderung an UnKnown.

The_eagle · 24. Dezember 2024 um 13:56

Aber das hier:
https://v64.tech/uploads/default/original/2X/3/3ad5c0255dbcf76248d32284a0584b92cb703dc0.png
sieht alles richtig aus.
WAN, LAN und OPT1 sehe aus wie sie aussehen müssen.
Daran liegt der Fehler nicht.

The_eagle · 24. Dezember 2024 um 14:24

Die v6-Adresse von www.heise.de ist 2a02:2e0:3fe:1001:7777:772e:2:85
Bei dir wird die ja offenbar nicht aufgelöst.
Kannst du die direkt anpingen, also ping -6 2a02:2e0:3fe:1001:7777:772e:2:85
Teste das mal sowohl unter windows am LAN wie auch per ssh über die Konsole der sense.

[2.7.2-RELEASE][admin@pfSense.localdomain]/root: nslookup www.heise.de
Server:		127.0.0.1
Address:	127.0.0.1#53

Non-authoritative answer:
Name:	www.heise.de
Address: 193.99.144.85
Name:	www.heise.de
Address: 2a02:2e0:3fe:1001:7777:772e:2:85

neelix8200 · 24. Dezember 2024 um 14:47

Von der Konsole der OPNSense aus kann ich Name und IP anpingen. Vom PC aus nicht.

jesn_tec · 25. Dezember 2024 um 10:04

Ich hab ähnliches Problem gehabt mit meiner IPv4… Mal lief alles für 15 Tage sauber, mal nur 2 Tage, mal nur 7 Tage… Nach einem Reboot lief es immer wieder, selbst neustecken, damit die OpnSense merkt huch da ist mein PPPoE weggeflogen, hat nicht geholfen.
Danach habe ich mal gelesen, dass man das Interface Resetten soll.

Unter System → Einstellungen → Cron kann man einen Job erstellen, der z.B. Jeden Tag um 06:00 Uhr deinen WAN einmal resettet… geht auch Tag gebunden. Dafür einfach einen Job mit dem Befehlt „Periodic interface reset“ und als Parameter „wan“ übergeben.

Im meinem Beispiel hier hab ich jeden Montag um 06:00 Uhr den reset.

Da der Link auch schon mal eher weggeflogen ist habe ich das ganze bei mir auf Montag, Mittwoch, Freitag und Samstag aufgeteilt, jeweils zu anderen Uhrzeiten.

Seit dem habe ich kein Problem mehr. Telekom konnte nicht helfen und meine ganzen IT Nerds auch nicht, da sich das PPPoE einfach irgendwie komplett weghängt. Hatte das selbe Problem mit der PfSense auch schon…
Jetzt fliegt der Link kontrolliert für 5-10 Sekunden bei der Neueinwahl weg um die eingestellten Uhrzeiten, aber damit kann ich leben.

Ich habe das Telekom Glasfaser Modem 2 und dahinter auch einen Mini PC mit J4125 Prozessor und 2 Intel NICs…

The_eagle · 25. Dezember 2024 um 10:27

Damit ist klar, dass du eine stabile IPv6-Verbindung am WAN hast. Zumindest jetzt. Gut möglich, nun so aber nicht mehr nachvollziehbar, dass das zuvor auch anders war, als das WAN noch über eine Bridge lief.

Das aktuelle Problem liegt im LAN, bzw. am LAN-Interface. Du hast ja neben WAN und LAN noch OPT1. Wie viele physikalische NIC’s hat deine Hardware denn? Ich vermute jetzt mal vier, denn drei wäre ja schon ungewöhnlich.
Oder hast du nur zwei physikalische NIC’s und auf der LAN-Bridge noch zwei VLAN’s?

Um der Ursache auf den Grund zu kommen:

wie sind deine Brindge’s konfiguriert?
wie sieht denn die Ausgabe eines „ifconfig“ am Host (per ssh) aus?
welche Router-Advisements hast du gesetzt?
falls du DHCP6 verwendest, welchen DHCPv6-Server nutzt du (KEA oder ISC)?

Du erwähntest eine REWE-App, an der du das immer Sonntags merken würdest, dass v6 nicht geht.

Läuft die auf einem Android-Device?
Welche Geräte (Betriebssysteme) hast du generell um LAN und in OPT1)?
Hintergrund der Frage: Android hat keinen DHCPv6-Client, kann also nur SLAAC.

The_eagle · 25. Dezember 2024 um 10:36

an der PPPoE-Verbindung kann es aktuell nicht mehr nicht liegen. neelix8200 konnte ja per ssh direkt von der OPNsense sowohl per IPv6 Namen auflösen und v6-pings senden, während das zeitgleich vom Windows-Device am LAN nicht ging. Wäre sein IPv6 am WAN oder gar das ganze PPPoE weg, hätte es auch per ssh direkt von der OPNsense aus nicht klappen dürfen.

neelix8200 · 5. Januar 2025 um 13:13

root@pve:~# ip a l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host noprefixroute
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master vmbr0 state UP group default qlen 1000
    link/ether a8:b8:e0:03:fe:91 brd ff:ff:ff:ff:ff:ff
3: enp2s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b8:e0:03:fe:92 brd ff:ff:ff:ff:ff:ff
4: enp3s0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether a8:b8:e0:03:fe:93 brd ff:ff:ff:ff:ff:ff
6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a8:b8:e0:03:fe:91 brd ff:ff:ff:ff:ff:ff
    inet 192.168.13.250/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::aab8:e0ff:fe03:fe91/64 scope link
       valid_lft forever preferred_lft forever
11: tap102i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr102i0 state UNKNOWN group default qlen 1000
    link/ether d6:e9:ed:44:a7:36 brd ff:ff:ff:ff:ff:ff
12: fwbr102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether ce:66:0b:c4:d1:61 brd ff:ff:ff:ff:ff:ff
13: fwpr102p0@fwln102i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether 5e:6a:06:a0:db:94 brd ff:ff:ff:ff:ff:ff
14: fwln102i0@fwpr102p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr102i0 state UP group default qlen 1000
    link/ether ce:66:0b:c4:d1:61 brd ff:ff:ff:ff:ff:ff
15: tap102i1: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr102i1 state UNKNOWN group default qlen 1000
    link/ether 1a:bc:fa:a2:aa:ba brd ff:ff:ff:ff:ff:ff
16: fwbr102i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 02:f1:a6:ab:82:36 brd ff:ff:ff:ff:ff:ff
17: fwpr102p1@fwln102i1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether ca:18:5b:96:84:d7 brd ff:ff:ff:ff:ff:ff
18: fwln102i1@fwpr102p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr102i1 state UP group default qlen 1000
    link/ether 02:f1:a6:ab:82:36 brd ff:ff:ff:ff:ff:ff
19: tap103i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master fwbr103i0 state UNKNOWN group default qlen 1000
    link/ether ca:5b:15:8f:f6:01 brd ff:ff:ff:ff:ff:ff
20: fwbr103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 4e:95:1e:08:d4:d0 brd ff:ff:ff:ff:ff:ff
21: fwpr103p0@fwln103i0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master vmbr0 state UP group default qlen 1000
    link/ether b6:6b:ec:bb:77:00 brd ff:ff:ff:ff:ff:ff
22: fwln103i0@fwpr103p0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master fwbr103i0 state UP group default qlen 1000
    link/ether 4e:95:1e:08:d4:d0 brd ff:ff:ff:ff:ff:ff
25: tap101i0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 8e:9e:dd:55:6c:54 brd ff:ff:ff:ff:ff:ff
26: tap101i2: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master vmbr0 state UNKNOWN group default qlen 1000
    link/ether 32:97:49:08:cf:a9 brd ff:ff:ff:ff:ff:ff

Nichts konfiguriert. Alles auf Default.

Die REWE App läuft unter Android ja. Jede andere App fällt irgendwann auf IPv4 zurück, die aber anscheinend nicht und meldet stattdessen „Du bist Offline“.

Ich habe hier Windows und Android im LAN. In OPT läuft ein Freikunk- Offloader und eine Linux VM mit Docker. Und da scheint das IPv6 keine Probleme zu machen. Muss also scheinbar irgendwie im/am LAN Interface hängen.

neelix8200 · 5. Januar 2025 um 13:25

und hier die Konfig der Interfaces

net0 ist LAN
net2 ist OPT
hostpci1 ist WAN

The_eagle · 5. Januar 2025 um 13:42

Du meinst du hast keinerlei Router-Advisements gesetzt?
Nun weiß ich nicht was bei der OPNsense Default ist, bei der pfsense ist der Default Router Mode in den Router Advertisements diabled. Das aber bedeutet es werden keinerlei IPv6-Adressen vergeben. Die Clients würfeln die sich selbst aus und bekommen auch kein IPv6-Prefix, etc. mitgeteilt. Haben am Ende nur Link-Local-Adressen im LAN.
Das kann nicht das sein was du willst.
Versuch es mal mit Unmanaged als Router Mode

The_eagle · 5. Januar 2025 um 14:18

Lies dir die folgend verlinkten Infos mal durch:
https://docs.opnsense.org/manual/radvd.html
https://docs.netgate.com/pfsense/en/latest/services/dhcp/ipv6-ra.html
Da erfährst du einiges über Sinn und Zweck der IPv6 Router Advertisements

neelix8200 · 5. Januar 2025 um 15:40

Diese Einstellungen gibt es bei OPNSense so nicht und laut Anleitung ist da auch alles schon richtig eingestellt:
https://docs.opnsense.org/manual/ipv6.html

Ich habe jetzt mal auf pfSense umgestellt. Mal schauen, ob es damit besser läuft.

Der erste Unterschied ist schon mal: Ich sehe die IPv6 Adressen im Dashboard:

neelix8200 · 5. Januar 2025 um 16:11

So. Feedback: negativ.
Der Effekt bleibt. Es muss also irgendwas im Proxmox sein. Aber was?

neelix8200 · 5. Januar 2025 um 16:37

Hat das vllt. mit meiner VLAN Konstellation zutun?

Die OPNSense/pfSense hat ja zwei Interfaces, die auf der gleichen Bridge enden:
LAN: untagged
OPT1: tagged mit 138

Ich hatte hier 1:1 die Konfiguration kopiert wie ich sie unter ESXi hatte. Aber ESXi entspricht ja ehr OVS als Linux Bridge.

Muss ich vielleicht hier was ändern?

The_eagle · 5. Januar 2025 um 18:00

Ich denke du sucht an der falsch Stelle. Selbstredend hat auch die OPNsense Router-Advisements. Das steht ja genau so auch in der offiziellen OPNsense-Dokumentation.
https://docs.opnsense.org/manual/radvd.html

Demnach kennt die OPNsense die Modes:Router Only, Unmanaged, Managed, Assisted, Stateless
Also was ist bei dir da eingetragen?
Es nutzt ja nun mal wenig, wenn das LAN-Inteace zwar korrekt konfiguriert wird, die Devices im LAN die aber nicht mitgeteilt bekommen, weil die Router-Advisements auf Router Only stehen und es deswegen weder SLAAC noch DHCPv6 gibt. Ist genau so, als würdest du IPv4 konfigreiren, dann aber vergessen den DHCPv4-Server zu konfigurieren und zu starten und die Clients warten alle ewig auf die Zuweisung einer IPv4-Adresse.

neelix8200:

6: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether a8:b8:e0:03:fe:91 brd ff:ff:ff:ff:ff:ff
    inet 192.168.13.250/24 scope global vmbr0
       valid_lft forever preferred_lft forever
    inet6 fe80::aab8:e0ff:fe03:fe91/64 scope link
       valid_lft forever preferred_lft forever

Und wenn ich mir deine vmbr0 ansehe, dann hat dir nur eine Link-Local-Adresse, weil sie eben weder per DHCPv6 noch per SLAAC was zugewiesen bekommt.

neelix8200 · 5. Januar 2025 um 18:05

Also wie ich festgestellt habe, funktioniert IPv6 im OPT-Netz problemlos. Nur im LAN nicht.
Beide Interfaces sind aber gleich konfiguriert, daher mein Gedanke, dass die Bridge mit dem VLAN-Trunk zum externen Switch irgendwie durcheinander kommt.