Frage zu Zertifikaten und Zugriff von innen und außen (mit HAProxy oder Caddy)

[white_rabbit]

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.

[viragomann]

Hallo,

eine Möglichkeit, das zu vereinfachen, ist, die Zugriffe von intern auch auf HAproxy zu routen. Dazu kann die interne IP zum Frontend hinzugefügt werden, sollte er nicht ohnehin auf allen lauschen und diese im internen DNS eintragen.
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.

Wenn die Verbindung zwischen HAproxy und den Backend Servern auch verschlüsselt sein müssen, würde ich eine interne CA verwenden und mittels dieser langlebige Zertifikate generieren und auf den Backends installieren.
HAproxy kann dann so konfiguriert werden, dass er die Zertifikate überprüft, dann müssen Hostnamen (jener in der Backend Konfig) bzw. IP im Zertifikat eingetragen sein, oder dass er einfach jedes beliebige akzeptiert.

Es gibt auch Ansätze, das Kopieren der Zertifkate auf die Backends zu automatisieren. Das würde ich aber nur machen, wenn der Weg über HAproxy absolut keine Option ist.

[white_rabbit]

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)

[Patrick M. Hausen]

HAproxy ist unübersichtlich und ein Problem des Plugins ist, dass der maßgebliche Autor von der etablierten Terminologie von HAproxy abweicht und das ganze aufbaut wie viele Loadbalancer aus der kommerziellen Ecke - F5, Cisco, Kemp, ... - das Ganze behandeln.

Ich hab mir zugegebenermaßen nicht alle Details in diesem Thread angeguckt aber als generellen Hinweis:

Ich benutze für alle Dienste, die extern und intern erreichbar sein sollen, ausschließlich die externe IP-Adresse und FQDN. Nebst Letsencrypt-Zertifikat, natürlich. 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.

Weshalb sollte ich für Zugriffe von "innen" eine andere IP-Adresse benutzen? Die Verbindung kommt zum LAN rein, dann ist "WAN address" eine lokale Adresse, also geht das an den Caddy. Da wird nix "erst mal raus zum Provider und dann wieder rein" geroutet. Jede Adresse, die für die Sense auf einem lokalen Interface liegt, ist gleichwertig. Und da ich auf LAN "allow LAN net to any" habe, geht das auch einfach so durch.

Keine NAT-Refelction, nix. Funktioniert einfach.

Es wäre einen winzigen Tick "optimaler", wenn cloud.meinedomain.de intern direkt auf den Server verweisen würde. Das würde den Proxy-Overhead sparen. Aber alle Server und die Sense sind hier intern mit 1G oder 10G veerknubbelt, also was soll das?

Pluspunkt: wenn es imtern funktioniert, weißt du, dass es auch extern funktioniert - und umgekehrt.

Das ist der Riesenvorteil eines Reverse-Proxy mit SSL-Terminierung im Proxy. Funktioniert von außen wie innen absolut identisch und es braucht keine NAT-Reflection oder anderes Gedöns.

Eine Verbindung von einem Client im "LAN" mit Ziel "WAN address" geht nicht "über das Internet". Nie. Berücksichtigen! 😉

[viragomann]

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.

Naja, die OPNsense webGUI sollte natürlich nicht am selben Port wie HAproxy lauschen.
Einen alternativen Port kannst du in System: Settings: Administration einstellen.
Ebenso sollte da "Disable web GUI redirect rule" angehakt sein, damit der Port 80 nicht auf das Webinterface umgeleitet wird.

[white_rabbit]

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!

[viragomann]

Wo sehe ich das? Beim HAProxy finde ich keine Port-Einstellungen

Da war von der OPNsense Web GUI die Rede. Das hat nichts mit HAproxy zu tun. Wo das zu finden ist, hatte ich oben beschrieben.

[Patrick M. Hausen]

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

Wenn du gleichzeitig über einen DynDNS-Anbieter dafür sorgst, dass der A-Record immer stimmt, dann natürlich. Weshalb auch nicht? ;) Aus der Sicht deiner lokalen Infrastruktur gibt es keinen Unterschied zwischen dynamischer und statischer Adresse. Zum Zeitpunkt X ist da eine Adresse. Fertig.

Zu der anderen Frage: System > Settings > Administration, TCP Port auf was anderes als 443 setzen und bei HTTP Redirect den Haken setzen, also den Redirect deaktivieren. Sonst kannst du keine eingehenden Dienste auf 80 und 443 nutzen.

[white_rabbit]

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!?

[Patrick M. Hausen]

Du benutzt auch beim Zugriff von innen den offiziellen FQDN, der beim DynDNS-Anbieter immer aktuell gehalten wird und immer auf die jeweils gültige WAN-Adresse zeigt. Wozu brauchst du noch einen Eintrag in Unbound?

[white_rabbit]

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

[Patrick M. Hausen]

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

Extern: cloud.meinedomain.de
Intern: meinzuhause.lan

Irgend sowas.

Und dann für alle extern erreichbaren Anwendungen nur die externe Domain benutzen.

Das Zertifikat der Firewall kommt dann, wenn du das Firewall UI nicht auf einen anderen Port gelegt hast ... z.B. 4443. Und den HTTP-Redirect ausschalten!

[white_rabbit]

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.

[Patrick M. Hausen]

Wenn du die local domain im Unbound auf transparent stellst, sollte es ohne lokalen Eintrag nur mit dem DynDNS auch funktionieren. Trotzdem macht man das einfach kategorisch nicht, ist generell eine schlechte Idee, foo.com intern zu benutzen, wenn das gleichzeitig die öffentlich sichtbare Domain der Firma ist.

Das mit dem anderen Port wurde aber schon X-mal erwähnt, das ist Grundvoraussetzung, um überhaupt irgendwas auf 443 erreichbar zu machen.

[white_rabbit]

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