Öffentlicher IPv6-Suffix ändert sich sporadisch

[psychofaktory]

Hallo,

beim WAN-Anschluss meiner OPNsense (26.1.6_2-amd64) ändert sich trotz fester IP sporadisch die Adresse und ich kann mir nicht erklären wieso.

Folgende Ausgangslage:

• Telekom Business DSL mit fester IP (DualStack)
• feste IPv6-Adresse laut Telekom-Kundencenter: 2003:xxxx:xx7f:b9ae:0000:0000:0000:0000
• MAC-Adresse des physikalischen Ethernet-Ports des WAN-Anschlusses igb0_vlan7 (PPPoE via VLAN7): a0:36:9f:21:80:e9
• MAC-Adresse des physikalischen Ethernet-Ports des LAN-Anschlusses igb1: a0:36:9f:21:80:ea

Aus dem festen IPv6-Präfix vom Provider und der MAC-Adresse sollte nach meinem Verständnis nun eine Adresse nach dem EUI-64-Format gebildet werden:
2003:xxxx:xx7f:b9ae:a236:9fff:fe21:80e9

Das funktioniert auch.
Jedoch wird ändert sich genau diese Adresse unregelmäßig sporadisch zu 2003:xxxx:xx7f:b9ae:a236:9fff:fe21:80ea; also der EUI-Adresse die zum LAN-Anschluss passend wäre.

Wie kommt das und wie kann ich das verhindern?

[mooh]

Deutsche Telekom usually hands out a static public address for your router plus a prefix. The public address is not from the prefix range. Maybe you can show how exactly the WAN interface is configured?

Upps, falsche Sprache: Die Telekom gibt normalerweise öffentliche Adressen für den Router aus und ein Präfix für. Dies Routeradresse ist nicht aus dem Präfix. Vielleicht zeigst Du mal die geneue Konfiguration des WAN Interface?

[psychofaktory]

Die Telekom gibt bei Aktivierung der festen IP-Adresse mehrere IPv6-Subnetze vor.
Einmal "Öffentlich/WAN": Diese wäre hier 2003:xxxx:xx7f:b9ae:0000:0000:0000:0000
Und dann "Kundennetz/LAN): hier 2003:xxxx:xx39:ae00:0000:0000:0000:0000

Bei meiner OPNsense ist seit jeher ein VLAN7 auf dem WAN-Interface (hier igb0) angelegt. Damit verknüpft sind die PPPoE-Einwahldaten.
Die Konfiguration des WAN-Interface sieht dann wie im Screenshot aus:
You cannot view this attachment.


Die IPv6 Adresse des WAN-Inferfaces wird dann automatisch aus der von der Telekom vorgegebenen WAN-Subnetz sowie der MAC-Adresse nach dem EUI-64-Format generiert.
Die LAN-/VLAN-Schnittstellen stehen dann jeweils bei IPv6 auf "Track Interface" mit "WAN" als übergeordnete Schnittstelle. Diesen IPv6-Adressen dieser Schnittstellen werden dann aus der von der Telekom vorgegebenen LAN-Subnetz, einer von mir für jedes Subnetz vorgegebene Präfix-ID, sowie der MAC-Adresse der LAN-Schnittstelle (hier igb1) nach dem EUI-64-Format generiert.

Bei den LAN-Schnittstellen funktioniert das auch wunderbar und die Adressen bleiben gleich.
Nur beim WAN wechselt der aus der MAC-Adresse generierte Anteil immer wieder zwischen der MAC von igb0 und igb1.




Ich habe mir das nun auch nochmal bei anderen Instanzen (alle bei der Deutschen Telekom), und konnte jeweils ein ähnliches Muster erkennen.

OPNsense 2:
WAN-Interface: igb1
EUI-64-Adresse mit MAC von igb0

OPNsense 3 (keine feste IP):
WAN-Interface: igb1_vlan7
EUI-64-Adresse mit MAC von igb0

OPNsense 4 (Business):
WAN-Interface: igb1_vlan7
EUI-64-Adresse mit MAC von igb2

Allerdings kann ich bei diesen Maschinen nicht beurteilen ob die Adresse sich ebenfalls sporadisch ändert.

