Archiv der Kategorie: pfSense

Exchange 2016 Reverse Proxy mit pfSense 2.4 und HAProxy

Motivation für diesen Beitrag: Veröffentlichung von Exchange 2016 mittels Reverse Proxy und vorhandener pfSense. Es bietet sich HAproxy an, denn es gibt ein recht gut gepflegtes Package dafür. Weiterhin besteht die Möglichkeit neben dem Loadbalancing auch ACLs zu nutzen um z.B. Pfade zu filtern. Oftmals wird es nicht genutzt weil die Verknüpfung der Frontend ACLs nicht so trivial ist. Um euch die Einarbeitung zu ersparen habe ich mal schnell ein paar Screenshots gemacht. Diese sollten bei euch direkt zu einem „Aaaahhh“ Effekt führen. Ich fange jetzt nicht an wie man das Package installiert und die HAproxy Grundeinstellungen macht wie Zertifikate einspielen oder die Stats-Seiten aktivieren etc.
Ich nutze für mein Beispiel mal den Fall von zwei Anwendungen die über eine externe IP per Subdomain zugänglich gemacht werden sollen. Der primäre Service ist natürlich der Exchange, der zweite Dienst wird „shared“ eingerichtet:Wir benötigen ein Frontend auf die externe IP und den Realserver (Exchange) im Backend. Hier meine Definition vom Backend für den Exchange 2016:

Wenn man mehrere Exchange Server im DAG Cluster betreibt, muss man einfach die weiteren Realserver unter Punkt 2 hinzufügen.
Nun gehts an Frontend. Hier der Überblick über die zwei angelegten Frontends:

In der Definition vom Frontend entscheidet sich welche URL wird aufgerufen, welcher Port und welcher Pfad.
Grundlegend wird festgelegt auf welche IP (WAN Address) und Port der Service hören soll:
Nun werden die ACL und ACTION erstellt. Das ist wohl der Grund warum viele Howtos hier mit einer einfachen TCP Weiterleitung vorlieb nehmen. Dabei ist das gar nicht so schwer:
Folgende Annahme: die externe URL ist „exchange.domain.tld“ und der Pfad „/owa“ oder „/mapi“. Also der Aufruf wäre https://exchange.domain.tld/owa.
Wenn nun eine Anfrage am HAproxy ankommt, muss er diese Anfrage in URL und Pfad zerlegen, erkennen und verarbeiten können. Dafür müssen wir als erstes einige Definitionen unter „Access Control lists“ anlegen die wir in den „Actions“ nutzen können. Den Hostnamen legen wir als ACL „hostname_exchange“ mit der Bedingung „Host matches“ und dem Wert „exchange.domain.tld“ an. Anschliessend definieren wir die Pfade mit der ACL „path_exchange“ mit der Bedingung „Path contains“ und den entsprechenden Werten der Pfade wie „/owa, /mapi etc“. Diese kann man bei „Path contains“ durch Leerzeichen getrennt eingeben.
Nun können wir aus diesen zwei Bedingungen eine „Action“ bauen. Beide Bedingungen müssen ja zutreffen. Damit die beiden angelegten Bedingungen auch „UND“ verknüpft werden, muss man sie in der „Action“ bei „Condition acl names“ einfach hintereinander durch Leerzeichen getrennt hinschreiben. Wenn also die Bedingung „hostname_exchange“ und „path_exchange“ zutreffen wird auf das Backend „Exchange_Backend“ weitergeleitet. Jede andere nicht definierte URL oder Pfad wird mit einem Fehler seitens des HAproxys quitiert.
Nun noch das Zertifikat für dieses Frontend angeben:
Jeder andere Service wird wie dieser Exchange als „shared“ Frontend veröffentlicht:

APU2C4 Bausatz mit pfSense installieren

Hier wieder eine kleine Quickdoku wie man einen APU2C4 Bausatz assembliert und mit pfSense installiert. So wird der Bausatz geliefert und los geht’s:
APU2C4-Bausatz
Kühlung anbringen:
APU2C4-Kuehlung
mSATA einsetzen:
APU2C4-mSATA
Jetzt kann das System installiert werden. Dazu benötigen wir von der Webseite des Herstellers das „TinyCore Linux“ , welches mittels USB Stick gebootet wird. Zuerst muss die Datei „apu2-tinycore6.4-usb-installer.exe“ geladen und ausgeführt werden. Das Setup wird das TinyCore Linux auf einem leeren USB Stick installieren. Das Image von pfSense wird im Anschluss auf den USB Stick kopiert und nach dem booten des TinyCore Linux auf die mSATA geschrieben. Der Bootvorgang und die erste  Bedienung des Boards erfolgt mit der seriellen Schnittstelle (115200 Baud 8n1). Als Terminalprogramm nutze ich Teraterm.
APU2C4-firstboot
Mit „fdisk -l“ lassen wir uns die Partitionen anzeigen. In meinem Fall wird die mSATA unter /dev/sda gefunden:
pfsense_2
Nun das Image mit dem Befehl „gzip -dc pfSense-CE-2.3.2-RELEASE-4g-amd64-nanobsd.img.gz | dd of=/dev/sda bs=1M“ auf die mSATA Partition schreiben:
pfsense_3
pfsense_4
Wenn das Image geschrieben worden ist, das System mit „poweroff“ herunterfahren, den USB Stick entfernen und die pfSense Firewall zum ersten Mal starten und mit der Grundeinrichtung beginnen….. Leider muss die pfSense Firewall beim ersten Bootvorgang mit dem Internet verbunden sein, denn sonst wird die Prüfung des Paketmanagers in einer Schleife „hängen“ bleiben. Zum Glück hatte ich gerade noch einen Mikrotik Router am Netz hängen den ich schnell als Gateway bereitstellen konnte:
DSC_0614_small
Das wars….. Nun können wir das System über die WebGUI verwalten:
pfsense_5

