OPNsense Forum

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?

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?

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:
Konfiguration_WAN-Interface.png


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?

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?

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

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?

Quote from: drosophila on May 03, 2026, 03:25:08 AMDas 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.

Quote from: Maurice on May 03, 2026, 12:59:43 PMDas 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?

Quote from: Maurice on May 03, 2026, 12:59:43 PMGib 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.

Quote from: mooh on May 04, 2026, 01:05:28 PMWenn 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.

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?

Quote from: mooh on May 04, 2026, 01:05:28 PMIch 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.

Quote from: psychofaktory on May 04, 2026, 01:56:12 PMSollte 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.

Quote from: psychofaktory on May 04, 2026, 01:56:12 PMNein, 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.

Quote from: Maurice on May 04, 2026, 06:27:48 PM

Quote from: mooh on May 04, 2026, 01:05:28 PMIch 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.

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:

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

Quote from: Patrick M. Hausen on May 04, 2026, 08:55:14 PMDas 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 (https://forum.opnsense.org/index.php?topic=45822.0) 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).

Quote from: psychofaktory on May 04, 2026, 09:08:31 PMDem 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.

Quote from: psychofaktory on May 04, 2026, 09:08:31 PMIst 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?

Quote from: Patrick M. Hausen on May 04, 2026, 09:22:24 PMIch 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.

Quote from: Patrick M. Hausen on May 04, 2026, 09:22:24 PMVielleicht 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.

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
/*
 * 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

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

Quote from: psychofaktory on May 04, 2026, 09:35:40 PMDoch, "Nur Präfix anfordern" ist bei allen genannten Instanzen aktiv. Genau so wie im Screenshot oben ersichtlich.

Wurde ja schon erklärt, dass das eine SLAAC-Adresse ist und mit DHCPv6 nichts zu tun hat.

Quote from: Bob.Dig on May 04, 2026, 09:53:28 PM

Quote from: psychofaktory on May 04, 2026, 09:35:40 PMDoch, "Nur Präfix anfordern" ist bei allen genannten Instanzen aktiv. Genau so wie im Screenshot oben ersichtlich.

Wurde ja schon erklärt, dass das eine SLAAC-Adresse ist und mit DHCPv6 nichts zu tun hat.

Danke für die Erinnerung. Hast Recht. Genau deshalb wird da ja auch eine EUI-64 rein verwurstet.

Ich denke, meine Code-Analyse stimmt trotzdem. Er nimmt sich "irgendeine" MAC von einem lokalen Interface und nimmt die für pppoe0. Auf manchen Systemen scheint "irgendeine" zumindest deterministisch über Reboots hinweg zu sein, auf manchen nicht so ganz.

Wenn man mit einem festen Prefix bei der DTAG eine stabile Adresse z.B. für Ingress haben will, und es einem irgendwie widerstrebt, dafür nun "LAN address" zu benutzen, dann kann man sich ja eine Adresse auswürfeln und die als VIP mit /128 auf lo0 legen. Einen Firewall-Alias und dann in der Regel auf WAN statt "from * to WAN address" eben "from * to MEIN_ALIAS" und gut ist. Die DTAG routet ja das ganze /56 über den Draht, ohne genauer hin zu gucken.

Letztlich braucht man eine deterministische Adresse ja meist für Ingress. Selbst, wenn man auf einem eigenen VPC irgendwo in einer Cloud z.B. SMTP freischalten will, kann man ja genau so gut das /64 nehmen. Oder IPv4. Also für Egress funktioniert's schon irgendwie, will ich damit sagen.

Muss ich morgen mal ausprobieren. Ich mag so "ist stabil, aber ich weiß nicht weshalb, und ob das so bleibt" Szenarien auch nicht.

Muhahaha!

Jetzt hab ich mal "Request prefix only" aktiviert und ich kriege immer noch eine GUA, mit EUI-64 drin, so weit sind wir ja inzwischen, und ... es ist die MAC vom igc0, über das auch die Session läuft.

Ich mach das mit der /128 auf lo0 ... :-)

Grüße
Patrick

Und die /var/etc/mpd_wan.conf ist mit und ohne "Request prefix only" vollkommen identisch! WTF?

OK, die Magie passiert in /usr/local/opnsense/scripts/interfaces/ppp-linkup.sh, das seinerseits /usr/local/opnsense/scripts/interfaces/ppp-ipv6.php aufruft.

Letzteres ist überschaubar, ich lass die Copyright-Boilerplate mal weg:

require_once 'config.inc';
require_once 'util.inc';
require_once 'system.inc';
require_once 'interfaces.inc';
require_once 'filter.inc';
require_once 'auth.inc';

if (empty($argv[1]) || empty($argv[2])) {
    exit(1);
}

$interface = convert_real_interface_to_friendly_interface_name($argv[1]);
$family = $argv[2];

if (empty($interface) || ($family != 4 && $family != 6)) {
    exit(1);
}

if (!interface_ppps_bound($interface, $family)) {
    exit(1);
}

switch (is_ipv6_allowed() ? ($config['interfaces'][$interface]['ipaddrv6'] ?? 'none') : 'none') {
    case 'dhcp6':
    case 'slaac':
        interface_dhcpv6_prepare($interface, $config['interfaces'][$interface]);
        interface_dhcpv6_configure($interface, $config['interfaces'][$interface]);
        /* signal this succeeded to avoid triggering a newwanip event right away */
        exit(0);
    default:
        interface_static6_configure($interface, $config['interfaces'][$interface]);
        system_routing_configure(false, $interface, true, 'inet6');
}

