Messages

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.

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

Was schreib ich da beispielsweise rein?

Ich hatte hier 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).

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.

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.

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

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.

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.

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?

[e9]

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?

Addendum:
Under "Access," none of the buttons in any of the suboptions can be used anymore.
The same applies to "Miscellaneous" -> "SYSLOG destinations," as well as in the "HTTP(S)" tab, all submenus from "Cache path" downwards.

In the Nginx configuration under "HTTP(S)" -> "Security headers," the web interface appears to be defective.

When creating a new security header or editing an existing one, the "Cancel" or "Save" buttons that are normally present are missing from all tabs.


The tabs "Script," "Image," "Stylesheet," "Medium," "Frame," "Font," "WebSockets," "Worker," and "Form" cannot be accessed at all.


Tested under OPNsense Business 25.10.2 (amd64) and OPNsense 26.1.2_5 (amd64) with both the Edge browser (145.0.3800.70, 64-bit) and Firefox ESR (140.7.1esr, 64-bit).

That fixes it for now:
https://github.com/opnsense/plugins/pull/5184

After this adjustment, however, the "HTTP/3 (QUIC)" option had to be set for all HTTP servers, which was not a problem for me.

Hi,

I tried to enable http3/quic for my HTTP servers by checking the corresponding box in the nginx configuration.
This allowed me to determine that the following entries were added to nginx.conf:

Code Select Expand

listen 443 quic reuseport;
listen [::]:443 quic reuseport;
add_header Alt-Svc 'h3=":443"; ma=86400' always;
If http3/quic is then activated for another HTTP server, all these entries are also set for that server.
However, this then leads to the following error message:

Code Select Expand

nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
nginx: [emerg] duplicate listen options for 0.0.0.0:443 in /usr/local/etc/nginx/nginx.conf

Apparently, the reuseport option can only be used once:
https://stackoverflow.com/questions/76348128/enabling-quic-http-3-on-multiple-domains-with-nginx-1-25


How can http3/quic be enabled for additional HTTP servers without causing the error?

There was obviously something wrong with the configuration.

Unfortunately, even after intensive searching and reconfiguring, I couldn't find out exactly where the error was.


I have now reset OPNsense to version 24.7.10 and restored a configuration from 3 days ago.

nginx could then be started again. I then carried out the update to version 24.7.11_2 again.


Now everything works again.

Hi,


I have recently upgraded from OPNsense 24.7.10 to the current version 24.7.11_2.
No other changes were made to the nginx configuration.

Since a restart, the nginx service can no longer be started.

log says:

Code Select Expand

2024-12-20T10:44:37 Emergency nginx nginx: configuration file /usr/local/etc/nginx/nginx.conf test failed
2024-12-20T10:44:37 Emergency nginx nginx: [emerg] no "ssl_certificate" is defined for the "listen ... ssl" directive in /usr/local/etc/nginx/nginx.conf:8175
2024-12-20T10:44:36 Debug nginx NGINX setup routine started.
The nginx.conf looks like this from the mentioned line 8175 onwards_

Code Select Expand

