Hallo Leute,
Ich suche jetzt schon Tage nach einer Lösung und komme einfach nicht dahinter, obwohl ich mir schon einige Videos usw. angesehen habe. Ich weiß auch nicht ob das eigentlich der richtige Weg ist da ich ja nichts darüber finde.
Ich möchte realisieren: Für alle meine internen Geräte ein Zertifikat mit dem ACME Client erstellen und über HAproxy verteilen.
(vorweg macht man das überhaupt so oder gibt's bessere Lösungen?)
Da ich für den Exchange2019 HAproxy + ACME Client eingestellt habe zwecks Zertifikate und das auch schon Jahre Top funktioniert wollte ich das auch für meine anderen WebGui/Geräte machen da dieses weck Klicksen lästig ist im Browser.
Für die OPNsense selbst einfach da braucht man kein HAproxy nur ACME Client und unter System-Einstellungen-Verwaltung das Zertifikat für die OPNsense angegeben und funktioniert auch sofort wenn ich ,,fw01.meineDomain.tld" aufrufe. Egal von welcher Schnittstelle ohne HAproxy -> okay passt denk ich mir.
So jetzt komme ich zum eigentlichen Problem wo ich keine lösung bis jetzt gefunden habe.
Wenn ich jetzt z.b für meine WebGui vom ,,mg01.meinDomain.tld" ein Zertifikat erstellen lasse und ich möchte das dies wie beim Exchange Server verwenden stosse ich auf das Problem das ich beim DC die DNS config so machen muss das ,,mg01" auf die externe IP zeigt wie bei ,,mail.meinedomain.tld" sonst erkennt das HAproxy nicht um das Zertifikat zu verwenden.
Das nächste problem kommt erst wenn ich das ganze für das NAS machen will da kann ich die externe nicht angeben da die ja in der AD hängt und die DNS Einträge selbst aktualisiert.
So jetzt würde ich eure Hilfe benötigen da ich irgendwie keine Ahnung/Idee habe wie ich das lösen könnte.
Quote from: MoChri on May 06, 2025, 03:29:02 PMIch möchte realisieren: Für alle meine internen Geräte ein Zertifikat mit dem ACME Client erstellen und über HAproxy verteilen.
(vorweg macht man das überhaupt so oder gibt's bessere Lösungen?)
Warum sollte man das machen, wenn man HAproxy hat.
Meiner Meinung die bessere Konfiguration ist, alle Zugriffe über HAproxy auf den Backends zu führen, auch von intern.
Auf der OPNsense besorgt der ACME Client öffentlich-gültige Zertifikate. Diese werden im HAproxy dem Public Service zugewiesen. Fertig.
Soll auch die Verbingung von HAproxy auf die Backends verschlüsselt werden, auf der OPNsense eine CA für interne Zertifikate erstellen und sehr langlebige Zertifikate damit generieren und diese auf den Backend-Servern installieren. Das könnte auch dasselbe für alle sein.
HAproxy kann dann per https zugreifen. Das Backend kann so konfiguriert werden, dass es die Zertifikate nicht überprüft. Also muss der CN nicht zur Domain passen. Auch müsste es zeitlich nicht gültig sein. Er kann es aber auch gegen eine angegebene CA überprüfen.
Grüße
Danke schon mal für die schnelle rückmeldung aber wie soll ich das jetzt verstehen?
HAproxy erstellt man zuerst den Tatsächlichen Server -> (Virtuelle) Backend-pool mit Frontend -> mit dem spreche ich eigentlich, wenn ich z.b. mg01.meinedomain.tld aufrufe.
Das geht aber nur weil ich im DNS Server die externe IP angegeben habe. Wie kann ich den Frontend den übergehen so das der haproxy das für die interne Geräte macht. Das ist ja gerade das was ich nicht kapiere.
Wenn du mir das näher erklären könntest bitte oder einen Link hast dazu wäre echt super.
Danke
Quote from: MoChri on May 06, 2025, 04:31:10 PMHAproxy erstellt man zuerst den Tatsächlichen Server -> (Virtuelle) Backend-pool mit Frontend -> mit dem spreche ich eigentlich, wenn ich z.b. mg01.meinedomain.tld aufrufe.
Das geht aber nur weil ich im DNS Server die externe IP angegeben habe. Wie kann ich den Frontend den übergehen so das der haproxy das für die interne Geräte macht.
Dafür ist nichts weiter nötig als den Zugriff auf die externe IP zu erlauben.
Du sollst also keine internen DNS Override für die Domains eingerichtet haben. Dann verbinden sich die Geräte auf die externe IP.
OPNsense ist vermutlich dein Standardgateway, also erhält es diese Anfragen. Dass die angefragte IP tatsächlich einem anderen Interface zugewiesen ist, als die Pakete ankommen, ist dabei egal.
Also erstens gibt es für den HAproxy Setup mal ein super Tutorial (https://forum.opnsense.org/index.php?topic=23339.0).
HAproxy ist zugegebenermassen schwieriger als Caddy, kann aber ein bisschen mehr. Auch dafür gibt es ein Tutorial (https://forum.opnsense.org/index.php?topic=38714.0).
Am Rande bemerkt würde ich aus gegebenem Anlass keine HTTP-01 Verifikation für von außen sichtbare Dienste mehr nutzen, sondern nur noch DNS-01. Die Gründe dafür sind hier (https://forum.opnsense.org/index.php?msg=236105) erklärt. Wenn man ACME-Zertifikate für Services nutzen will, die nicht von außen erreichbar sind, führt an DNS-01 ja sowieso nichts vorbei. Es vereinfacht auch vieles, weil man dann nur ein einziges Wildcard-Zertifikat für alle DNS-Namen in der Domain benötigt.
Quote from: meyergru on May 06, 2025, 08:12:18 PMAm Rande bemerkt würde ich aus gegebenem Anlass keine HTTP-01 Verifikation für von außen sichtbare Dienste mehr nutzen, sondern nur noch DNS-01.
Das setzt aber eine API voraus, die mit dem genutzten DNS zusammenarbeitet.
Also es empfiehlt sich das vorab zu überprüfen.
Ich hatte seinerzeit eigens das DNS zu einem vermeintlich unterstützten Provider migriert, natürlich in Handarbeit, um dann festzustellen, dass die verwendete API bereits seit einem halben Jahr nicht mehr funktioniert hatte. Angekündigt hatte der Provider die Änderung bereits ein Jahr zuvor.
Am Ende hatte ich Stunden für die DNS Migration, die ACME Konfiguration und das Troubleshooting aufgewendet und dann ein SAN Zertifikat bei einem Anbieter gekauft. War viel Aufwand für nichts.
Irgendwo einen günstigen Cloud-VPC mieten und die Distribution nach Wahl und acme-dns (https://github.com/joohoi/acme-dns) installieren.
Hab ich gemacht. Mit FreeBSD bei Vultr.
Interessant.
Das wäre dann allerdings ein Single point of failure, den ich mir lieber nicht in eine Produktivumgebung einbauen möchte.
Für den Hausgebrauch aber sicher nett.
Wieso? Der liegt bei einem Cloud-Anbieter in der Infrastruktur, die hoffentlich halbwegs verfügbar ist, und wird nur dann benötigt, wenn die Zertifikate entweder erstmalig ausgestellt oder später dann verlängert werden. Monitoring drauf, das piept, wenn er ausfällt, und gut.
Quote from: viragomann on May 06, 2025, 08:29:53 PMDas setzt aber eine API voraus, die mit dem genutzten DNS zusammenarbeitet.
Also es empfiehlt sich das vorab zu überprüfen.
Ich hatte seinerzeit eigens das DNS zu einem vermeintlich unterstützten Provider migriert, natürlich in Handarbeit, um dann festzustellen, dass die verwendete API bereits seit einem halben Jahr nicht mehr funktioniert hatte. Angekündigt hatte der Provider die Änderung bereits ein Jahr zuvor.
Am Ende hatte ich Stunden für die DNS Migration, die ACME Konfiguration und das Troubleshooting aufgewendet und dann ein SAN Zertifikat bei einem Anbieter gekauft. War viel Aufwand für nichts.
@viragomann: Nicht wirklich - im verlinkten Thread ist erklärt, dass es bei ACME dank DNS-Alias-Mode nur eine
einzige updatefähige Domain braucht, um ggf. mehrere mit DNS-01 zu bedienen. Angesichts der buchstäblich zig verschiedenen DNS-Update-Methoden in OpnSense sehe ich echt nicht, wo das Problem liegt. Um nur ein Beispiel zu nennen, ohne wirklich dafür werben zu wollen: Hetzner bietet eine eigene API, die unterstützt wird und bei denen eine .DE-Domain gerade mal 3,90€ im Jahr kostet - das ist mutmaßlich billiger als Dein SAN-Zertifikat, dem aktuelle Browser bald eh nicht mehr trauen, weil es zu lange läuft.
Und: die verwendete Domain für den DNS-Update kann, wie gesagt, auch eine ausschließlich für diesen Spezialzweck genutzte sein - die muss nicht einmal bei einem Hoster liegen, der das eventuell eben nicht kann. Man muss im DNS der Wildcard-Domains nur einen einzigen CNAME auf die updatefähige Domain eintragen... Patrick hat das gerade getan und es ist wirklich einfach. Er hat dafür keine zusötzliche Domain genutzt, sondern eine Sub-Domain auf einen Cloud-Host-DNS mit ACME-DNS delegiert.
Und was die Ausfallsicherheit angeht: Aktuell muss Du alle 90 Tage updaten. In baldiger Zukunft alle 30 Tage. Solange der Update also nicht monatelang ausfällt: kein Problem.
Quote from: meyergru on May 06, 2025, 08:49:17 PMMan muss im DNS der Wildcard-Domains nur einen einzigen CNAME auf die updatefähige Domain eintragen
Diesen Teil hatte ich bislang noch nicht verstanden. Ist das irgendwo ausführlicher erklärt?
Die DNS Challenge setzt ja einen TXT Eintrag in der Domain, für welche ein Wildcard-Zertifikat angefragt wird.
Also meine Domain: meineDomain.tld.
Der Zert-Aussteller sucht in tld nach dem zuständigen Nameserver und bekommt den von meinem DNS Provider. Diesen fragt er dann nach dem jeweiligen TXT Record in meineDomain.tld
Wie ein CNANE diesen überzeugen kann, einen anderen DNS Server abzufragen, ist mit nicht klar.
Jein ...
Du konfigurierst bei deinem normalen Provider einen festen CNAME Eintrag:
$ dig _acme-challenge.hausen.com
[...]
;; ANSWER SECTION:
_acme-challenge.hausen.com. 14400 IN CNAME 9fb3ffc1-e14e-4971-bf5f-ef679b0a4d36.acme.hausen.com.
Und dann konfigurierst du deinen ACME-Client so, dass er auf dem ACME-DNS-Server in der gezeigten Domain die TXT-Records einträgt.
Und natürlich kannst du auch
_acme-challenge.viragomann.de. IN CNAME 9fb3ffc1-e14e-4971-bf5f-ef679b0a4d36.acme.hausen.com.
anlegen. Und dann denselben ACME-DNS-Server für N Domains benutzen. Mit ein und demselben Account (das ist diese GUID für die Subdomain) oder mit jeweils einem eigenen, ganz wie du willst.
Daher braucht der Provider, wo du deine "echte" Domain hostest, gar kein API. Du hast einen API-fähigen Server für alle deine Domains.
P.S. Eine Feinheit natürlich noch: acme.hausen.com ist eine eigene Zone, mit A, AAAA und NS-Records. Und die zeigen alle auf diesen Cloud-VPC mit dem acme-dns Dienst.
Super! Danke. :-)
Habe in dem verlinkten Tread und auf Github schon weiter gelesen. Die Zone ist der Trick. Das sollte hinzubekommen sein.
Grüße
Indem Du den CNAME für _acme-challenge.domain.xy auf irgendeine DNS-Update-Domain, z.B. update.update-domain.xy richtest. Mach mal eine nslookup auf _acme-challenge.congenio.de. Wenn Du vom Ergebnis weiter schaust, wirst Du sehen, dass die DNS-Update-Domain _acme-challenge.name2ip.net andere Nameserver hat als die übergeordnete Haupt-Domain name2ip.net (die ist bei Hetzner). In der DNS-Update-Domain musst Du übrigens nicht unbedingt _acme-challenge.update-domain.xy verwenden, der Name ist beliebig.
Der ACME.SH DNS-Alias Mode kann automatisch die DNS-Update-Domain per DNS finden, weil er einfach _acme-challenge.domain.xy abfragt.
Ist alles auch hier (https://github.com/acmesh-official/acme.sh/wiki/DNS-alias-mode) erklärt. In OpnSense sagst Du dann nur "DNS Alias Mode" bei der DNS-01 Verifikation und alles funzt.
Vielleicht wäre auch dafür ein Tutorial angezeigt...
Danke für die ausführliche Erklärung.
Hab es verstanden und merke es mir vor für den Fall, dass wieder mal der Bedarf da ist. Das gekaufte SAN-Zertifikat läuft ja auch mal aus. :-)
Quote from: meyergru on May 06, 2025, 08:12:18 PMAlso erstens gibt es für den HAproxy Setup mal ein super Tutorial (https://forum.opnsense.org/index.php?topic=23339.0).
HAproxy ist zugegebenermassen schwieriger als Caddy, kann aber ein bisschen mehr. Auch dafür gibt es ein Tutorial (https://forum.opnsense.org/index.php?topic=38714.0).
Am Rande bemerkt würde ich aus gegebenem Anlass keine HTTP-01 Verifikation für von außen sichtbare Dienste mehr nutzen, sondern nur noch DNS-01. Die Gründe dafür sind hier (https://forum.opnsense.org/index.php?msg=236105) erklärt. Wenn man ACME-Zertifikate für Services nutzen will, die nicht von außen erreichbar sind, führt an DNS-01 ja sowieso nichts vorbei. Es vereinfacht auch vieles, weil man dann nur ein einziges Wildcard-Zertifikat für alle DNS-Namen in der Domain benötigt.
Die kenne ich schon alle und gibt noch viel mehr dazu was mir aber nicht die richtige Antwort/Erklärung bringt.
Ich habe ja OPNsense mit HAproxy + ACME für denn Exchangeserver laufen und der ist von aussen & intern erreichbar weil am externen Domainprovider der A, MX, SPF, DKIM, DMARC, usw. Eintrag gemacht wurde auf "mail.meindomain.tld" und intern habe ich bei meinem internen DNS Server auch die ext. IP für den A eintrag von "mail.meindomain.tld" eingestellt.
Der frontend von HAproxy hört auf die externe IP:443
Das ist für mich total verständlich und funktioniert ja auch super.
Nur habe ich mir Gedanken gemach, um das so lästige Wegklicken von dem Zertifikatfehlern hinzubekommen, müsste das ja auch nur für die Interne Geräte auch funktionieren. Ja da ist aber jetzt der hacken wo ich es nicht mehr verstehe!!
Ich habe ein Netzwerksegment 172.20.20.1/24 wo alle meine Geräte laufen -> Domaincontroller/DNS-Server/Netzwerkspeicher/Mail-Gateway/Audio-Server/Drucker/usw. was alle eine HTTPS Seite zur Bedienung und Konfiguration besitzen. Da möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.
Das ganze ohne das ich bei den Clienten ein Zertifikat hochladen muss da dies ja mein HAproxy übernehmen soll. Dies funktioniert ja auch beim Exchangeserver schon so nur da geht alles über die ext. IP wo der hacken ist! Da ich bei den Activ Directory Domaincontroller alle verbunden Geräte ja die Einträge selbst machen und das ist die interne IP z.b für nas.meinedomain.tld = 172.20.20.23.
Mein problem ist ich verstehe nicht wie ich OPNsense(HAproxy) einstellen muss das dies von intern funktioniert ohne das ich es über die externe IP mache.
Habe unter DHCPv4 keine DNS-Server & Domainname gesetzt
hätte bei Unbound DNS die Host Überschreibeung probiert mit HOST (*) Domain (meindomain.tld) auf die DNS-Server IP leider stürtz da Unbound DNS ab und kann es nicht mehr starten.
Quote from: MoChri on May 06, 2025, 11:06:29 PMDa möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.
Das geht genau dann, wenn
- du eine HAproxy-Konfiguration für NAS.meinedomain.tld hast - den Teil hast du im Griff
- auch intern NAS.meinedomain.tld auf die externe (!) IP-Adresse deiner OPNsense auflöst
Das ist die einzige mir bekannte Methode. Wenn du Split-DNS haben willst, dann geht das halt fundamental nicht. Klar soweit?
Ist dann natürlich die Frage, ob Browser zum Administrieren die einzige Verwendung von NAS.meinedomain.tld ist. Wenn du das auch für die SMB-Verbindungen benutzt anstelle von NAS.local oder \\NAS ... dann wird es schwierig.
Ich hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.
Quote from: Patrick M. Hausen on May 06, 2025, 11:24:31 PMQuote from: MoChri on May 06, 2025, 11:06:29 PMDa möchte ich jetzt, wenn ich intern von meinem PC am Browser z.b.:"NAS.meinedomain.tld" eingeben eine Zertifikatfehlerfreie verbindung haben.
Das geht genau dann, wenn
- du eine HAproxy-Konfiguration für NAS.meinedomain.tld hast - den Teil hast du im Griff
- auch intern NAS.meinedomain.tld auf die externe (!) IP-Adresse deiner OPNsense auflöst
Das ist die einzige mir bekannte Methode. Wenn du Split-DNS haben willst, dann geht das halt fundamental nicht. Klar soweit?
Ist dann natürlich die Frage, ob Browser zum Administrieren die einzige Verwendung von NAS.meinedomain.tld ist. Wenn du das auch für die SMB-Verbindungen benutzt anstelle von NAS.local oder \\NAS ... dann wird es schwierig.
Ich hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.
Danke für deine Antwort! Die hat es auf den Punkt gebracht das dies nicht so lösbar ist so wie ich das haben möchte daher findet man ja auch nichts im Internet dazu!
Jetzt muss und werde ich entweder deinen Weg einschlagen oder mit den Zertifikatfehlern leben müssen. :)
Quote from: MoChri on May 06, 2025, 11:59:26 PModer mit den Zertifikatfehlern leben müssen.
Bau dir deine eigene CA und importier die auf allen Desktops mit denen du arbeitest als vertrauenswürdig.
Von einer privaten CA signierte Zertifikate dürfen eine Laufzeit von etwa 2 Jahren plus 3 Monaten haben.
HTH,
Patrick
Quote from: Patrick M. Hausen on May 07, 2025, 12:10:14 AMQuote from: MoChri on May 06, 2025, 11:59:26 PModer mit den Zertifikatfehlern leben müssen.
Bau dir deine eigene CA und importier die auf allen Desktops mit denen du arbeitest als vertrauenswürdig.
Von einer privaten CA signierte Zertifikate dürfen eine Laufzeit von etwa 2 Jahren plus 3 Monaten haben.
HTH,
Patrick
Hallo Patrick,
Ja werde ich machen nur kurz noch eine Frage
Wo würdest du die machen? Auf der OPNsense oder am Domaincontoller installieren?
Gruss
Christian
Ich hab sie auf der OPNsense. Ich habe aber auch keinen DC :-)
Quote from: Patrick M. Hausen on May 06, 2025, 11:24:31 PMIch hab mich dagegen entschieden und hab auf der Sense eine CA mit 20 Jahren Laufzeit für eine interne Domain - foo.meinedomain.tld - und alle Geräte hier sind in dieser. Dann ein Wildcard-Zertifikat mit 2 Jahren Laufzeit und ich hab nur alle 2 Jahre Aufwand.
Patrick hat vollkommen korrekt die Methode für ACME-Zertifikate für "interne" Zertifikate beschrieben. Die hat zwei Nachteile:
1. Die Namen müssen eine TLD enthalten, sind also länger als eigene Zertifikate (xxx.localdomain).
2. Da die Zertifikate aktuell nur 90 Tage gelten und üblicherweise nach 60 Tagen verlängert werden, müssen sie normalerweise alle 60 Tage wieder auf die Endgeräte eingebracht werden. In Zukunft sollen diese Zertifikate übrigens nur noch maximal 10 Tage gelten - so will es das CA/Browser Forum (https://www.heise.de/news/47-Tage-CAs-und-Browserhersteller-beschliessen-kuerzere-Laufzeit-fuer-Zertifikate-10352867.html).
Die einzige Alternative zu 2 ist, eine zentrale Instanz (z.B. die OpnSense) ein Wildcard-Zertifikat ausstellen zu lassen und einen Reverse Proxy zu verwenden, der den Zugriff auf die internen Services macht. Ein Einbringen per SFTP o.ä. ist oft nicht möglich.
Ich mache es bisher genau wie Patrick: Ich habe meine eigene langlebige CA, deren Zertifikat ich auf meinen PCs einbringe und mit der ich die Zertifikate ausstelle. Das hat bis dato zwei Probleme:
1. 2020 wurde die maximale Gültigkeit von Zertifikaten begrenzt auf derzeit 397 Tage. Man kann heute also eigentlich keine Zertifikate mehr ausstellen, die lange laufen, was man aber für interne Services gern möchte.
2. Wildcard-Zertifikate werden ausschließlich bei CNs akzeptiert, die eine TLD aufweisen, also *.yyy.de, aber nicht *.yyy. Damit muss für jeden Service ein eigenes Zertifikat ausgestellt werden.
In naher Zukunft wird das nochmals schwieriger, weil auch die maximale Zertifikatsdauer auch für nicht-ACME-Zertifikate verkürzt werden soll, in Schritten bis auf 47 Tage (!).
Es gibt allerdings einen Trick, den Patrick nicht erwähnt hat: Die Gültigkeitsregeln gelten nicht für bereits ausgestellte Zertifikate.
Das macht sich am Laufzeitbeginn fest, den man aber setzen kann: der notwendige Parameter für "openssl ca" lautet "-startdate 20190630120000Z" (P.S.: Die CA muss natürlich auch davor "entstanden" sein). Leider geht das nicht mit der OpnSense-CA, wäre eventuell ein sinnvoller Feature-Request.
Das mit der Laufzeit ist nicht ganz richtig.
Wenn du eine private CA in deinen Trust-Store importierst, erkennt das System richtig, dass das eine interne ist. Und für Zertifikate einer internen CA gelten andere Regeln.
Siehe z.B. hier:
https://support.apple.com/en-us/102028
QuoteThis change will not affect certificates issued from user-added or administrator-added Root CAs.
Dummerweise hat Apple es aber an anderer Stelle versaut und deshalb gilt zumindest unter Mac OS jetzt die vorherige maximale Gültigkeitsdauer von 825 Tagen. Das sind die rund 2 Jahre plus 3 Monate, die ich erwähnt hatte. Hab gerade nochmal den genauen Wert recherchiert.
Eigentlich könnten Zertifikate einer internen CA beliebig lang gelten aber wie gesagt nicht unter Mac OS ...
Mit "rund alle 2 Jahre" kann ich leben. Zumal mein Uptime Kuma mich warnt, wenn die auslaufen.
Gruß
Patrick
P.S. Und warum das ganze? Das hat @meyergru ja auch schon erwähnt: für das ganze Geraffel wie Switche, Drucker und USV, auf die man die Zertifikate nicht automatisch deployed bekommt. Es sei denn man will archaische Weboberflächen skripten 🤪
Interessant, das muss neu sein. Macht ja auch Sinn, sonst gäbe es mit internen Zertifikaten ja immer Stress.
Firefox und Opera machen es jetzt auch so. Das war mal anders - ich habe das nämlich auf die harte Art gelernt, als ich 2020 mal ein neues Zertifikat ausgestellt habe, dass dann nicht funktionierte. Dann habe ich nachgeforscht und den Trick mit dem alten Startddatum gefunden.
Quote from: MoChri on May 06, 2025, 11:06:29 PMDas ganze ohne das ich bei den Clienten ein Zertifikat hochladen muss da dies ja mein HAproxy übernehmen soll. Dies funktioniert ja auch beim Exchangeserver schon so nur da geht alles über die ext. IP wo der hacken ist! Da ich bei den Activ Directory Domaincontroller alle verbunden Geräte ja die Einträge selbst machen und das ist die interne IP z.b für nas.meinedomain.tld = 172.20.20.23.
Mein problem ist ich verstehe nicht wie ich OPNsense(HAproxy) einstellen muss das dies von intern funktioniert ohne das ich es über die externe IP mache.
Habe unter DHCPv4 keine DNS-Server & Domainname gesetzt
hätte bei Unbound DNS die Host Überschreibeung probiert mit HOST (*) Domain (meindomain.tld) auf die DNS-Server IP leider stürtz da Unbound DNS ab und kann es nicht mehr starten.
Zwei Punkte:
1) Nur weil du intern den AD DNS hast, MUSS der nicht zwingend benutzt werden. Du kannst problemlos den Clients per DHCP den DNS der Sense geben und dort als Domain Override dein meinedomain.tld zum AD DNS verweisen lassen. Man kann da auch mehrere für Redundanz angeben. Damit würden dann alle erstmal über die Sense reden, nicht direkt mit der AD Zone.
2) In der Sense kannst du dann problemlos nas.meinedomain.tld umschreiben auf den HAProxy - entweder die Public IP oder du bindest HAproxy einfach zusätzlich noch auf die interne IP und dann kannst dus auf die interne IP umschreiben. Geht beides. Dann redet dein Client mit der Sense/Haproxy, die ruft dein NAS auf. Feddich.
Das GEHT. Ist nur nicht ganz so simpel und hängt stark von den Rahmenbedingungen ab, deshalb nutzt da kein "Howto" irgendwas, weil niemand weiß wie dein Netz intern aufgebaut und strukturiert ist.
Aber gehen tuts.
Cheers :)