Archiv der Kategorie: Sophos UTM

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

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

Sophos XG Firewall – Erste Eindrücke

Sophos_XG_LogoMontagmorgen. Mal schnell die neue OVF der Firewall XG hochgeladen und… ja… und… erst mal nix. Erst mal muß ein total nerviger Aufwand mit der Registrierung betrieben werden um überhaupt die ersten Gehversuche zu machen. Die Konsole ist gesperrt und man kann nicht mal eben mit ifconfig die IP ins interne LAN setzen, sondern muss einen Clientrechner ins 172er Netz bringen um die quälende Prozedur der Registrierung hinter sich zu bringen. Ich hasse es wenn es mir so schwer gemacht wird. Ein offline Test ist also absolut unmöglich. Den Rechner erst mal ins Netz der XG packen, z.B. 172.16.16.100/24. Dann sollte die Default-IP der XG mit 172.16.16.16 erreichbar sein.
Install_1Install_2
Jetzt mit dem Browser über https://172.16.16.16:4444 die Grundeinrichtung vornehmen:
Install_4 Install_5 Install_6
Wenn man diese ganze Prozedur über sich hat ergehen lassen, so kann man endlich das Dashboard in Augenschein nehmen. Erster Eindruck von mir – das will man nicht 🙁
DASHBOARD_0
Das wird einige Zeit dauern bis man sich von einer UTM auf die neue XG „umgewöhnt“ hat. Hier einige weitere Impressionen der Oberfläche. Was beim VPN auffällt: wo sind die RED Tunnel? Schnell im FAQ nachgesehen -> ist noch nicht drin 🙁    Sophos XG FAQ
VPN_1So sehen die neuen Seiten für die Firewallregeln aus:
FW_1 FW_2       FW_3

Jetzt werde ich erst mal den ersten Eindruck setzen lassen und eine Migration von einer bestehenden UTM ausprobieren. Die meisten Migrationen werden wohl erst mal an dem nicht vorhandenen RED Device scheitern, welches ich für das OSPF Routing benötige….

Sophos UTM: Kundenprojekt im Rechenzentrum von LuxConnect

Sophos-D2Ein schönes Kundenprojekt welches hier Erwähnung finden sollte: Ich habe für einen der größten deutschen Kaffeehersteller im Rechenzentrum „LuxConnect“ in Luxemburg eine alte Firewall durch einen Sophos UTM Cluster abgelöst. Die von mir damals installierte und in die Jahre gekommene Linuxfirewall mit Heartbeat, IPTables und OpenVPN musste ersetzt werden. Da die Sophos UTM ebenfalls eine sehr gute Unterstützung von OpenVPN bietet, konnten die bestehenden Standorte an die neue UTM angebunden werden, ohne jede Außenstelle mit neuer Firewallhardware zu versorgen. Diese können nun ohne Zeitdruck sukzessive ausgewechselt werden. Vorhandene IPSEC Tunnel konnten ebenfalls ohne Probleme migriert werden. Eine weitere aktuelle Success Story zu Sophos UTM finden Sie unter der Rubrik „Projekte„.

Sophos UTM: Transparent AD SSO Konflikt mit SSL VPN

Damit es anderen Admins nicht so wie mir ergeht: SSLVPN auf Port 443 ist zwar schön um aus Hotel-WLANs und Länderzone drei ein VPN aufbauen zu können, aber es gibt unschöne Kollisionen mit den Active Directory SSO. In den Webfilter Einstellungen kann man die SSO Abfragen zum DC an ein Interface binden:
sophos-adsso-errorDamit gibt es keine Konflikte mehr mit dem SSLVPN, welche sich in Disconnects der über AD authentifizierten Benutzer bemerkbar machen. Ich hoffe damit einigen Kollegen das ewig lange Suchen zu ersparen…. Hier der entsprechende Eintrag in der Spohos Knowledgebase.