Hallo zusammen,
ich habe einen Nginx-Server laufen und möchte nun einen Exchange Server für den externen Zugriff bereitstellen. Momentan funktioniert das jedoch nicht, da der Port 443 blockiert ist.
Meine Frage: Gibt es eine Möglichkeit, den Nginx so zu konfigurieren, dass er als Pass-Through-Proxy fungiert und das Zertifikat des Exchange Servers verwendet? Oder hat hier jemand Erfahrung, wie man das am besten umsetzt, damit der Exchange Server über den Nginx erreichbar ist?
Danke im Voraus!
LG,
Simon
Wenn du eingehend Port 443 verwenden möchtest, musst du das Firewall-UI auf einen anderen Port legen und am besten auch die automatische Weiterleitung von HTTP nach HTTPS deaktivieren, da man Port 80 ja meistens auch selbst mit einer gezielten Weiterleitung versorgen möchte.
Für Pass-through, wenn die SSL-Terminierung auf dem Exchange selbst stattfindet, reicht ja ein eingehendes NAT Port Forward. Wozu da der NginX? Content inspection geht ja sowieso nicht, wenn das SSL bis zum Exchange durch geht ...
Quote from: Patrick M. Hausen on January 27, 2025, 12:51:22 PMWenn du eingehend Port 443 verwenden möchtest, musst du das Firewall-UI auf einen anderen Port legen und am besten auch die automatische Weiterleitung von HTTP nach HTTPS deaktivieren, da man Port 80 ja meistens auch selbst mit einer gezielten Weiterleitung versorgen möchte.
Für Pass-through, wenn die SSL-Terminierung auf dem Exchange selbst stattfindet, reicht ja ein eingehendes NAT Port Forward. Wozu da der NginX? Content inspection geht ja sowieso nicht, wenn das SSL bis zum Exchange durch geht ...
Die Firewall-UI nutzt bereits einen anderen Port, und die eingehenden Ports 443 und 80 werden von Nginx verwendet. Dadurch kann ich diese Ports für den Exchange Server nicht direkt nutzen. Ein einfaches Portforwarding ist daher ebenfalls nicht möglich.
Vielen Dank im Voraus!
Hallo,
möchtest Du den Exchange hinter einem ReverseProxy konfigurieren? Wenn ja, wäre NGINX eine Möglichkeit - alternativ Caddy oder HAProxy...
Port 80 und 443 werden dann vom Reverseproxy belegt und je nach Aufruf an den internen Abnehmer weitergereicht.
Quote from: bertoni on January 27, 2025, 02:03:51 PMHallo,
möchtest Du den Exchange hinter einem ReverseProxy konfigurieren? Wenn ja, wäre NGINX eine Möglichkeit - alternativ Caddy oder HAProxy...
Port 80 und 443 werden dann vom Reverseproxy belegt und je nach Aufruf an den internen Abnehmer weitergereicht.
ich habe meinen Exchange Server so konfiguriert, dass er über die URL erreichbar ist. Das funktioniert auch problemlos. Allerdings habe ich ein Problem:
Wenn ich versuche, von extern Outlook einzurichten, schlägt das fehl. Es scheint, als ob die Verbindung nicht korrekt hergestellt werden kann – Outlook fragt ständig nach einem Passwort. Das deutet für mich darauf hin, dass es ein Kommunikationsproblem gibt.
Gibt es etwas Spezielles, das ich bei der Konfiguration von Autodiscover oder anderen Diensten beachten muss, damit das funktioniert mit Nginx ?
Vielen Dank im Voraus für eure Hilfe!
Das funktioniert entweder mit Caddy in OPNsense Community oder der OPNWAF (basierend auf Apache) in OPNsense Business.
In Caddy wäre es der Haken "NTLM" im Handler, welcher Outlook von extern ermöglicht. Das Modul ist im os-caddy plugin kompiliert. https://github.com/caddyserver/ntlm-transport
In Apache (OPNWAF) ist es ein eigenes Modul was kompiliert ist, nennt sich "mod_proxy_msrpc". Dieses ist in der OPNsense Business Version dabei.
https://docs.opnsense.org/vendor/deciso/opnwaf.html#exchange-server
Bei NGINX gibt es das Modul nur in nginx plus https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm
Das bedeutet, um Exchange mit Outlook zum laufen zu bekommen, verwende entweder Caddy oder OPNWAF, oder benutze keinen TLS Termination Proxy, sondern einen Layer 4 Proxy (HAproxy, nginx und Caddy können Layer 4 Proxy)
Quote from: Monviech (Cedrik) on January 27, 2025, 03:03:27 PMDas funktioniert entweder mit Caddy in OPNsense Community oder der OPNWAF (basierend auf Apache) in OPNsense Business.
In Caddy wäre es der Haken "NTLM" im Handler, welcher Outlook von extern ermöglicht. Das Modul ist im os-caddy plugin kompiliert. https://github.com/caddyserver/ntlm-transport
In Apache (OPNWAF) ist es ein eigenes Modul was kompiliert ist, nennt sich "mod_proxy_msrpc". Dieses ist in der OPNsense Business Version dabei.
https://docs.opnsense.org/vendor/deciso/opnwaf.html#exchange-server
Bei NGINX gibt es das Modul nur in nginx plus https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm
Das bedeutet, um Exchange mit Outlook zum laufen zu bekommen, verwende entweder Caddy oder OPNWAF, oder benutze keinen TLS Termination Proxy, sondern einen Layer 4 Proxy (HAproxy, nginx und Caddy können Layer 4 Proxy)
Oke, mit dem normalen Nginx, der bei der OPNsense dabei ist, kann ich kein Autodiscover über Exchange fahren.
Die Seite ist zwar über das Internet erreichbar, aber es gibt immer wieder Schwierigkeiten beim Abrufen von Benutzerdaten. Das Profil wird zwar geladen, aber es erscheint sofort eine erneute Passwortabfrage.
Ich bin mir unsicher, ob das Problem an der Nginx-Konfiguration liegt oder ob auf meinem Test-Exchange-Server noch etwas angepasst werden muss.
Das schrieb @Monviech doch, dass es nur mit NginX Plus geht. Der ist in OPNsense naturgemäß nicht drin, ist ja kein Open Source sondern ein Lizenzprodukt. --> auf Caddy oder HAproxy wechseln.
Quote from: Patrick M. Hausen on January 27, 2025, 03:44:17 PMDas schrieb @Monviech doch, dass es nur mit NginX Plus geht. Der ist in OPNsense naturgemäß nicht drin, ist ja kein Open Source sondern ein Lizenzprodukt. --> auf Caddy oder HAproxy wechseln.
Alles klar mit Caddy funktioniert es - da habe ich aber das Problem das mein Guacamole (RDP) nur eine weiße Seite angezeigt wird ... deswegen bin ich von Nginx noch nicht geswitch .. muss ich mich mal mit beschäftigen - vielleicht weiß da jemand von euch Bescheid
Für Guacamole hab ich extra das Feature "Upstream Path" in das Caddy-Plugin eingebaut, kein Problem :-)
(https://forum.opnsense.org/index.php?action=dlattach;attach=41997;image)
Quote from: Patrick M. Hausen on January 27, 2025, 04:20:32 PMFür Guacamole hab ich extra das Feature "Upstream Path" in das Caddy-Plugin eingebaut, kein Problem :-)
(https://forum.opnsense.org/index.php?action=dlattach;attach=41997;image)
Oke, bei mir ging es jetzt auch ohne den Upstream Path.
Ich hatte immer das Problem, als Caddy auf OPNsense zum Einsatz kam, aber jetzt scheint alles soweit zu funktionieren. Vielen Dank, jetzt kann ich den Nginx wohl endlich einstampfen! 😊
Kurze Frage zu Caddy: Bei Nginx gibt's ja die Möglichkeit, eine eigene 'Gebannt'-Seite einzurichten. Wie sieht das bei Caddy aus? Gibt es da sowas auch, oder ist das noch nicht so weit entwickelt?
Das plugin konfiguriert Caddy so, dass es keine statischen Dateien serviert, also auch keine eigenen Error HTML Seiten. Das dient zur sicherheit für die Firewall, es gibt kein Web Root Verzeichnis. Es ist nur proxy.
Wenn Access Lists benutzt werden kann man dort in den Advanced Optionen einen eigenen HTTP Status Code mit eigener Message definieren, die dann im Browser angezeigt wird.
Quote from: Monviech (Cedrik) on January 28, 2025, 09:29:32 PMDas plugin konfiguriert Caddy so, dass es keine statischen Dateien serviert, also auch keine eigenen Error HTML Seiten. Das dient zur sicherheit für die Firewall, es gibt kein Web Root Verzeichnis. Es ist nur proxy.
Wenn Access Lists benutzt werden kann man dort in den Advanced Optionen einen eigenen HTTP Status Code mit eigener Message definieren, die dann im Browser angezeigt wird.
Super, vielen Dank für die Info!
Ist Caddy in puncto Sicherheit auf dem gleichen Niveau wie Nginx, oder hinkt es hier noch etwas hinterher?
Das Einrichten eines neuen Servers ist ja deutlich einfacher als bei Nginx. :-)
Gibt es sonst noch etwas, das ich beachten sollte?
Ich kann das nicht beurteilen. Du kannst ja mal im Caddy Forum nachfragen: https://caddy.community/
Wenn du technisch etwas höhere Sicherheit willst kannst du den Prozess als "www" user laufen lassen indem du das in den General Settings umstellst.
https://docs.opnsense.org/manual/how-tos/caddy.html#run-caddy-process-unprivileged
Die ganzen DNS Sachen für Autodiscover hast du extern erreichbar?
Yes, mit Caddy funktioniert das wirklich gut (Handy etc.) - Caddy macht da eine gute Arbeit - auch verschiedene Tests durchgeführt, aktuelle TLS Version sind vorhanden.
Guten Tag!
Kannst du deine Konfiguration teilen?
Wir haben mit Outlook als Client immer noch das Problem der Authentifizierung, welche immer und immer wieder aufploppt.
Wir müssen dauernd die Zugangsdaten eingeben und wenige Sekunden später, erscheint erneut die Benutzer/Kennwortabfrage im Outlook.
Im LAN oder mit VPN funktioniert der Zugriff einwandfrei.
Wäre nett von dir/euch, wenn ihr uns ein paar Inputs geben könntet..
Danke!
Quote from: Monviech (Cedrik) on January 27, 2025, 03:03:27 PMDas funktioniert entweder mit Caddy in OPNsense Community oder der OPNWAF (basierend auf Apache) in OPNsense Business.
In Caddy wäre es der Haken "NTLM" im Handler, welcher Outlook von extern ermöglicht. Das Modul ist im os-caddy plugin kompiliert. https://github.com/caddyserver/ntlm-transport
In Apache (OPNWAF) ist es ein eigenes Modul was kompiliert ist, nennt sich "mod_proxy_msrpc". Dieses ist in der OPNsense Business Version dabei.
https://docs.opnsense.org/vendor/deciso/opnwaf.html#exchange-server
Bei NGINX gibt es das Modul nur in nginx plus https://nginx.org/en/docs/http/ngx_http_upstream_module.html#ntlm
Das bedeutet, um Exchange mit Outlook zum laufen zu bekommen, verwende entweder Caddy oder OPNWAF, oder benutze keinen TLS Termination Proxy, sondern einen Layer 4 Proxy (HAproxy, nginx und Caddy können Layer 4 Proxy)
Kannst du uns eine Beispielkonfig geben?
Irgendwie klappt das bei uns nicht. Ständiger Authentifizierungsloop, wenn außerhalb des LAN bzw ohne VPN..
Wäre super! Danke!
Welches plugin wird denn verwendet?
Mit Caddy und OPNWAF habe ich es erst heute getestet weil ich auf Fehlersuche bin.
Popups passieren sporadisch, manchmal keine, manchmal unendlicher loop, manchmal nur eins.
Wenn man Outlook ein paar mal schließt und startet geht es manchmal plötzlich.
Ich kann gerade keine Tips geben.
Quote from: Monviech (Cedrik) on January 05, 2026, 12:05:58 PMWelches plugin wird denn verwendet?
Mit Caddy und OPNWAF habe ich es erst heute getestet weil ich auf Fehlersuche bin.
Popups passieren sporadisch, manchmal keine, manchmal unendlicher loop, manchmal nur eins.
Wenn man Outlook ein paar mal schließt und startet geht es manchmal plötzlich.
Ich kann gerade keine Tips geben.
@oachkatze meint es würde mit caddy funktionieren?
Ja, aber Dinge ändern sich mit der Zeit. Z.B "Exchange Extended Protection" im Exchange Server je nach Service Pack, NTLM deprecation von Microsoft, Outlook dass zu Outlook Classic wurde, ob mapi over http oder rpc over http verwended wird...
Ganz viele Themen die es gerade langsam immer schwerer machen den Exchange korrekt zu reverse proxien.
Also gibt es aktuell keine funktionierende Lösung mit Caddy, auch wenn man die Ext. Protection deaktiviert?
Bindet ihr den Zugang zu euren Exchangeserver direkt via NAT ans Internet? Also mit eigener IP und fertig?
Wenn der Exchange ein öffentliches Zertifikat hat kannst du es noch so testen (in Caddy):
General Settings:
- Enable Layer4 Proxy
Layer 4 Proxy: Add Layer 4 Route
- Routing Type: listener_wrappers
- Matchers: TLS (SNI Client Hello)
- Domain: autodiscover.example.com mail.example.com (also alle Domains vom Exchange Zertifikat hier rein)
- Upstream Domain: 192.168.1.1 (IP vom Exchange)
- Upstream Port: 443
Die Exchange Domains in "Reverse Proxy" deaktivieren, da sie jetzt von "Layer 4" benutzt werden.
Dann Apply.
Jetzt wird ohne TLS termination gearbeitet.
Danke für deien Infos, aber ich möchte bewusst den L7-modus nutzen..
So wie es beim KEMP ja auch klappt. Dort sind die Lizenzkosten einfach enorm und wir setzen bei vielen unserer Kunden erfolgreich OPN als firewall ein, deshalb die geplante Erweiterung mit CADDY und LE-Zertifikaten.
Nur das NTLM problem scheint man nicht in griff zu kriegen, also auch nicht mit caddy wies scheint.
Quote from: zorpat84 on January 05, 2026, 09:14:33 PMSo wie es beim KEMP ja auch klappt. Dort sind die Lizenzkosten einfach enorm
Mit Kemp haben wir lange sehr erfolgreich und zufrieden gearbeitet. Ich würde die Lizenzkosten eher im unteren Bereich ansiedeln, verglichen mit F5, Cisco & Co. ;-)
Außerdem sind die generell sehr kompetent - sowohl Implementierung als auch Support.
Also wenn's der Business-Case her gibt, bleibt doch bei denen.
Quote from: Patrick M. Hausen on January 05, 2026, 09:26:31 PMAlso wenn's der Business-Case her gibt, bleibt doch bei denen.
..als Plan B sicher.. aber es ist doch nicht möglich, dass es all diese tollen layer7 proxies nicht schaffen einen Exchangeserver sauber anzubinden, oder? ☺️
Naja geh halt zu den Projekten und wirf ihnen Geld hin damit sie es Maintainen. Bei Caddy ist es dieses Plugin hier was auch in der OPNsense Caddy Plugin version kompiliert ist. Und das hat auch 2-3 Jahre funktioniert:
https://github.com/caddyserver/ntlm-transport
Aber die meisten nutzen jetzt halt Exchange Online, da passiert nicht mehr viel gerade auser es ist ein Business Case und jemand ist Sponsor.