Bei einem Kunden sollte auf der Bestandshardware, ein 2011er Black Dwarf und eine RC100 von 2014, die Securepoint-Firmware durch pfSense ersetzt werden. Hintergrund der Massnahme war der Wunsch kosten zu sparen.

Im vorliegenden Szenario ging es lediglich darum die Firewall-Regeln als auch die VPN-Konfiguration zu übernehmen. Andere Teile der Securepoint UTMs wurden nur rudementär verwendet.

Vorbereitung ist alles

Das Vorhaben ist nichts für mal auf die Schnelle und Zwischendurch. Wir hatten zwischen der Ankündigung des Kunden die Lizenzen nicht verlängern zu wollen und dem Ablaufdatum nur acht Tage, inkl. Wochenende, Zeit. Theoretisch genug Zeit, aber man hat ja noch andere Projekte und Termine, von Überraschungen ganz zu schweigen.

Zur Vorbereitung sollte man, sofern nicht vorhanden, den aktuellen IST-Zustand in Sachen Firewall-Regeln, Benutzer, Zertifikate usw. dokumentieren. Die meiste Konfiguration muss im Rahmen von Fleißarbeit manuell übertragen werden. Soll heißen: Firewall-Regeln als auch Benutzer müssen von Hand angelegt werden, Zertifikate werden mittels Export aus der Securepoint UTM ausgegeben und dann via copy & paste über einen Text-Editor in pfSense eingefügt.

Um unnötige Ausfallzeit zu vermeiden, stellten wir dem Kunden Leihsysteme, die bereits mit pfSense vorinstalliert und mit der vorbereiteten Konfiguration bestückt waren bereit. So musste am Tage der Umstellung “nur” jeweils kurz die Kabel umgesteckt werden und im Anschluss konnte die Securepoint-Hardware uminstalliert werden.

Hardware

Wie eingangs erwähnt, wurde beim Kunden sowohl ein Black Dwarf als auch eine RC100 uminstalliert. Mittels Vorbereiteten USB-Stick war das keine große Sache. Lediglich im BIOS der Geräte musste die Bootreihenfolge der Festplatten (der Stick wurde als USB-Festplatte erkannt) geändert werden.

Nicht wundern darf man sich darüber, das die Installation bei 38% einige Zeit “hängt”. Im Falle des “Zwergs” wird auf eine 1 GB CompactFlash-Karte installiert, das dauert ca. 15 Minuten. Bei der RC100 immerhin auf eine 120 GB SSD, dort dauerte es ebenfalls mehrere Minuten.

Apropos 1 GB Festspeicher: Das Setup von pfSense merkt an, das 1 GB recht knapp ist und im Falle eines Crash etc. nicht allzuviel (zwischen)gespeichert werden kann. 1 GB ist zugleich die Mindestanforderung und reicht für den Betrieb zunächst aus.

Das Bootverhalten zwischen Securepoint OS und pfSense ist höchst unterschiedlich. Zugegebenerweise startet das Lüneburger Linux (Securepoint) wesentlich schneller gegenüber pfSense, andererseits wie oft muss man einen Router schon neu starten?!

Firewall

Ein Hauch vom Securepoint-Handling lässt sich übrigens mittels der Aliase realisieren, wenngleich nicht so umfangreich und folglich, sofern ordentlich gepflegt, so übersichtlich.

Auf jeden Fall sollte man jede Regel mit einer Bemerkung versehen, damit man später noch nachvollziehen kann, wozu sie dient! Alle Regeln müssen neu angelegt werden.

Site-to-site-VPN

Beim Kunden besteht einen Standortvernetzung auf Basis von OpenVPN. Übergangsweise wurde die Kombination Securepoint/pfSense verwendet. Nachdem beide Seiten auf pfSense migriert waren, gab es ein Problem mit dem Routing. Aus welchem Grund auch immer, wurde auf dem Client die Route nicht gesetzt oder selbst wenn Sie manuell gesetzt wurde, nicht verwendet. Statt langwieriger Fehlersuche wurde die Standortvernetzung kurzerhand “abgerissen” und gemäss der Empfehlung in der pfSense-Dokumentation neu aufgebaut. Die bereits konfigurierten Firewall-Regeln bleiben dabei erhalten.

Roadwarrior-VPN

