Messages

Das meinte ich nicht. Wenn deine Domain "meine.domain" ist, dann benutz die für extern erreichbare Services und das sowohl von innen als auch von außen. Aber benutz sie nicht als Domain für DHCP und schlimmstenfalls Active Directory (falls du eine Firma bist und sowas hast).

Dann bin ich beruhigt, denn das haben wir so.

Ich habe es nochmal so versucht wie Ihr es vorgeschlagen habt aber es hat leider nicht funktioniert. Die OPNSense lauscht jetzt auf Port :8443 und auch sonst sind die Optionen so gesetzt wie oben genannt. Allerdings konnte ich den (internen) Server (docker-Container) leider nicht mit gültigem LE-Cert erreichen. Es wurde immer das Cert des Containers verwendet.
Ich habe zwischendurch sogar mit einem A-Record auf die WAN-Adresse versucht um zu schauen, ob es daran liegt ... aber das hat nichts geändert.

Am Ende habe ich es dann so gemacht wie sonst: Das LE-Cert von der OPNSense auf den docker-Container kopiert und direkt dort eingebunden. Zusätzlich die Domain-Überschreibung auf der OPNSense auf die lokale IP wieder aktiviert. Immerhin läuft es jetzt; auch wenn das erneut der umständliche (und schlechtere) Weg ist. Aber wie auch immer: Besten Dank für's Mitdenken. Ich schaue mir in Kürze os-caddy an...

Ja, das kann sein -- bei der Ersteinrichtung des Servers stand damals genau diese Frage im Raum: Intern und extern den gleichen FQDN verwenden oder nicht. Leider waren wir da schlecht beraten und haben uns dafür entschieden.

Die Sache mit dem "transparent" schaue ich mir aber nochmal an -- vielleicht klappt's ja trotzdem noch

Du benutzt intern und extern dieselbe Domain? Mach das halt nicht ;-)

Dann ist *das* das Problem ... das kann ich leider nicht so einfach ändern.
Den Port der OPNSense werde ich aber noch auf :8443 oder sowas legen.

[nochmal]

Ja, das machte ich ja auch. Aber wie gesagt: wenn ich den Eintrag im Unbound deaktiviere, erhalte ich seltsamerweise das Zertifikat der Firewall. Wenn ich ihn aktiviere, wird natürlich auf die interne IP des Servers umgeleitet. Dann benötigt der Server aber leider nochmal zusätlich das richtige Zertfikat -- und genau auf diesen Schritt würde ich gerne verzichten. Vermutlich fehlt da nur eine Kleinigkeit...

Wenn du gleichzeitig über einen DynDNS-Anbieter dafür sorgst, dass der A-Record immer stimmt, dann natürlich.

Ok, vermutlich habe ich an dieser Stelle ein Brett vor dem Kopf. Bei uns ist es so, dass unser ISP keine feste IP anbieten kann und wir daher auf dyn-DNS-Anbieter angewiesen sind. Die Aktualisierung übernimmt die OPNSense über "Dienste: Dynamisches DNS: Einstellungen".
Und unter "Dienste: Unbound DNS: Überschreibungen"  kann ich dann doch keinen A-Record auf die WAN-Adresse einrichten, oder? Der ändert sich ja "ständig"...

Es ist ja eher im Gegenteil so, dass wir bei uns im Moment intern den "falschen Weg" gehen und im Unbound die Domain-Überschreibung für die Server nutzen, die auch intern von den Clients erreichbar sein sollen (daher auch das Problem mit dem zu kopierenden LE-Cert auf den Server).
Wenn ich das ändere, bekommt ein Client beim Zugriff auf eine interne Adresse aber nicht das richtige Zertifikat.
Irgendwie sehe ich den Wald vor lauter Bäumen nicht, fürchte ich!?

Super! Danke -- das versuche ich (hier Ubuntu Linux)

... leider klappt es nicht. Ich erhalte (sowohl unter Linux als auch direkt auf der OPNSense):

Code Select Expand

/usr/local/bin/openssl enc -d -aes-256-cbc -md sha512 -pbkdf2 -iter 100000 -in config-2024-12-26_01_39_07.xml
enter AES-256-CBC decryption password:
bad magic number

Vielleicht hätte ich dazu sagen sollen, dass ich die Datei auf ein Nextcloud-Share kopiere und dort die Option
"Verschlüsselungspasswort (optional) ______________" verwendet habe.

Der Header der Datei passt aber zu Deinem Befehl und das Passwort ist 100%ig korrekt.

Code Select Expand

---- BEGIN config.xml ----
Version: OPNsense 24.7.5_3
Cipher: AES-256-CBC
PBKDF2: 100000
Hash: SHA512
....


Also z.B. die Nextcloud heißt dann cloud.meinedomain.de - A und AAAA sind die WAN-Adresse meiner OPNsense und dort lauscht der Caddy und proxiet die Requests zum FreeBSD-Jail mit der Nextcloud.

