Messages

Das funktioniert innerhalb eines Subnetzes ganz gut, aber ich habe verschiedene Teilnetze, die verschiedene weitergerecihte /64-Prefixe haben.
Wenn ich nun den DNS-Server per ULA abspreche, dann funktioniert das aus dem einen Teilnetz wunderbar, aber die anderen bekommen einen Eintrag, der per IPv6-Vorgaben nicht über einen Router geroutet werden.

Gibt es hier eine Möglichkeit, eine lokale IPv6 routen zu lassen?

Hallo.

Ich betreibe eine OPNsense als interne FW hinter dem DSL-Router.
Im internen Netz arbeitet eine MS-AD auf Univention. Diese benötigt eine DNS-Auflösung, damit die CLients die Server finden.
Mit ipv4 ist die Konfiguration ohne Probleme machbar und läuft problemlos. Routing zwischen den Teilnetzen sowie die Verteilung der IPs.
Ich benötige aber IPv6-Zugriff der Clients. Damit diese korrekt die Server auflösen, muss der AD-Controller als DNSv6 per IPv6 über DHCPv6 bekannt gegeben werden, da der Router per RA nicht die korrekte Auflösung hinbekommt. [Bitte nicht als Lösung: Dann trage die DNS-Records doch in die OPNsense]

Ich erhalte vom ISP (Telekom) ein /56 prefix, dass korrekt weitergereicht wird. Die Verteilung der IPv6 auf die Clients und die Server stimmt. Diese haben auch eine korrekte IPv6-local (im jeweiligen Netz auch ansprechbar), aber lassen sich darüber nicht auflösen, da sich Server und Clients nicht im selben subnet befinden. Die Router routen keine IPv6-local.

Wie kann ich dem DHCPv6 auf der OPNsense beibringen, dass der das zugewiesene Prefix vor dem UID des Rechners setzen soll, bevor er die Leases verteilt?

Ich hoffe, ich konnte den Rahmen genug beschreiben.

Vielen Dank
Patrick

Ich habe den entsprechenden Hacken (Disable web GUI redirect rule) bereits mehrfach gesetzt und wieder herausgenommen.
Der Fehler lässt sich reproduzierbar wiederholen.
Sobald ich auf https umstelle, wird immer wieder derselbe Fehler (siehe oben) erzeugt und der lighttpd akzeptiert keine Verbindungen, weder per http noch per https, obwohl auf beiden Ports per curl eine Antwort erscheint.

Der Lighttpd aktualisierte sich über Nacht. Danach trat derselbe Effekt auf.
Ein erneuter Revert brachte die Lösung.
Ich habe nun den Login per https deaktiviert. Das kann aber nicht die Lösung sein.
Welches Problem tritt denn hier auf?
Ich verwende kein lets encrypt,nur eine selfsigned CA.

Thanks for the revert command.
All works fine again.

Hallo zusammen,

nach dem Update auf 20.7.7_1 ist die Webgui nicht mehr erreichbar. Im Browser erscheint nur noch die Fehlermeldung SSL_ERROR_INTERNAL_ERROR_ALERT

Auf der Shell der OPNsense war kurz ein Fehler im lighttpd erkennbar, der beim Start nicht mehr auftaucht. Nun lässt sich aber im Log (/var/log/lighttpd.log) folgender Fehler erkennen:
(mod_openssl.c.1088) SSL: building cert chain for TLS server name 192.168.0.1: error:00000000:lib(0):func(0):reason(0)
(mod_openssl.c.3089) SSL: 1 error:1417A179:SSL routines:tls_post_process_client_hello:cert cb error

Ich habe nach ähnlichen Fehlern gesucht und dabei noch auf die Ausgabe der folgenden Befehle gestoßen:


Die Webgui hat einen Refer auf https, daher kann ich die Webgui auch nicht mehr ohne https erreichen.
Wie kann ich diese Umleitung in der Shell abschalten?

Vielen Dank
Paddi