Damit nicht alle Roadwarrior kontaktiert und bei diesen die VPN-Konfiguration geändert werden sollte, bestand eine Vorgab darin, entsprechend das VPN unter pfSense zu gestalten.

Zunächst exportiert man alle Zertifikate inkl. dem CA-Zertifikat aus der Securepoint UTM. Anschließend öffnet man diese mit einem Texteditor, wir verwendeten dazu Notepad++. Zuletzt wurde Zertifikat für Zertifikat mittels copy & paste in pfSense übertragen.

An dieser Stelle der Hinweis, das man nach dem Hinzufügen des CA-Zertifikats die “Serial for next certificate” der Ordnung halber setzen sollte. Dazu das CA-Zertifikat editieren und das entsprechende Feld ausfüllen.

Nachdem die Zertifikate migriert waren, wurden alle Benutzer angelegt und jeweils das Zertifikat zugewiesen. Im nächsten Schritt wird der OpenVPN-Server angelegt, das kann man über den Assistenten oder per Hand tun. Wird der Assistent nicht verwendet, so muss beachtet werden, das eine Firewall-Regeln auf der WAN-Schnittstelle für OpenVPN angelegt werden muss!

Wichtig für die Kompatibilität zu Securepoint sind folgende Einstellungen:

• Den Haken bei “TLS Authentication” entfernen.
• Ggf. bei “Peer Certificate Authority” das CA-Zertifikat auswählen.
• Bei “Encryption algorithm” “BF-CBC (128-bit)” auswählen.
• Im Feld “IPv4 Tunnel Network” das Transfer-Netz in CIDR-Notation, z.B. 10.0.0.0/24, eintragen.
• Im Feld “IPv4 Local Network/s” das entfernte Netzwerk in CIDR-Notation, z.B. 192.168.2.0/24, eintragen.

Den VPN-Benutzern jeweils eine feste IP-Adresse zuordnen

Da nicht jeder Benutzer auf alles im Netzwerk zugreifen können soll, ist es notwendig, jedem VPN-Zugang eine IP-Adresse zuzuordnen. Mit entsprechenden Firewall-Regeln lässt sich folglich reglementieren, ob man z.B. nur auf den Terminalserver via tcp/3389 (msrdp) zugreifen kann.

Damit die Vergabe identisch zu der bei Securepoint bleibt muss zunächst die Option

Allocate only one IP per client (topology subnet), rather than an isolated subnet per client (topology net30).

in der Roadwarrior-OpenVPN-Server-Konfiguration gesetzt sein.

Da in diesem Fall die Kombination aus Zertifikat und Benutzername/Kennwort zur Authentifizierung herangezogen wird, muss bei den “Client Specific Overrides” statt des “Common name” des jeweiligen Benutzerzertifikats der Benutzername angegeben werden:

Aus der Feld-Beschreibung geht das leider nicht hervor und führt einen ggf. zunächst in die Irre. Entspricht der Benutzername dem CN, ist an dieser Stelle nichts zu beachten. Bei dieser Migration musste allerdings darauf explizit geachtet werden, da es Unterschiede gab.

Der konkrete “Advanced”-Eintrag lautet:

ifconfig-push <IP-Adresse> <Subnetz>;

 Beispiel: ifconfig-push 10.0.0.2 255.0.0.0;

Roadwarrior-Konfiguration exportieren leicht gemacht

Damit man den Komfort weiterhin hat, einfach die Konfiguration für einen Roadwarrior exportieren zu können, empfiehlt sich die Installtion des OpenVPN Client Export Package.

Securepoint OpenVPN-Client

Den OpenVPN-Client von Securepoint kann man im übrigen unverändert weiter verwenden. Kommen weitere bzw. neue Roadwarrior hinzu, kann der Client ebenfalls verwendet werden. Man importiert einfach die Konfiguration, die man von pfSense exportiert hat. Kosmetische Unterschiede bestehen darin, das man z.B. in den Feldern “Remote:” oder “Remote Port:” nichts angezeigt wird. Die Einstellungen sind dennoch vorhanden und werden verwendet. Da es allerdings Formatierungsunterschiede in den *.ovpn-Dateien zwischen pfSense und Securepoint gibt und der VPN-Client darauf schlicht keine Rücksicht nimmt, kommt es zu diesen leeren Feldern.

Quellen

fastinetserver – pfSense openVPN static ip for clients (Man beachte die Kommentare!)

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.