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:
In der Übersicht der Zertifikate ist nun das gültige Zertifikat zu sehen, welches von der CA “Let’s Encrypt Authority X3” ausgestellt wurde:
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.