OPNSense is a fork of the well-known open source firewall PFSense, I personally like OPNSense better, the GUI is tidier, there is a REST api and the most important plug-ins are also available.
As there is a plugin for HAProxy and also for Let's Encrypt for OPNSense, I have started testing this combination in conjunction with Exchange 2016. OPNSense can therefore directly request a free certificate from Let's Encrypt and then takes care of the renewal itself.
Free firewall and free certificates, sounds good. Here is a first test.
Surroundings
My test environment is set up as follows:
Internet access is established via a Fritzbox. OPNsense establishes the Internet connection via the Fritzbox. The Exchange server is located "behind" the OPNsense VM, so a double NAT takes place here. Here is the list of IP addresses:
| 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 |
Preparation
After installation and integration into my network, I first changed the port for the administration website. In the standard configuration, the administration interface listens on port 443 (https). However, I would like to use port 443 for Exchange. I have decided to use port 4444.
The required plugins are then installed. The plugin "os-acme-client" is the plugin for Let's Encrypt, "os-haproxy" takes over the publication of Exchange. As my environment is a VM on ESXI, I have also installed the VMware tools:
In addition to the corresponding network configuration, that was all the preparations.
Firewall
After OPNsense was integrated into my network, I first created two firewall rules that allow http and https traffic on the WAN port:
For both rules, "WAN" is selected as the interface and "TCP" as the protocol. HTTP" is selected as the target port range for one rule and "HTTPS" for the second rule.
After creating the two rules, it looks like this:
One rule for HTTP and one rule for HTTPS. This means that external traffic is already permitted. We continue with HAProxy.
HAProxy
We continue with the basic configuration of HAProxy for Exchange 2016. In the HAProxy settings, the Exchange server is first created as a real server:
I have set up the Exchange Server as follows, I have switched off the option "Check the SSL certificate" because Exchange uses a self-signed certificate:
As soon as the server has been created, a BackEnd can be created:
The following settings are made for the backend:
Now an ACL is created, for this test I make it simple and only create one ACL:
The following settings apply to the ACL:
Once the ACL has been created, an "Action" is created:
The following is configured for the action:
Finally, the front end is created:
The following settings are used for the front end. The IP address 192.168.10.107 is the WAN IP address of the OPNsense firewall (NAT behind Fritzbox) plus the HTTPS port (443). In this case 192.168.10.107:443
Since a certificate from Let's Encrypt still exists, I initially use the standard certificate for the Web GUI. This allows the configuration to be tested. Furthermore, the "X-Forwarded-For header" is also activated:
These settings are defined in the advanced settings of the front end;
HAProxy can then be activated:
If HAProxy was already activated, it is best to restart it once.
Now OWA is already working, but since there is no valid certificate yet, there are of course certificate warnings:
The Let's Encrypt plugin can now be configured.
Let's Encrypt
Let's Encrypt offers the option of integration via the "Staging environment" to test. For officially valid certificates, Let's Encrypt has Limitations This means, for example, that it is not possible to issue an unlimited number of certificates. For tests, it is therefore advisable to start with the staging environment and only switch to the "production environment" when everything is working.
In this case, the staging environment is also used first:
As soon as the plug-in has been activated, the account can be created:
Only one e-mail address is required for the account:
The verification method can now be configured:
I left HTTP-01 as the verification method, and I also had to explicitly specify the WAN IP in my environment, otherwise no connection could be established. The previously created "Exchange_2016_Frontend" is selected as the FrontEnd:
NoteThe Exchange 2016 frontend was only configured on port 443 (HTTPS), but Let's Encrypt checks the domain with the validation method HTTP-01 on port 80 (HTTP), so I created an additional FrontEnd on port 80 (HTTP) for Let's Encrypt:
The IP of the WAN interface is also specified for the Let's Encrypt frontend, but this time with port 80. "acme_challende_backend", which was created by the plugin, is selected as the default backend. The same applies to the "redirect_acme_challanges" action:
Back to the Let's Encrypt plugin, where the certificate can now be configured:
My Exchange server is named mail.frankysweb.de for all web services (ActiveSync, Outlook Anywhere, EWS, etc) and autodiscover.frankysweb.de for Autodiscover. I therefore specify the following values for the certificate:
Once the certificate has been configured, it is in "Pending" status, so the certificate can now be selected and the "Issue or renew certificate now" button clicked:
After a short time, you will see "OK" under "Last Acme Status":
The test certificate issued by the Let's Encrypt Staging Environment can now be seen in the certificate overview. It was issued by the "Fake LE Intermediate X1":
In order to obtain a valid certificate, the Let's Encrypt environment can now be switched to "Production Environment":
Once the "Production Environment" has been selected, the certificate must be reissued:
The valid certificate issued by the CA "Let's Encrypt Authority X3" can now be seen in the certificate overview:
Finally, the certificate only needs to be assigned to the Exchange frontend:
The valid certificate can now be selected in the frontend settings:
Now certificate warnings no longer appear:
Conclusion
The configuration is a little more complex than initially thought. While I was writing this article, an update for the HAProxy and Let's Encrypt plugins was released in the meantime, so I started again from scratch to test it with the current version.
This configuration works, but is far from perfect. I need to familiarize myself with the ACLs and actions in order to create a reasonable configuration. For a first test, however, it is quite promising.
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