exit(1);

Das Flag "Request prefix only" im UI setzt einfach nur in der config.xml:

       <dhcp6prefixonly>1</dhcp6prefixonly>

Ich hab versucht, hinter die Logik zu steigen, muss hier aber abbrechen. Also alles in allem scheint der mpd5 doch deterministisch zu sein, der ist aber für das Aushandeln von IPv6 überhaupt nicht zuständig. Weshalb nicht? mpd5 kann doch IPv4 und IPv6 per PPPoE heißt es in der Doku. Trotzdem macht die OPNsense hier anscheinend alles selbst. Über mehrere PHP- und Shellscripts hinweg, die vom mpd5 getriggert werden.

Wahrscheinlich ist auch das Rätsel der stabilen EUI-64 dann irgendwo dort zu lösen.

"Request prefix only" ist eine Einstellung des DHCPv6-Clients und nicht PPP-spezifisch. Es geht nur darum, ob der dhcp6c auch IA_NA anfragt.
Bei der Telekom ist es völlig egal, ob man diese Option setzt oder nicht, denn per DHCPv6 bekommt man dort ausschließlich ein Präfix (IA_PD), keine Adresse (IA_NA). Für die Konfiguration der WAN-Adresse wird dort wie gesagt SLAAC verwendet.

Deine Analyse scheint dann mein Bauchgefühl zu bestätigen: Bei SLAAC auf PPP-Interfaces ist die für EUI-64 verwendete MAC-Adresse mehr oder weniger zufällig und OPNsense kann daran auch nichts ändern. Das ist natürlich unschön.

mpd5 kümmert sich nur um IPv6CP, nicht um DHCPv6 und Router Solicitation / SLAAC. Das läuft ganz normal über dhcp6c und rtsold.

Ich habe kein SLAAC und mein Provider kann überhaupt nur Prefix Only, deswegen kann ich nur bedingt mitreden.

Bevor @franco die Möglichkeit eingebaut hat, den Präfix auch für das WAN zu nutzen, war die ,,egress MAC" aufgrund des willkürlich gewählten LAN-Interfaces auch zufällig, weil das WAN gar keine GUA bekam.

Quote from: Maurice on May 05, 2026, 12:14:28 AMDeine Analyse scheint dann mein Bauchgefühl zu bestätigen: Bei SLAAC auf PPP-Interfaces ist die für EUI-64 verwendete MAC-Adresse mehr oder weniger zufällig und OPNsense kann daran auch nichts ändern. Das ist natürlich unschön.

Aber dieser Teil scheint m.E. komplett im Scope von OPNsense zu liegen. Daher denke ich, man könnte die auch konfigurierbar machen.

Ich werde erstmal eine neue GUA auf das lo0 werfen ...

Ich bin immer wieder begeistert wieviel ich von der Kompetenz hier im Forum lernen kann.
Das Thema scheint deutlich komplexer zu sein als ich dachte.

Ich konnte die GUA-Adresse nun zumindest schon mal über das Setzen einer optionalen Schnittstellen-ID fixieren.
Das hatte zuvor nicht funktioniert, weil zusätzlich auch eine optionale Präfix-ID angegeben sein muss. Der Haken bei "Nur Präfix anfordern" hat keinerlei Unterschied gemacht.
Wenn ich nun also als optionale Präfix-ID "0x1" angebe, und als optionale Schnittstellen-ID "0x337", dann siehts bei meiner Schnittstellen-Übersicht für die WAN-Schnittstelle so aus:

• addr6:
   2003:xxxx:xx39:ae01::337/64

• IPv6-Adressen:
   2003:xxxx:xx39:ae01::337/64
   fe80::a236:9fff:fe21:80ea/64

Zur Erinnerung: So war es vorher:

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

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

Unter addr6 steht nun also eine GUA-Adresse.
Die GUA-Adresse wird nicht mehr aus dem öffentlichen Adressbereich der Telekom genommen, sondern dem für das Kundennetz.
Die fe80-Adresse ist weiterhin an die MAC-Adresse gebunden und unterliegt so weiterhin den sporadischen Veränderungen.


