OPNSense ist ein Fork der bekannten OpenSource Firewall PFSense, mir persönlich gefällt OPNSense besser, die GUI ist aufgeräumter, es gibt eine REST-Api und die wichtigsten PlugIns sind ebenfalls verfügbar.
Da für OPNSense ein Plugin für HAProxy und auch für Let’s Encrypt existiert, habe ich angefangen diese Kombination in Verbindung mit Exchange 2016 zu testen. OPNSense kann also direkt ein kostenloses Zertifikat von Let’s Encrypt anfordern und kümmert sich dann auch selbstständig um die Erneuerung.
Kostenlose Firewall und kostenlose Zertifikate, hört sich doch gut an. Hier ein erster Test.
Umgebung
Meine Testumgebung ist wie folgt aufgebaut:
Der Internetzugang wird über eine Fritzbox hergestellt. OPNsense stellt die Internetverbindung über die Fritzbox her. Der Exchange Server befindet sich “hinter” der OPNsense VM, hier findet also ein doppeltes NAT statt. Hier die Auflistung der IP-Adressen:
| WAN IP Fritzbox | 80.153.231.160 |
| LAN IP Fritzbox | 192.168.10.1 |
| WAN IP OPNSense | 192.168.10.107 |
| LAN IP OPNSense | 172.16.14.1 |
| IP Exchange | 172.16.14.9 |
Vorbereitung
Nach der Installation und der Einbindung in mein Netzwerk habe ich zuerst einmal den Port für den Verwaltungswebsite geändert. Die Verwaltungsoberfläche hört in der Standardkonfiguration auf Port 443 (https). Port 443 möchte ich aber für Exchange nutzen. Ich habe mich hier für Port 4444 entschieden.
Danach werden die erforderlichen Plugins nachinstalliert. Das Plugin “os-acme-client” ist das Plugin für Let’s Encrypt, “os-haproxy” übernimmt die Veröffentlichung von Exchange. Da es sich in meiner Umgebung um eine VM auf ESXI handelt, habe ich auch die VMware Tools installiert:
Neben der entsprechenden Netzwerkkonfiguration waren das schon alle Vorbereitungen.
Firewall
Nachdem OPNsense in mein Netzwerk integriert wurde, habe ich zunächst zwei Firewall Regeln erstellt, die http und https Verkehr auf dem WAN Port zulassen:
Für die beiden Regeln wird als Schnittstelle jeweils “WAN” und als Protokoll “TCP” ausgewählt. Als Zielportbereich wird für eine Regel “HTTP” und für die zweite Regel “HTTPS” ausgewählt.
Nach dem Anlegen der beiden Regeln sieht es dann so aus:
Eine Regel für HTTP und eine Regel für HTTPS. Somit wird schon einmal Traffic von extern erlaubt. Weiter geht es mit HAProxy.
HAProxy
Weiter geht es mit der grundlegenden Konfiguration von HAProxy für Exchange 2016. In den HAProxy Einstellungen wird zunächst der Exchange Server als Real Server angelegt:
Ich habe des Exchange Server wie folgt angelegt, die Option “Überprüfen Sie das SSL-Zertifikat” habe ich abgeschaltet, da Exchange ein selbst signiertes Zertifikat verwendet:
Sobald der Server angelegt wurde, kann ein BackEnd erstellt werden:
Für das Backend werden die folgenden Einstellungen getätigt:
Jetzt wird eine ACL angelegt, für diesen Test mache ich es mit einfach und erstelle nur eine ACL:
Die folgenden Einstellungen gelten für die ACL:
Nachdem die ACL angelegt wurde, wird eine “Aktion” erstellt:
Für die Aktion wird folgendes konfiguriert:
Zum Schluss wird das Frontend angelegt:
Für das FrontEnd werden die folgenden Einstellungen verwendet. Die IP-Adresse 192.168.10.107 ist dabei die WAN IP Adresse der OPNsense Firewall (NAT hinter Fritzbox) plus den HTTPS-Port (443). In diesem Fall also 192.168.10.107:443
Dan noch ein Zertifikat von Let’s Encrypt existiert, verwende ich zunächst das Standard Zertifikat für die Web GUI. So lässt sich die Konfiguration schon einmal testen. Des weiteren wird auch die “X-Forwarded-For-Kopfzeile” aktiviert:
In den erweiterten Einstellungen des Frontend sind diese Einstellungen definiert;
Danach kann HAProxy aktiviert werden:
Falls HAProxy schon aktiviert war, dann am besten einmal neu starten.
Jetzt funktioniert schon einmal OWA, aber da noch kein gültiges Zertifikat vorliegt kommt es natürlich zu Zertifikatswarnungen:
Jetzt kann das Let’s Encrypt Plugin konfiguriert werden.
Let’s Encrypt
Let’s Encrypt bietet die Möglichkeit die Integration über das “Staging Enviroment” zu testen. Für offiziell gültige Zertifikate hat Let’s Encrypt Limitierungen eingebaut, so können zum Beispiel nicht beliebig viele Zertifikate ausgestellt werden. Für Tests bietet es sich also an mit dem Staging Enviroment zu starten und erst auf das “Production Enviroment” umzustellen wenn alles funktioniert.
In diesem Fall wird auch zunächst das Staging Enviroment genutzt:
Sobald das PlugIn aktiviert wurde, kann der Account angelegt werden:
Für den Account wird nur eine E-Mail Adresse benötigt:
Jetzt kann die Überprüfungsmethode konfiguriert werden:
Als Überprüfungsmethode habe ich HTTP-01 belassen, außerdem musste ich in meiner Umgebung die WAN IP explizit angegeben, da sonst keine Verbindung aufgebaut werden konnte. Als FrontEnd wird das zuvor erstellte “Exchange_2016_Frontend” ausgewählt:
Hinweis: Das Exchange 2016 Frontend wurde nur auf Port 443 (HTTPS) konfiguriert, Let’s Encrypt prüft die Domain mit der Validierungsmethode HTTP-01 allerdings auf Port 80 (HTTP), daher habe ich einen zusätzliches FrontEnd auf Port 80 (HTTP) für Let’s Encrypt erstellt:
Für das Let’s Encrypt Frontend wird ebenfalls die IP des WAN Interfaces angegeben, dies mal allerdings mit Port 80. Als Standard Backend wird “acme_challende_backend” ausgewählt, welches durch das Plugin erstellt wurde. Gleiches gilt auch für die Aktion “redirect_acme_challanges”:
Zurück zum Let’s Encrypt Plugin, hier kann jetzt das Zertifikat konfiguriert werden:
Mein Exchange Server ist hört auf die Namen mail.frankysweb.de für alle Webservices (ActiveSync, Outlook Anywhere, EWS, etc) und autodiscover.frankysweb.de für Autodiscover. Daher gebe ich die folgenden Werte für das Zertifikat an:
Nachdem das Zertifikat konfiguriert wurde, steht es im Status “Pending”, daher kann jetzt das Zertifikat ausgewählt und der Button “Zertifikate jetzt ausstellen oder erneuern” geklickt werden:
Nach kurzer Zeit ist dann unter “Last Acme Status” der Wer “OK” zu sehen:
Jetzt ist das Test-Zertifikat, welches vom Let’s Encrypt Staging Environment ausgestellt wurde, in der Zertifikatsübersicht zu sehen. Ausgestellt wurde es von der da “Fake LE Intermediate X1”:
Um nun an ein gültiges Zertifikat zu kommen, kann nun die Let’s Encrypt Umgebung auf “Production Environment” umgestellt werden:
Nachdem das “Production Environment” ausgewählt wurde, muss noch das Zertifikat erneut ausgestellt werden:
In der Übersicht der Zertifikate ist nun das gültige Zertifikat zu sehen, welches von der CA “Let’s Encrypt Authority X3” ausgestellt wurde:
Zum Schluss muss das Zertifikat nur noch dem Exchange Frontend zugewiesen werden:
In den Einstellungen zum Frontend kann jetzt das gültige Zertifikat ausgewählt werden:
Nun erscheinen auch keine Zertifikatswarnungen mehr:
Fazit
Die Konfiguration ist etwas aufwändiger als zunächst gedacht. Während ich diesen Artikel erstellt habe, wurde zwischenzeitlich ein Update für die Plugins HAProxy und Let’s Encrypt veröffentlicht, daher habe ich zwischenzeitlich wieder von vorne angefangen, um es mit der aktuellen Version zu testen.
Diese Konfiguration funktioniert zwar, ist aber alles andere als perfekt. Ich muss mich noch einmal eingehenden mit den ACLs und Aktionen vertraut machen um eine vernünftige Konfiguration zu erstellen. Für einen ersten Test, ist es aber ganz vielversprechend.
Hallo,
gibt es eine Möglichkeit den OPNsense/HAProxy-Weg ohne SSL Offloading einzusetzen? Bei Exchange Extended Protection wird dieser Weg ja leider unmöglich (soweit ich es verstanden habe).
Viele Grüße
Sascha
Hi,
Siehe hier:
https://www.frankysweb.de/exchange-extended-protection-und-haproxy/
Das geht auch mit OPNsense und HAProxy. Wichtig ist, dass das Zertifikat bei Haproxy und Exchange identisch ist.
gruß
Chris
Ich habe im OPNsense Forum eine aktuelle und etwas ausführlichere Anleitung zum dem Thema geschrieben.
https://forum.opnsense.org/index.php?topic=23339.0
Vielen Dank für deine Anleitung. Sehr gut finde ich, das du mit dem HAProxy begonnen hast und dann erst mit dem Zertifikat. Das hat mich an deinen Beitrag gefesselt.
Allgemein ist wichtig zu wissen das sich die Oberfläche etwas geändert hat und man mit ACL nicht wirklich etwas anfangen kann: Entspricht jetzt HAProxy –> Einstellungen –> Regeln & Prüfungen –> Bedingungen.
Vielleicht erweiterst du deinen Betrag ja noch um das Reverse Proxy Thema um von 80 auf 443 weiter zu leiten. Das fehlt mir noch. :)
Hallo Frank,
ein lesenswerter Artikel, der mir bei einem geplanten Projekt weiterhelfen wird. Könntest Du eventuell ein Update des Artikels machen? Z.B. werden seit Version 18.7.7 Client Zertifikate für HAProxy unterstützt. Damit könnte man den Zugriff auf Exchange doch gut absichern.
Gruß, Stefan
Korrektur: Die Client Zertifikate werden seit Version 18.7.8 unterstützt.
Ein Update wäre mega! Es ist momentan richtig schwer, irgendwas passendes im Netz zu finden.
Hallo Franky, hast du schon eine Lösung gefunden wie man die ACL etwas besser konfigurieren kann weil /* finde ich persönlich keine gute Idee. Zumal man das von aussen auf die ECP zugreifen kann was mir persönlich nicht so gefällt aus Security-Sicht.
Mir scheint aber so das opnsense bzw. haproxy sich im Moment schwer tut das die ACL auch wirklich ziehen.
Es wäre schön wenn du einen Lösungsansatz dafür hättest.
Geht ganz einfach.
Du kannst die Rule auf host_matches stellen.
Unten dann genau die Subdomain eintragen die du haben willst.
Gruß Robert
Hallo Frank,
mittlerweile ist in PFsense acme 2 auch in der Lage, wildcard Zertifikate selbständig zu installieren. Schade das es kein Howto für Pfsense geben wird, auch wenn OpnSense recht ähnlich (Fork) aufgebaut sind. Aber vielleicht reizt es dich ja mal doch, es auf einer Pfsense 2.4.3 zu versuchen. HaProxy ist da ja ebenfalls verfügbar.
Beste Grüße,
Falk
Hallo Frank,
danke für die Erläuterung. Ich habe HA Proxy erfolgreich im Einsatz. Kurz vorher hatte ich bereits dein Popwershell Script für Exchange 2016 durchlaufen lassen.
Ist es möglich, dass der Exchange über das PoerShell Script ein LetsEncrypt Cert bezieht und HA Proxy auch? Oder kommen sich dann Beide in die Wege. Im Moment läuft es, jedoch würde ich gern wissen, was in 90 Tagen passiert ;)
Gruß
Danny
Grüße.
Also ich muß erstmal besten Dank sagen für diese gute Anleitung.
Ich hatte ein paar Schwierigkeiten beim Einrichten, da sich die Oberfläche des HAproxy im OPNsense geändert hat.
Jetzt hab ich nur noch eine kleine Thematik….
Könntest du vielleicht mal beschreiben, wie man das für IMAPs und SMTPs einrichtet.
Ich bin nach dem gleichen Schema vorgegangen, aber bekomme keine Verbindung.
Nutze aber keinen Exchange, sondern einen Postfix usw.
Hallo Frank,
danke für deine Anleitung ich habe allerdings ein Problem damit ich die Anleitung auf ein wenig angepasst.
So habe ich z.b in der aktuellen Version vom HAProxy in den ACL nicht /* freigegeben sondern alles bis auf das ECP.
Es funktioniert auch soweit ich habe nur ein Problem mit ActiveSync auf dem Handy.
Dort ist es so das ich leider nicht sehe wenn eine Mail eintrifft oder bzw. ich kann keine Mail versenden.
Muss man über Active Sync noch irgentwas in der Firewall etc. freigeben damit man mit dem Handy darauf zugreifen kann nur dachte ich immer das es genügt wenn ActiveSync von aussen funktioniert den die einrichtung konnte abgeschlossen werden.
Ich verwende Exchange 2016 mit dem neuen CU.
OWA usw. funktioniert tatellos. Auch wenn ich die URL von Active Sync aufrufe geht es hast du heissen tip woran das liegen könnte.
Ich verwende Opensense 1.7.7-8.
Hallo Frank,
vielen Dank für den großartigen Artikel und deine unermüdliche Bereitschaft, dein Wissen weiterzugeben. Ich lese schon seit 2013 regelmäßig deine Beiträge und muss sagen, durch sie bin ich bisher völlig unproblematisch durch zwei Exchange-Migrationen gekommen!
Ich habe nun auch ein Setup auf Basis von opnsense und Exchange 2016 am Laufen, dein Artikel war dafür natürlich wieder ein Must-Read :)
Zu der Frage von Frank bzgl. Zertifikaten bei Zugriff von innen bzw. außen, die Frage kam mir auch sehr schnell auf. Ich habe eine sehr einfache Lösung gefunden:
Maildomain: „company.de“
AD-Domain: „intranet.company.de“
Mail-Server (im AD-DNS): „winsrv-mail.intranet.company.de“ (Bsp.: 10.220.10.20)
Als Hostnamen für den Zugriff auf Mail soll
„mail.OFFICE.company.de“
genutzt werden, hier ist jetzt nur wichtig, dass die Sub-Domain NICHT gleich lautet wie die AD-Domain.
Nun habe ich in opnsense einfach zwei DNS Host Override (Services -> unbound DNS -> Host override) definiert, damit „mail.office.company.de“ und „autodiscover.company.de“ von intern aufgelöst werden können. Als IP gebe ich dabei aber die interne LAN-IP der OPNSENSE an, bzw. die IP der passenden VLAN-Schnittstelle, an der auch der Mailserver hängt.
Im öffentlichen DNS des Domain-Hosters wird die feste öffentliche IP eingetragen, unter der die opnsense im Internet zu erreichen ist, einmal für den Namen „mail.office.company.de“ und für „autodiscover.company.de“.
Das einzigste was jetzt noch zu tun ist: in HAProxy im Exchange-Frontend nicht die IP-Adresse angeben, sondern:
„mail.office.company.de:443“
Jetzt tut es sowohl von drinnen als auch von draußen mit demselben, gültigen Zertifikat.
Ein Hinweis noch zu SAN-Zertifikaten mit LetsEncrypt:
Jeder der alternativen Namen muss zumindest im öffentlichen DNS des Domain-Hosters auf die Adresse der opnsense zeigen, LetsEncrypt prüft JEDEN Namen ab, der zum Zeitpunkt der Beantragung im Zertifikat steht.
Auch erst mal vielen Dank an Franky, durch den Artikel hab ich auch gute Anregungen bekommen. Auch wenn die Beiträge älter sind ergänze ich mal noch was, falls jemand wie ich vor kurzem auf Lösungssuche ist.
Zum internen Gebrauch: Ich habe einfach im DNS der AD die beiden Subdomains vom Exchangeserver auf die LAN IP der OPNSense umgelenkt und diese auch im Frontend (in den neueren Versionen des HaProxy „Public Service“) unter Listen Adresses (IP aus Frankys Testaufbau: 172.16.14.1:443) mit eingetragen.
Geht dann auch von bestens von „drinnen und draußen“.
Ich wollte einfach nur Danke sagen :) Danke für die wirklich großartige Arbeit mit den 2 Plugins, für mich fast schon die wichtigsten Tools hinter OPNsense überhaupt.
DNSresolver + DHCP + HAproxy + LetsEncrypt in der Kombination auf dem Backend vervierfacht den Wert der Gateway Lösung!
Vielen Dank
Hallo Frank,
zuerst einmal ein großes Lob für deine tolle Website. Sie hat mir schon mehrmals weitergeholfen.
Aktuell bin ich dabei, für einen Freund in seiner kleinen Firma (3 Leute) einen neuen Windows Server samt Exchange 2016 einzurichten. Speziell bei dem Thema Zertifikate wird es für mich schwierig.
Ich habe lt. deiner Anleitung „Exchange 2016 – Opnsense -HAProxy und Let´s Encrypt“ versucht, die Zertifikate für extern einzurichten.
Jetzt habe ich aber noch ein grundsätzlichens Verständnisproblem:
So weit ich es verstanden habe dient die Anleitung dazu, die Zertifikate für den exteren Zugriff auf die Exchange-URL (mail, autodiscover) einzurichten. So weit so gut.
Ebenso lt. deinen Anleitungen habe ich die internen Exchange-URLs den externen gleichgesetzt und im DNS erreichbar gemacht (funktioniert). Doch bei den Let´s Encrypt Zertifikaten für intern verstehe ich was nicht:
1) Ist es richtig, das die Anleitung für „Exchange2016-Opnsense-HAProxy-LetsEncrypt“ nur für externe (von außerhalb der Firma) Aufrufe gilt?
2) Bei internen Aufrufen (d.h. in der Firma über lokalen DNS) bekomme ich keine Verbindung, da lt. Browser Zertifikate fehlen.
3) Die Anleitung von Dir für Exchange2016 & Let´s Encrypt für Intern würde ja für die gleichen URLs (mail, autodiscover) nochmals neue Zertifikate anfordern. Frage geht das überhaupt?
4) Wenn Frage 3 nein, wie bekomme ich dann die Let´s Encrypt Zertifikate von der Opnsense & HAProxy Konfig durch das häufige Renewal automatisch auch intern ins AD oder auf den Exchange?
Hoffe Ihr könnt mir da etwas Licht in die Sache bringen.
Recht herzliches Dankeschön mal vorab.
LG
Robert
Hi Franky…
Immer wieder schön was es so gibt. Bin seit etlichen Jahren auf PFSense und schaue mir nun OPN an. Von Sophos habe ich die Finger gelassen weil es nicht wirklich mehr kann als die PFS (bei ca. 450 User, mit „Schnickschnack“). Hat eben ein schönes Interface.. mehr konnte ich aber wirklich nicht feststellen.. Wie sind Deine Erfahrungen?
Gruss Matze
Frank,
du Unermüdlicher. Immer etwas Neues ;-)
Wenn du OPNsense mit sophos UTM vergleichst, wie fällt denn dein Fazit aus?
Grüße
Martin
Hi Martin,
das wäre ein Vergleich zwischen Äpfeln und Birnen. Der HAProxy von OPNsense ist in erster Linie ein Loadbalancer und keine Web Application Firewall (Apache ModSecurity) wie von der UTM verwendet. Ein direkter Vergleich ist so also nicht möglich.
Gruß, Frank
Hallo Frank,
Wie sieht die Situation in Verbindung mit Outlook Anyware aus?
Ich hatte hier z.b. in Verbindung mit nginx relativ viele Probleme.
Macht der haproxy einem hier das Leben leichter?
Grüße Kevin
Hi, habe es bisher nicht mit Outlook Anywhere versucht, sondern nur mit MAPIoverHTTP. Eigentlich hat HAProxy aber kein Problem mit Outlook Anywhere.
Gruß, Frank