server {

    listen 80 default_server;
    listen [::]:80 default_server;


    sendfile On;
    server_name  example.com;

    client_header_buffer_size 1k;
    large_client_header_buffers 4 8k;
    charset utf-8;
    access_log  /var/log/nginx/example.com.access.log main;
    access_log  /var/log/nginx/tls_handshake.log handshake;
    error_log  /var/log/nginx/example.com.error.log error;
    #include tls.conf;
    error_page 403 /opnsense_error_403.html;
    error_page 404 /opnsense_error_404.html;
    error_page 405 /waf_denied.html;
    error_page 500 501 502 503 504 /opnsense_server_error.html;

    location = /opnsense_error_403.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_error_404.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    location = /opnsense_server_error.html {
        internal;
        root /usr/local/etc/nginx/views;
    }
    # location to ban the host permanently
    set $naxsi_extensive_log 0;
    location @permanentban {
        access_log /var/log/nginx/permanentban.access.log main;
        internal;
        add_header "Content-Type" "text/plain; charset=UTF-8" always;
        return 403 "You got banned permanently from this server.";
    }
    error_page 418 = @permanentban;
    location = /waf_denied.html {
        root /usr/local/etc/nginx/views;
        access_log /var/log/nginx/waf_denied.access.log main;
    }
    location ^~ /.well-known/acme-challenge/ {
        default_type "text/plain";
        proxy_pass http://127.0.0.1:43580;
    }
    # block based on User Agents defined in global http settings
    if ($http_user_agent ~* Python-urllib|Nmap|python-requests|libwww-perl|MJ12bot|Jorgee|fasthttp|libwww|Telesphoreo|A6-Indexer|ltx71|okhttp|ZmEu|sqlmap|LMAO/2.0|l9explore|l9tcpid|Masscan|zgrab|Ronin/2.0|Hakai/2.0|Indy\sLibrary|^Mozilla/[\d\.]+$|Morfeus\sFucking\sScanner|MSIE\s[0-6]\.\d+) {
        return 418;
    }
    location /opnsense-auth-request {
      internal;
      fastcgi_pass  unix:/var/run/php-webgui.socket;
      fastcgi_index index.php;
      fastcgi_param TLS-Cipher $ssl_cipher;
      fastcgi_param TLS-Protocol $ssl_protocol;
      fastcgi_param TLS-SNI-Host $ssl_server_name;
      fastcgi_param Original-URI $request_uri;
      fastcgi_param Original-HOST $host;
      fastcgi_param SERVER-UUID "337026df-317a-49d2-9526-172c5b38bcc4";
      fastcgi_param SCRIPT_FILENAME  /usr/local/opnsense/scripts/nginx/ngx_auth.php;
      fastcgi_param AUTH_SERVER "Local Database";
      fastcgi_intercept_errors on;
      include        fastcgi_params;
    }
    include 337026df-317a-49d2-9526-172c5b38bcc4_pre/*.conf;


location  / {
    BasicRule wl:19;
    DeniedUrl "/waf_denied.html";
    if ($scheme != "https") {
        return 302 https://$host$request_uri;
    }
    autoindex off;
    proxy_set_header Host $host;
    proxy_set_header X-TLS-Cipher $ssl_cipher;
    proxy_set_header X-TLS-Protocol $ssl_protocol;
    proxy_set_header X-TLS-SNI-Host $ssl_server_name;
    # proxy headers for backend server
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header X-Forwarded-Port $server_port;
    proxy_set_header X-Forwarded-Host $host;
    proxy_set_header X-TLS-Client-Intercepted $tls_intercepted;
    proxy_read_timeout 3600s;
    proxy_send_timeout 3600s;
    proxy_ignore_client_abort off;
    proxy_request_buffering off;
    proxy_max_temp_file_size 1024m;
    proxy_buffering off;
    proxy_pass https://upstreamb7b7de2accac4d758e74637ac2fd5380;
    proxy_ssl_server_name off;
    proxy_ssl_protocols TLSv1.2 TLSv1.3;
    proxy_ssl_session_reuse off;
    proxy_ssl_trusted_certificate /usr/local/etc/nginx/key/trust_upstream_b7b7de2a-ccac-4d75-8e74-637ac2fd5380.pem;
    proxy_ssl_verify off;
    proxy_ssl_verify_depth 1;
    proxy_store off;
    proxy_hide_header X-Powered-By;
    include 0b649b16-f937-41e3-8518-27b394057e1a_post/*.conf;
}
    include 337026df-317a-49d2-9526-172c5b38bcc4_post/*.conf;

Where is the mistake here?

Thank you for your assessment.
I see from this that it should obviously not be done with a small adjustment to the configuration.
That actually sounds very advanced to me.

What should be done to warm up the servers after the nginx start?

I had originally activated the function to have maximum security.
So would you recommend deactivating ocsp must staple instead?