Langfristig ist meiner Ansicht nach eine saubere und zuverlässige Lösung nur möglich, wenn die Adresse zuverlässig aus der MAC-Adresse des zugewiesenen WAN-Interfaces generiert wird.
Bestenfalls mit der zusätzlichen Option das ganze manuell konfigurierbar zu machen.

Quote from: Maurice on May 05, 2026, 12:14:28 AM"Request prefix only" ist eine Einstellung des DHCPv6-Clients und nicht PPP-spezifisch. Es geht nur darum, ob der dhcp6c auch IA_NA anfragt.
Bei der Telekom ist es völlig egal, ob man diese Option setzt oder nicht, denn per DHCPv6 bekommt man dort ausschließlich ein Präfix (IA_PD), keine Adresse (IA_NA). Für die Konfiguration der WAN-Adresse wird dort wie gesagt SLAAC verwendet.

Ich höre Deine Worte, aber bei meiner OPNsense hat "Request prefix only" am Telekom Anschluss für Privatkunden, aber sonst gleicher Konfiguration wie der TO, genau die Auswirkung eben keine GUA zu bekommen, respektive eine zu bekommen, wenn nicht gesetzt. Könnte natürlich am Privat- vs Geschäftkundenanschluss liegen.

Und die EUI-64 ist auch von der MAC des Interfaces abgeleitet, über die die PPPoE Verbindung läuft.

Hab dasselbe Problem schon lange. Der letzte Teil meiner IPv6 wechselt bei Reboots ständig zwischen 9cfe und 9cf9. Nach jedem Reboot muss ich das Monitoring neu konfigurieren.

Das wundert mich wirklich. Mit Request Prefix Only und einem passenden Präfix und einer Interface ID kann man die GUA so festlegen, wie man will.

Mit einem festen Präfix am Businessanschluss müsste das sogar eine feste IP geben.

Bug oder Feature

Screenshot 2026-05-06 105127.png

Quote from: meyergru on May 06, 2026, 10:48:22 AMMit Request Prefix Only und einem passenden Präfix und einer Interface ID kann man die GUA so festlegen, wie man will.

Was schreib ich da beispielsweise rein?

Was Du willst. Im Zweifel 1. Es geht doch nur darum, eine feste EUI-64 zu haben. Da die Notation ein Integer ist, kannst Du das höchste Bit nicht setzen.

Ich nehme für die Interface ID oft eine zufällige Zahl, damit die nach Privacy Extensions aussieht.

Quote from: meyergru on May 06, 2026, 10:48:22 AMDas wundert mich wirklich. Mit Request Prefix Only und einem passenden Präfix und einer Interface ID kann man die GUA so festlegen, wie man will.

Mit einem festen Präfix am Businessanschluss müsste das sogar eine feste IP geben.

Ja, so habe ich es jetzt auch und somit am Business-Anschluss effektiv eine feste IP.

Aus Anwendersicht ist eben nur etwas unverständliche das:

• die ohne die Angabe der optionalen Präfix- und Schnittstellen-ID EUI-64-Adresse sich ändert, da die zugrundeliegende MAC quasi zufällig wechseln kann.
• auch mit gesetztem Haken bei "Request Prefix Only" und ohne Angabe der optionalen Präfix- und Schnittstellen-ID eine GUA bezogen wird - allerdings offenbar nur bei Geschäftskundenanschlüssen der Telekom; nicht bei privaten Anschlüssen.
• in der Konstellation die GUA nur dann selbst festgelegt werden kann, wenn neben der Interface-ID auch die optionale Präfix-ID angegeben wird.

[Edit]: Bei der hier beschriebenen (https://forum.opnsense.org/index.php?msg=266164) OpnSense 3 wird auch an einem Privatkundenanschluss der Telekom trotz Haken bei "Request Prefix Only" eine GUA bezogen. Teilweise dauert es nur ein wenig bis die Adresse angezeigt wird.

Quote from: Patrick M. Hausen on May 06, 2026, 11:08:25 AMWas schreib ich da beispielsweise rein?

Ich hatte hier (https://forum.opnsense.org/index.php?topic=51756.msg266411#msg266411) ein Beispiel dazu gemacht.
Aktuell habe ich bei Präfix "0" eingetragen, und bei Schnittstellen-ID die feste IPv4-Adresse (ohne Punkte und mit Nullen aufgefüllt).

Hab mal bei mir geschaut. Ich habe ein Failover LAGG im LAN. Aktuell hat das die MAC-Adresse ...9c:fe. Und meine GUA am pppoe0 ist momentan die ...:9cfe.

Also ändert sich bei mir immer wieder die MAC-Adresse des lagg0? Aber warum?