Ok -- klappt das auch bei einer dynamischen WAN-Adresse?

Naja, die OPNsense webGUI sollte natürlich nicht am selben Port wie HAproxy lauschen.

Wo sehe ich das? Beim HAProxy finde ich keine Port-Einstellungen und das war bisher auch noch nie ein Problem.

Aber ich sehe schon: Ich sollte wirklich zum Caddy wechseln. Das scheint ja echt einfacher und übersichtlicher zu sein!

Hallo.
Kurze Frage:
Ich lasse nachts die config.xml als Backup verschlüsselt auf ein Share kopieren.

Nun würde ich gerne in eine ältere Version schauen -- allerdings möglichst ohne die aktuelle Konfiguration überschreiben zu müssen. Ich will nur einen alten Eintrag wiederfinden und mit der aktuellen Version vergleichen. Eigentlich also keine große Sache. Da die Datei auf dem Share aber verschlüsselt liegt, wüsste ich gerne, ob man die Datei auch auf der Konsole entschlüsseln kann, um sie wieder im Klartext vergleichen zu können?
Danke.

Oder einfach die DNS Overrides entfernen, so dass die Hostnamen auf die WAN-IP aufgelöst werden. Auf die lauscht HAproxy ohnehin, auch wenn die Anfragen von intern kommen.

Hi. Danke für den Hinweis.
Ok -- das müsste bereits so eingestellt sein. Wenn ich nun allerdings von intern auf https://webui.meine-domain.de gehe, wird immer das falsche Zertifikat der OPNSense selbst  ("firewall.meine-domain.de") verwendet. Da dürfte dann noch eine weitere Regel fehlen, die für diesen Fall das richtige LE-Zert auswählt, oder? Nur: Wo? (HAProxy ist leider unübersichtlich, finde ich)

[außen]

Hallo.
Ich frage mich schon länger, ob ich hier einen Denkfehler habe oder ob das ein "Designproblem" ist:

Wenn man auf der OPNSense z.B. HAProxy + ACME für die LE-Zertifikate verwendet, ist es ja problemlos möglich, dass die OPNSense die Zertifikate regelmäßig erneuert und man beim Zugriff von außen immer beim richtigen internen Server auf Port 443 landet. Der HAProxy wählt dann das richtige LE-Zertifikat und alles ist gut.

Wenn man das gleiche aber von einem internen Client im gleichen Subnetz versucht, bekommt man das LE-Zertifikat nicht, da der Traffic ja auch nicht über die OPNSense muss sondern ein direkter Zugriff über den nächsten Switch möglich ist.

Daher habe ich mir bisher immer so geholfen, dass ich die LE-Zertifikate von der OPNSense zusätzlich auf die einzelen Server kopiert habe, so dass dieses Problem auch beim internen Zugriff nicht mehr auftaucht.
Was mir aber nicht ganz klar ist: Ist das überhaupt sinnvoll so oder geht das auch eleganter/anders? Kann man also auf das Kopieren verzichten, wenn es anders macht? Oder ist das bei diesem Setup unvermeidlich?

Ich frage das auch deshalb, weil zunehmend docker-Container zum Einsatz kommen und es da manchmal nicht so einfach zu entscheiden ist, wie/wo man das LE-Zertifikat ablegen muss, damit der Zugriff auf Port 443 auch intern über https:// funktioniert...

Danke jedenfalls für einen guten Tipp.

Gut zu wissen ... vielleicht wäre das hier ein brauchbarer Weg (sofern man das auch auf andere Files also die "default-config.xml" loslassen kann)??!
https://docs.opnsense.org/manual/git-backup.html

Ok -- das erklärt es.
Man kann die Konfiguration aber im AdGuard-WebUI nirgendwo sichern, oder? Es muss also manuell über  /usr/local/AdGuardHome/ geschehen?

 

Hallo.
Leider ist bei uns das OPNSense-Update von Version 24.7.2 auf  24.7.11 schief gegangen. Das Update ist über angeblich fehlenden Config-Files gestolpert und ist letztlich hängengeblieben

Letztlich haben wir das System neu aufgesetzt und anschließend ein Backup der Konfiguration eingespielt. Das hat zwar funktioniert, doch leider waren die Konfigurations-Files vom AdGuardHome nicht dabei.
Ist das ein bekannter Fehler?
Es war auch so, dass die Erweiterung für das AdGuard-Paket (selbst hinzugefügt) offenbar nicht mit im Backup gespeichert wurde, so dass ich sie neu manuell hinzufügen musste.

Das sollte eigentlich so nicht sein, oder?

Ok - danke.
Das reicht mir als Info  ;)

Na ja .. die Daten in dem Video sind schon ganz interessant, fand ich.

Ab Minute 11:15 laufen beide als Reverse Proxy. Ob man auf solche Zugriffszahlen in der Realität kommt, kann ich nicht genau sagen.