Ö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

[psychofaktory]

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.

Das wundert mich eben auch. Dem Beitrag hier nach sollte die MAC des WAN-Interfaces verwendet werden. Nach meinem Verständnis unabhängig davon ob VLAN7 verwendet wird oder nicht.
Dem Beitrag nach sollte allerdings auch die Optionale Schnittstellen-ID gesetzt werden können. 
Ist das evtl. eine Besonderheit bei Telekom-Anschlüssen das hier etwas anders gehandhabt wird?
Setzen der Schnittstellen-ID, Speichern, Anwenden und neu laden der Schnittstelle über die Schnittstellenübersicht sollte doch ausreichen um die Änderung wirksam werden zu lassen, oder?

Ich habe hier übrigens auch Deciso-Hardware am Start bei denen eben nicht die MAC des WAN-Interface genutzt wird.
Oben beschriebene OPNsense 3 ist eine DEC740 (an einem VDSL-Anschluss der Telekom), und OPNsense 4 ist eine DEC3840 (an einem Glasfaseranschluss der Telekom).

[Patrick M. Hausen]

Dem Beitrag hier nach sollte die MAC des WAN-Interfaces verwendet werden. Nach meinem Verständnis unabhängig davon ob VLAN7 verwendet wird oder nicht.
Dem Beitrag nach sollte allerdings auch die Optionale Schnittstellen-ID gesetzt werden können.

Ich bin mir nicht sicher, ob der Uwe (@meyergru) das mit der MAC wirklich zu 100% verifiziert hat.

Ich hab allerdings auch nicht "request prefix only" aktiviert. Und du anscheinend auch nicht. Sonst hätte man ja keine GUA auf WAN/pppoe0. Und ich möchte da gerne eine für den Reverse Proxy, und auch, damit ausgehend IPv6 einfach stressfrei läuft. Da hab ich eine andere Vorstellung als er.

Ist das evtl. eine Besonderheit bei Telekom-Anschlüssen das hier etwas anders gehandhabt wird?

Kann nicht sein. Der mpd5 sucht sich aus, mit welcher MAC-Adresse gearbeitet wird. Das passiert alles client-seitig. Die Gegenstelle der PPPoE-Session kann deine ganzen MAC-Adressen gar nicht wissen.

Man müsste mal in den Source vom mpd5 gucken. Vielleicht nimmt er "das erste Interface" auf dem Host und je nach dem ist das nicht immer dasselbe?

[psychofaktory]

Ich hab allerdings auch nicht "request prefix only" aktiviert. Und du anscheinend auch nicht. Sonst hätte man ja keine GUA auf WAN/pppoe0. Und ich möchte da gerne eine für den Reverse Proxy, und auch, damit ausgehend IPv6 einfach stressfrei läuft. Da hab ich eine andere Vorstellung als er.

Doch, "Nur Präfix anfordern" ist bei allen genannten Instanzen aktiv. Genau so wie im Screenshot oben ersichtlich.
Mein Nutzungsszenario ist ähnlich. Über verschiedene AAAA-Records werden über einen NGinx-ReverseProxy verschiedene Dienste bereitgestellt. Ändert sich IPv6-Adresse laufen die Records natürlich ins Leere. Das habe ich auch schon mittels DynDNS in Verbindung mit einem Cronjob abgefangen. Aber das ist natürlich auch nur eine Krücke.

Vielleicht nimmt er "das erste Interface" auf dem Host und je nach dem ist das nicht immer dasselbe?

Das klingt schlüssig. Allerdings auch fehleranfällig. Merkwürdig auch, dass das im laufenden Betrieb wechselt.

[Patrick M. Hausen]

Also der mpd5 bastelt sich im IPv6CP eine MAC-Adresse durch Aufruf der Funktion GetEther():

https://sourceforge.net/p/mpd/svn/HEAD/tree/trunk/src/ipv6cp.c#l157

Code Select Expand

/*
 * CreateInterfaceID()
 */

void
CreateInterfaceID(u_char *intid, int r)
{
    struct sockaddr_dl hwaddr;
    u_char *ether;

    if (!r) {
if (!GetEther(NULL, &hwaddr)) {
    ether = (u_char *) LLADDR(&hwaddr);
    intid[0]=ether[0] ^ 0x02; /* reverse the u/l bit*/
    intid[1]=ether[1];
    intid[2]=ether[2];
    intid[3]=0xff;
    intid[4]=0xfe;
    intid[5]=ether[3];
    intid[6]=ether[4];
    intid[7]=ether[5];
    return;
}
    }

    srandomdev();
    ((u_int32_t*)(void*)intid)[0]=(((u_int32_t)random()) % 0xFFFFFFFF) + 1;
    ((u_int32_t*)(void*)intid)[1]=(((u_int32_t)random()) % 0xFFFFFFFF) + 1;
    intid[0] &= 0xfd;

}

Er versucht, sich eine von einem lokalen Interface zu holen, und wenn das nicht klappt, dann würfelt er eine. Er ruft GetEther() allerdings mit "NULL" im ersten Parameter auf. Das führt dazu, dass in GetEther():

https://sourceforge.net/p/mpd/svn/HEAD/tree/trunk/src/util.c#l1259

Code Select Expand

/*
 * GetEther()
 *
 * Get the hardware address of an interface on the the same subnet as addr.
 * If addr == NULL, finds the address of any local ethernet interface.
 */

int
GetEther(struct u_addr *addr, struct sockaddr_dl *hwaddr)
{
[...]

"irgendein" Interface benutzt wird. Das ist bei IPv6 im Moment so fix implementiert und das könnte OPNsense auch nicht per Konfiguration ändern.