Welche Logik steckt hier dahinter?

[drosophila]

Das kommt mir irgendwie vor als könnte es sich nicht entscheiden, welches Interface das Richtige ist. Ist das eine komplett neue Konfiguration, oder wurden da evtl. mal die Interface-Assignments getauscht, so dass nun in einer aktuell nicht sichtbaren Konfigurationsstelle das falsche Interface steht, so dass es eine Race-Condition gibt? Kann man z.B. mal die beiden Interface-Assignments zwischen LAN und WAN tauschen (und natürlich die Kabel umstöpseln), um zu sehen, ob das Problem dann auch auftritt?

[Maurice]

Das wird an PPPoE liegen. Die WAN-Adresse wird ja nicht an igb0_vlan7 gebunden, sondern an pppoe0. Und ein PPP-Interface hat keine MAC-Adresse. Welche MAC-Adresse dann für EUI-64 verwendet wird scheint mehr oder weniger random zu sein.

Gib in der DHCPv6-Clientkonfiguration einfach eine "optionale Schnittstellen-ID" ein, dann wird diese verwendet (statt EUI-64).

[edit]
Bin mir gerade nicht mehr sicher, ob die optionale Schnittstellen-ID auch für SLAAC funktioniert (was hier auf dem WAN-Interface verwendet wird) oder nur für Interface Association / Track Interface. Ausprobieren.
[/edit]

Grüße
Maurice

[mooh]

Ich bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".

Wenn sich die IPv6 ändert, brechen dann auch Verbindungen ab?

[psychofaktory]

Das kommt mir irgendwie vor als könnte es sich nicht entscheiden, welches Interface das Richtige ist. Ist das eine komplett neue Konfiguration, oder wurden da evtl. mal die Interface-Assignments getauscht, so dass nun in einer aktuell nicht sichtbaren Konfigurationsstelle das falsche Interface steht, so dass es eine Race-Condition gibt? Kann man z.B. mal die beiden Interface-Assignments zwischen LAN und WAN tauschen (und natürlich die Kabel umstöpseln), um zu sehen, ob das Problem dann auch auftritt?

Instanz 3 ist eine neue Konfiguration. Die oben beschriebenen Instanzen 1, 2 und 4 sind schon älter und wurden immer wieder aktualisiert.
Die Zuweisung der Interfaces wurde lediglich (bereits vor Jahren) bei Instanz 1 geändert. Ich wäre jetzt nicht davon ausgegangen, dass hier ein Zusammenhang besteht.

Das wird an PPPoE liegen. Die WAN-Adresse wird ja nicht an igb0_vlan7 gebunden, sondern an pppoe0. Und ein PPP-Interface hat keine MAC-Adresse. Welche MAC-Adresse dann für EUI-64 verwendet wird scheint mehr oder weniger random zu sein.

Sollte das dann nicht an das zugrundeliegende Interface gekoppelt sein, oder zumindest statisch bleiben?

Gib in der DHCPv6-Clientkonfiguration einfach eine "optionale Schnittstellen-ID" ein, dann wird diese verwendet (statt EUI-64).

[edit]
Bin mir gerade nicht mehr sicher, ob die optionale Schnittstellen-ID auch für SLAAC funktioniert (was hier auf dem WAN-Interface verwendet wird) oder nur für Interface Association / Track Interface. Ausprobieren.
[/edit]

Nein, das manuelle setzen der Schnittstellen-ID hat leider nicht funktioniert. Es wird immer wieder die EUI-64 verwendet. Nach wie vor vom falschen Interface.

Wenn sich die IPv6 ändert, brechen dann auch Verbindungen ab?

Das kann ich leider nicht beurteilen. Der letzte Wechsel lag jetzt eine ganze Weile zurück. Durch meine Tests eben hat sich die EUI-64 nun wieder zurück auf das korrekte Interface geändert. Dabei hatte ich die Schnittstelle aber auch manuell neu geladen.
Ein Muster lässt sich aber daraus nicht ableiten, da ich die Schnittstelle zuvor auch schon neu geladen hatte, ohne dass die Adresse sich geändert hatte.

[mooh]

