OPNsense S2S mit Wireguard, FRR und OSPF

Durch ein Projekt hatte ich die Chance, eine Site-2-Site Vernetzung mit Wireguard umzusetzen. Dazu gibt es genug Howto’s und Youtube Videos. Bei allen wird jedoch lediglich ein einfaches Setup durchgeführt, wo das jeweils gegenüberligende Netz statisch in der Konfiguration eingetragen und dadurch die Route lokal gesetzt wird. Bei einer Änderung der Netzwerke muss jedesmal die Konfiguration angepasst werden. Gerade bei Hub and Spoke VPNs über mehrere Standorte ist es viel Arbeit diese Änderungen zu pflegen. Schön wäre es, wenn man per OSPF einfach diese Topologieänderungen publizieren, und wenn nötig einfach die Firewallregeln anpassen könnte. Das ist mit Wireguard recht einfach möglich wenn man die folgenden Punkte berücksichtigt und umsetzt. Hierzu ist wichtig wie man in Wireguard die Remotenetze definiert. Der Parameter „Allowed IPs“ ist hier wirklich sehr irreführend, denn er beschreibt eigentlich eher die „Remote Networks“. Bei einem „Roadwarrier“ wird als „Allowed IPs“ gerne die Definition „0.0.0.0/0“ gesetzt. Damit wird der Split-Tunnel entfernt und der ganze Traffic in den Tunnel geroutet. Genau dieses Verhalten werden wir uns zunutze machen. In der Konfiguration des Endpoints gebt ihr die Definition „0.0.0.0/0“ bei dem Reiter „Allowed IPs“ ein:

Damit spendiert ihr eurer OPNsense ein neues Default Gateway (also Vorsicht bei Fernwartungen!):

Dieses Verhalten könnt ihr beeinflussen wenn ihr vorher in der lokalen Konfiguration folgenden Haken setzt:

„Disable Routes“ bewirkt nun das zwar alle Netze in den Tunnel „dürfen“, aber nicht als lokale statische Routen gesetzt werden. Nun stimmt das Default Gateway wieder und der Tunnel ist aktiv ohne das Routen gesetzt sind und Traffic dorthin geroutet wird.

Das entsprechende Remotenetz muss nun entweder mit statischen Gatewayrouten oder mit dynamischen Routen gesetzt werden. Da wir uns das Leben gerne einfach machen, nutzen wir natürlich FRR und OSPF Routing. Meine internen Testnetze 192.168.40.0/24 und 192.168.30.0/24 konfiguriere ich in die Area 0.0.0.1 und 0.0.0.2.

Das Interface „Wireguard0“ wird auf beiden Seiten in die Backbone Area 0.0.0.0 konfiguriert:

Im Wireguard Transfernetz habe ich die Endpoints 192.168.169.1 und .2 gewählt. In der Routingtabelle sieht man nun schön, das der Weg ins Remotenetz per OSPF über das Transfernetz geht:

Jede weitere Site und jedes weitere Netz das auf einer Site hinzugefügt wird, kann durch anpassen der OSPF Netzwerke und Areas in allen Standorten veröffentlicht werden. Durch die Anpassung der Firewallregeln könnt ihr bestimmen wie der Zugriff auf die Netze erfolgen soll. Ich hoffe das ihr nun eine Anregung bekommen habt, wie ihr ein komplexeres Setup mit Wireguard und OSPF durchführen könnt.

Kleine Anmerkung für die pfSense User: hier wird die Option „Disable Routes“ leider (noch) nicht angeboten:

Nachtrag: Für jeden Peer muss eine eigene Wireguard Instanz angelegt werden, denn 0.0.0.0/0 kann nur einmal pro Instanz definiert werden. Also für jeden Link eine neue lokale Instanz mit eigenem Port und wgX Interface:

OPNsense mit OpenVPN, FRR und OSPF (QAD)

Quick and Dirty Howto wie man einen OpenVPN Tunnel ins OSPF aufnimmt. In meiner Testumgebung bilden zwei OpenVPN Tunnel im TUN Mode die Area 0.0.0.0 und das jeweils dahinter liegende Testnetz 192.168.30.0/24 die Area 0.0.0.1 und 192.168.40/24 die Area 0.0.0.2.

Die beiden Tunnel nutzen das Netz 172.31.55.0/30 und 172.31.56.0/30. Leider ging es mit dem nächsten /30 Netz von 172.31.55 nicht. Es musste ein neues Netzsegment genutzt werden. Kann natürlich auch ein Bug in FRR sein. Jedenfalls wird ein „OpenVPN“ Interface in OPNsense erzeugt. In FRR muss dieses Interface mit in die OSPF Konfiguration:

Danach die Areas und die zu distributierenden Netzwerke definieren:

Und schon sieht man das gegenüberliegende Netz in der Routingtabelle:

Mimosa Wifi PTP Bridge Failover mit Mikrotik Router