„Smart Repair“ für Postfix unter pfSense 2.2.x

pfSense_LogoWie schon berichtet wird das Packet „Postfix Forwarder“ nach dem Update der pfSense auf Version 2.2.x unbrauchbar gemacht. Hier eine kurze Anleitung wie man Postfix wieder zum Laufen bekommt. Zuerst den Postfix Konfigurationsordner wegsichern. Ich nutze dafür WinSCP. Der Ordner /etc ist ein symbolischer Link von /usr/local/etc in den PBI Ordner /usr/pbi/postfix-amd64/etc/postfix. Die darin enthaltenen Dateien komplett wegsichern:

pfSense_Postfix_1

Jetzt das Paket „Postfix Forwarder“ vollständig deinstallieren. Den Inhalt des Ordners habe ich bei meiner Installation vollständig gelöscht: „rm -r /usr/local/etc/postfix/“ oder mit WinSCP. Die pfSense am besten neu starten und das Paket wieder installieren. Nun die Konfigurationsdaten wieder per WinSCP zurücksichern. Postfix vermisst nach der Re-Installation drei wichtige Libraries im Systemordner und stürzt ab. Diese fehlenden Libraries müssen wir manuell nach /usr/lib/ kopieren:

Wer SASL AUTH für einen Relayhost nutzt, erhält folgende Fehlermeldung: „smtp_sasl_auth_enable is true, but SASL support is not compiled in„. In diesem Fall müssen noch die Cyrus SASL Libraries nachinstalliert werden. Mit PKG geht das ganz einfach:

Sollte PKG noch nicht genutzt worden sein, einfach „pkg“ tippen und mit „y“ beantworten. Damit wird PKG installiert. Zuerst das Repository auf den neusten Stand bringen mit „pkg update„. Jetzt sollte Postfix nach einem Reload laufen:

Nachtrag: Die Fehlermeldung „PHP Fatal error:  Call to undefined function sqlite_open() in /usr/local/www/postfix.php on line 457“ erscheint auf dem Dashboard wegen einer inkompatibilität von SQLite. Bis dieser Fehler behoben ist sollte man den Logtransfer in SQLite abschalten:

pfSense-Postfix-SQlite

pfSense Upgrade 2.2 zerstört Postfix Paket

Endlich hat das pfSense Team die Version 2.2 mit vielen Neuerungen (FreeBSD, ipsec, etc) freigegeben. Leider musste ich feststellen, das eine (zum Glück!) virtuelle Installation mit dem Postfix Paket nach dem Upgrade nicht mehr lief. Ein Artikel dazu gibt es auch im Forum. Dank Snapshot ging es schnell wieder zurück zur Version 2.1.5. Also alle die Postfix Forwarder in der pfSense nutzen: warten bis der Fehler behoben ist.
installation_Konsole

Eine Bemerkung von Diego Holzer möchte ich direkt hier in den Beitrag aufnehmen, weil diese wertvolle Information sonst evtl. überlesen wird:

Habe die gleiche Erfahrung gemacht. Habe für zuhause drei pfSense Appliance.
Internet Transfer (1) Firewall (2) DMZ (3).

Aus eigentlich recht guten Erfahrungen habe ich die Appliance von 2.1 auf 2.2 upgradet.

Auf der Transfer läuft NUT als Einspeisesignal der USV. Zusätzlich ist da noch pfBlocker installiert, um die ganzen Spammer fern zu halten.
Das Upgrade ging ohne Probleme, nur das pfBlocker Paket hat sich verabschiedet. Neu heisst das Paket pfBlockerNG und muss komplett neu konfiguriert werden.

Die Firewall hat ebenfalls NUT als Slave installiert, hat ansonsten nur noch OpenVPN Config Exporter installiert. Hier lief alles ohne Probleme.

Auf der DMZ kam dann das Highlight. Postfix Forwarder und Squid. Ging dann einen Moment, bis man realisiert, dass Postfix keine Nachrichten mehr annimmt. Auch Squid läuft nicht mehr. DNS Redirectfehler und wenn man diesen ausschaltet, hat man gleich das WebIf im Internet.

Fazit: 2.2 ist eine gute Sache, leider sind die Pakete Postfix Forwarder und Squid3 noch nicht brauchbar.

Vielen Dank für diesen Kommentar und viel Spaß weiterhin mit der pfSense!

Exchange mit pfSense veröffentlichen (Squid Reverse Proxy)

Die Veröffentlichung von Outlook Web Access, ActiveSync und Outlook Anywhere (RPC over HTTPs) ist mit der pfSense absolut easy einzurichten. Externes Zertifikat im Cert Manager hinterlegen, das Package Squid Proxy 3.1 installieren, ein paar Mausklicks und los geht’s. Ich habe zwar eine virtuelle Maschine in unserer DMZ die diese Freigabe mit mod_proxy_msrpc über Apache regelt, aber in kleineren Umgebungen kann man mit den Bordmitteln der kostenlosen pfSense sehr schnell das gleiche Ergebnis erzielen. Der Kompromiss ist meiner Meinung nach absolut in Ordnung. Also – Let’s Klick and Go:
System -> Cert Manager
SQUID_Cert
System -> Packages
SQUID_package1
Services -> Reverse Proxy
SQUID_Reverseproxy1 SQUID_Reverseproxy2
Der HTTPS Port 443 muss von extern natürlich erreichbar sein:
Firewall -> Rules -> INTERNET
SQUID_FW_Rule1
Check des Logfiles
SQUID_Logfile
So sieht die Konfiguration aus. Kann man auch in jedem „normalen“ Squid nutzen: