Archiv der Kategorie: Firewall

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.

„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