In unserer Firmengruppe wurde eine Lagerhalle, die sich in Sichtweite auf einem anderen Grundstück befindet, mit einer Wifi Bridge ans Firmennetz angebunden. Eine schwache 1MBit VPN Leitung konnte damit abgelöst werden. Als primäre Bridge habe ich mich für Funktechnik von Mimosa entschieden. Diese schafft es auf 520MBit. Als Failover Richtfunkstrecke kommt günstigere Technik mit weniger Bandbreite von Mikrotik zum Einsatz. Beide Bridges waren direkt an Cisco Switche angeschlossen. Failover mit STP war möglich, aber bei kleinen „wacklern“ auf der Funkstrecke musste der STP jedesmal neu berechnet werden und hat zum Ausfall mehrerer Dienste geführt. LACP habe ich versucht, wurde aber eines Besseren belehrt was asynchrone Bandbreite und Latenzen im LACP so anstellt. Es ist einfach nicht möglich. Also musste etwas her das ich von Linux nativ als „Bonding Mode“ kenne. Mikrotik Routerboards können neben LACP (IEEE 802.3ad) auch die Linux Bonding Modes. Also zwei Routerboards gekauft und die zwei Richtfunkstrecken im Bonding-Mode in eine Software-Bridge gepackt. Läuft wunderbar im Aktiv/Passiv Modus und schaltet auch sehr schnell um. Somit kriegen die Cisco Switche und deren STP nichts von den „wacklern“ auf den Funkstrecken mit.

Labortest mit OPNsense (Sophos UTM Ersatz?)

Ich betreibe pfSense schon seit dem Ende der M0n0wall auf einigen Produktivsystemen im Kundeneinsatz. Nun wollte ich mir den Fork „OPNsense“ mal genauer ansehen, weil dieser selbst vom ehemaligen Entwickler der M0n0wall empfohlen wird, und habe eine gößere Testinstallation in meiner VMware Umgebung ausgerollt. Ich habe alles ausprobiert was ich immer so in einer Netzwerkinfrakstruktur simuliere: MultiWAN, AD Integration, HA Proxy, Postfix Mailgate und dynamisches Routing über VPN Tunnel mit routed IPsec und OpenVPN. Das MultiWAN simuliere ich über einen ebenfalls virtuellen Mikrotik Router der vier WAN Interfaces bereit stellt. Hochverfügbarkeit ist ebenfalls in Form von CARP verfügbar.
Eins vorab: Eine Sophos UTM (vor allem nur mit Network Protection) kann man damit locker ersetzen! IT Entscheider sollten sich folgende Frage stellen: „Kann ich auf externe Ressourcen und Support zurückgreifen die mich unterstützen?“. Open Source ist gut – aber sie will auch verstanden und beherrscht werden. Sophos UTM oder XG bieten viele Systemhäuser an und es ist genug Know How auf dem Markt vorhanden. Daher hat die kommerzielle Variante mit ihren Kosten für evtl. Appliance Garantie und Support auch ihre Berechtigung. Auch wenn unter der Haube fast alle Dienste identisch sind und man sich nur durch die GUI unterscheidet. Ich versuche mal erste Eindrücke zur freien OPNsense mit Hilfe von Screenshots zu vermitteln. Wie gesagt, sie ist ein mächtiges Werkzeug und es geht hier nur um die Weitergabe meiner Erkenntnisse. Ich konnte jedenfalls alle Einsatzszenarien der UTM in unserem Unternehmen sehr einfach mit OPNsense abbilden. Ein wichtiger Grund sich über eine Migration von pfSense zu OPNsense Gedanken zu machen war für mich unter anderem auch das die Entwickler von pfSense das Postfix Mailrelay gegen alle Einwände der Community aus ihrer Firewall verbannt haben. OPNsense jedoch hat Postfix als Relay sehr gut integriert und kann ideal als Mailproxy vor einem Exchange eingesetzt werden. Howtos zu den einzelnen Themen werde ich noch veröffentlichen.
Das Dashboard ist aufgeräumt und kann auf die eigenen Bedürfnisse angepasst werden:

Das Erstellen der Firewallregeln ist Interface bezogen und entspricht nicht der typischen globalen „Input / Output“ Verfahrensweise wie mit iptables unter Linux, aber man gewöhnt sich sehr schnell an das Funktionsprinzip bei OPNsense:

IPsec (hier im im routed Modus mit VTI) und OpenVPN haben gut administrierbare GUIs:

Anschliessend noch die Einrichtung des dynamischen Routings mit FRR und OSPF:

Viele Reporting Möglichkeiten mit Netflow, Squid Proxy als Webfilter, Postfix als Mailrelay und viele weitere Plugins machen die OPNsense zu einem wirklich guten UTM Gateway. Das angeeignete Know How wird in einer größeren Installation bei einem Kunden zum Einsatz kommen. Für Anfragen zur Integration oder Migration stehe ich gerne zur Verfügung.

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: