Archiv der Kategorie: Firewall

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:

Mikrotik RouterOS: Not-so-full-Mesh mit Transit Fabric , Dual Provider und OSPF Failover

Seit einiger Zeit spiele ich mit RouterOS von Mikrotik. Ein besseres Preis- Leistungsverhältnis findet man selten bei solchen Produkten. Durch die Mikrotik MUM Vorträge kam ich auf die Idee mein berühmtes Multi-Provider-Failover-OSPF Setup mit Mikrotik umzusetzen. Das ist dank der vielen unterstützten Protokolle und Funktionen absolut kein Problem. Mikrotik Router sind halt keine UTMs, sondern wirklich nur Router. Daher kann man deren Einsatz z.B. vor einer Sophos UTM planen. Ein Transfernetz zwischen Mikrotik und Sophos UTM trennt klar die Aufgaben. Jeder macht was er am besten kann: Routing und Tunnel graben übernimmt Mikrotik, das Filtern und Scannen wird durch die UTM erledigt.
Die Testumgebung besteht aus zwei virtuellen MikroTik Routern, die zwei simulierte Internetprovider haben. Diese werden wie immer durch einen dritten Router simuliert. Niemals reine L2 basierende Host-Only Netzwerke zwischen den Routern nutzen! Hinter den Testroutern liegen jeweils die Standortnetzwerke 192.168.30.0/24 und 192.168.40.0/24:
Um nun von 172.22.1.201 zu 172.24.1.201 einen Tunnel „T2“ zu etablieren verwende ich einen einfachen Trick: Ich setze eine Hostroute zu 172.24.1.201 über das Gateway von 172.22.21.201. Somit wird die Verbindung nicht über das im Routing priorisierte Gateway von 172.22.1.201 aufgebaut – was in meinem Fall Tunnel „T3“ entspricht und somit sinnbefreit wäre.

Nun definieren wir von jedem Provider aus einen Mikrotik proprietären EOIP Tunnel. Dieser kann auch mit IPSEC abgesichert werden. Streiche „kann“ und setze „muss“! Hier mal ein Beispiel-Screenshot für den zweiten Tunnnel, der mittels Hostroute zwischen den beiden zweiten Providern aufgebaut wird:

Jetzt die Netzwerke der Tunnel und Standorte noch ins OSPF eintragen. Iim Screenshot ist noch die Loopback zu sehen. Diese Loopback IP bitte immer als RouterID nutzen bei OSPF:

Nun werden die Standorte über alle Tunnel per OSPF gefunden:
Wenn bei den Providern unterschiedliche Bandbreiten genutzt werden, so empfehle ich die Einteilung der einzeln Tunnel in VLANs. Damit kann man das Loadbalancing steuern:

Hier der Link zu der PDF Version des MUM-Vortrags: KLICK

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

OpenVPN Server unter MikroTik RouterOS

Ja ja – lange nichts mehr geschrieben. Aber ich lebe noch und habe gerade eine OpenVPN Odyssee mit MikroTik Routern hinter mich gebracht. Warum? Ihr kennt es: Man googelt hoch motiviert nach einem knackigen Howto und entdeckt lauter Blogs, die mit viel Halbwissen gefüllt sind. Man merkt das die meisten noch nie ein OpenVPN unter Linux konfiguriert haben, geschweige denn den Unterschied zwischen TUN und TAP kennen. Sei es drum. Du hast diese Doku gefunden und sollst nicht enttäuscht werden, denn sie funktioniert 🙂
Erst mal die Zertifikate und Schlüssel mit OpenSSL bauen. Zu kompliziert? Stimmt. Dafür gibt es ja auch Easy-RSA. Zuerst die Datei „vars“ editieren und die gewünschten Parameter anpassen:

Dann bosseln wir schnell die benötigten Certs und Keys mit den folgenden Befehlen zusammen:

Zuerst importieren wir die Zertifikate. Die Certs am besten mit WinSCP auf den MikroTik Router kopieren:

OpenVPN-Server-Files-WinSCP

In der Winbox ins System importieren (System > Files > Import):

OpenVPN-Server-Files

Der Buchstabe „K“ erscheint sobald der Key zum passenden Zertifikat gefunden wurde:

OpenVPN-Server-Cert-Import

Jetzt legen wir ein Profil für OpenVPN Server an. Damit bestimmen wir die lokale Server-IP für den OpenVPN Adapter (TUN/TAP) und den IP-Pool der Remote Clients (PPP > Profiles):

OpenVPN-Server-Profiles

IP Pool. Gute Sache. Bevor man diesen auswählen kann, muss er erzeugt werden (IP > Pool):

OpenVPN-Server-IP-Pool

Jetzt kann der eigentliche OpenVPN Server aktiviert werden (PPP > OVPN Server):

OpenVPN-Server-Setup

Zum Einwählen fehlt noch ein Benutzer mit Passwort (PPP > Secrets):

OpenVPN-Server-Secrets

Das war’s jetzt auf dem MikroTik Router. Nun geht’s auf dem WIndows Client weiter. Folgende Dateien und Config in den Programmordner von OpenVPN kopieren:

OpenVPN-Server-Client-1

Hier meine Beispielkonfiguration:

Verbinden uns loslegen:

OpenVPN-Server-Client-1-Einwahl

Kleiner Ping aufs Gateway und das war’s:

Einwahl-mit-zwei-Testclients-Client2

Sophos UTM mit IPsec „Hub and Spoke“

Um die Realisierbarkeit eines Projektes zu überprüfen, habe ich einen Testaufbau mit einem „Hub and Spoke“ Szenario durchgeführt. Bei „Hub and Spoke“ wird der Traffic von einer per IPsec angebundenen Außenstelle (Remote Office) zur anderen über eine Zentrale Instanz (Main Office) weitergeleitet. Hier der schnell entworfene Plan und danach die Umsetzung:
Sophos-Hub-and-Spoke
Man muss lediglich das entfernte Remote Office in die Remote IPsec Konfiguration einfügen. Bei der Definition im Main Office als auch bei der Außenstelle muss das Netzwerk der entfernten Außenstelle eingetragen werden. Zum Beispiel wenn der Traffic von Sophos-3 zu Sophos-2 über Sophos-1 geleitet werden soll.
Hier die Definition im Main Office als Respond Only:
sophos-3-rem-def    sophos-3-def
Die Definition auf Sophos-3 mit Initiate Connection:
sophos-3-def-remote
Nun wird der Tunnel aufgebaut und die IPsec SA für die entfernte Außenstelle ist enthalten:
sophos-3-result
Im Main Office sind zwei Tunnel zu den Außenstellen aufgebaut. Der Traffic von Sophos-2 zu Sophos-3 wird durch den IPSEC Tunnel über das Main Office Sophos-1 geleitet:
sophos-result-ping