Ich glaube der spannende Teil ist die Sache mit der GUA während "nur Präfix" + DHCPv6 für das WAN aktiviert sind. Das passt nicht zusammen. Das WAN Interface sollte eine Adresse der Art "fe80::<EUI-64>%pppoe0/64" haben.

Ist bei den Routern mal von statischer IPv6 Konfig auf DHCPv6 umgestellt worden? Kann da was durcheinander gegangen sein?

[Maurice]

Ich bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".

Die Konfiguration bezieht sich nur auf DHCPv6. Die RAs der Telekom enthalten aber zusätzlich ein /64 mit A-Flag, weshalb das WAN-Interface eine per SLAAC autokonfigurierte Adresse bekommt. Das ist völlig unabhängig von DHCPv6. Es gibt in OPNsense leider keine einfache Möglichkeit, SLAAC zu deaktivieren.

Sollte das dann nicht an das zugrundeliegende Interface gekoppelt sein, oder zumindest statisch bleiben?

Das wäre aus User-Sicht sicherlich sinnvoll. Wie genau SLAAC auf PPP-Interfaces in FreeBSD / OPNsense implementiert ist habe ich gerade nicht im Kopf. Ggfs. ein Issue auf GitHub aufmachen.

Nein, das manuelle setzen der Schnittstellen-ID hat leider nicht funktioniert. Es wird immer wieder die EUI-64 verwendet. Nach wie vor vom falschen Interface.

Dann bezieht sich das nur auf Track Interface bzw. Interface Association und nicht auf SLAAC. Eigentlich auch logisch. SLAAC passiert soweit ich mich erinnere im Kernel, da hat OPNsense wahrscheinlich wenig Einfluss drauf.

[psychofaktory]

Ich bin mir nicht ganz sicher warum auf dem WAN Interface überhaupt eine GUA auftaucht. In der Konfiguration steht doch "nur Präfix anfordern".

Die Konfiguration bezieht sich nur auf DHCPv6. Die RAs der Telekom enthalten aber zusätzlich ein /64 mit A-Flag, weshalb das WAN-Interface eine per SLAAC autokonfigurierte Adresse bekommt. Das ist völlig unabhängig von DHCPv6. Es gibt in OPNsense leider keine einfache Möglichkeit, SLAAC zu deaktivieren.

Vielen Dank für die ausführliche Erläuterung zum technischen Hintergrund.


Aktuell werden mir in der Schnittstellen-Übersicht für das WAN-Interface diese IPv6-Adressen angezeigt:

• addr6:

fe80::a236:9fff:fe21:80e9%pppoe0/64

• IPv6-Adressen:
  2003:xxxx:xx7f:b9ae:a236:9fff:fe21:80e9
   fe80::a236:9fff:fe21:80e9/64

Bei dem Wechsel - der nicht passieren sollte - ändert sich das dann zu:

• addr6:
  fe80::a236:9fff:fe21:80ea%pppoe0/64
• IPv6-Adressen:
  2003:xxxx:xx7f:b9ae:a236:9fff:fe21:80ea
   fe80::a236:9fff:fe21:80ea/64

Es wundert mich, dass dieses Problem bisher offenbar noch niemandem aufgefallen ist.
Oder bin ich etwa der einzige der davon betroffen ist?
Dann wäre es interessant zu wissen was meine Konstellation von anderen mit gleichen Voraussetzungen unterscheidet.

[Patrick M. Hausen]

Ihr habt mich jetzt neugierig gemacht. Ich hab ein Deciso-Gerät mit Schnittstellen ax0, ax1 (10G) und igb0-2 (1G). Für den Uplink benutze ich igb0 ohne VLAN 7 - das macht bei mir das Modem.

Die MAC-Adressen enden folgendermaßen:

Code Select Expand

igb0: ...:67
igb0: ...:68
igb0: ...:69
 ax0: ...:6a
 ax1: ...:6b

IPv6-Adresse auf pppoe0: ...:6a.

Das hat sich aber noch nie geändert. Ich hab einen AAAA-Record für den Caddy, der ein Dutzend Dienste darüber anbietet. Trotzdem komisch, dass der mpd5 die MAC vom ax0 nimmt und nicht die vom igb0.

Grüße
Patrick