Von pfSense zu OPNsense: was bei der Migration wirklich zu beachten ist
Es gibt keinen offiziell unterstützten 1:1-Import einer aktuellen pfSense-Konfiguration nach OPNsense. Eine Migration ist möglich, aber wir würden sie als Neuaufbau mit kontrollierter Übernahme der bestehenden Konfiguration planen, nicht als simples Backup einspielen. Stand: aktuelle OPNsense-Version 26.7.4.
Dokumentieren → Aufbauen → Testen → Cutover
AUSGANGSLAGE
Warum gibt es keinen einfachen Import?
pfSense und OPNsense haben denselben historischen Ursprung und sind beide auf FreeBSD aufgebaut. Auf den ersten Blick sieht eine Migration deshalb einfacher aus, als sie tatsächlich ist.
Seit 2014 getrennte Wege
Die Projekte sind seit dem Fork technisch immer weiter auseinandergelaufen. OPNsense selbst beschreibt, dass inzwischen weniger als 10 % des ursprünglichen Legacy-Codes verblieben sind.
Konfiguration umgebaut
Auch die Konfiguration wurde über die Jahre verändert und teilweise auf neue interne Modelle und APIs umgestellt. Ältere Anleitungen im Netz sind deshalb mit Vorsicht zu genießen.
Formate nicht kompatibel
Im OPNsense-Forum wird ausdrücklich darauf hingewiesen, dass die Konfigurationsformate beider Projekte inzwischen nicht mehr direkt kompatibel sind. Ein früherer pfSense-Importer wurde entfernt.
Unser Ansatz: Die pfSense-Konfiguration ist eine wichtige Vorlage, aber kein fertiges OPNsense-Backup.
INVENTAR
Was lässt sich übernehmen?
Sehr viel von dem, was man für die Migration braucht, ist weiterhin vorhanden, muss aber teilweise manuell neu aufgebaut werden. Die pfSense-Konfiguration sollte deshalb vor allem als Inventar und technische Dokumentation dienen.
- WAN- und LAN-Konfiguration, VLANs
- DHCP-Netze und Reservierungen
- Firewall-Regeln, NAT und Portweiterleitungen, Aliase
- statische Routen, DNS-Konfiguration
- VPN-Konfigurationen und Zertifikate
- Benutzer und Gruppen, Captive Portal, Traffic Shaping, Dynamic DNS
- weitere installierte Pakete und deren Einstellungen
Die XML als Vorlage, nicht als Backup
pfSense speichert die Konfiguration als XML mit eigenen Backup- und Restore-Funktionen. Konfigurationen sind dabei an die jeweilige Konfigurationsrevision gebunden, es gibt also selbst innerhalb von pfSense Unterschiede zwischen älteren und neueren Ständen. Die XML eignet sich hervorragend, um schnell herauszufinden, welche VLANs, Aliase, DHCP-Reservierungen, Portweiterleitungen, VPN-Netze, Zertifikate und CAs vorhanden sind, notfalls automatisiert ausgewertet. Wofür sie sich nicht eignet: pfSense-config.xml → OPNsense → „wird schon passen“. Dafür sind die Systeme zu weit auseinander.
VORGEHEN
Der saubere Weg: parallel aufbauen
Wenn die Firewall produktiv eingesetzt wird, bauen wir die neue OPNsense-Installation parallel zur bestehenden pfSense-Firewall auf, auf zweiter Hardware oder zunächst als VM. Die alte Firewall bleibt so bis zum Umschalttermin vollständig funktionsfähig.
pfSense dokumentieren
Vollständiges Backup erstellen, dann eine echte Bestandsaufnahme: WAN-IPs, LAN-Netze, VLANs, Gateways, DNS, DHCP, Firewall-Regeln, NAT, Portweiterleitungen, Aliase, statische Routen, VPNs, Zertifikate, Benutzer, Dynamic DNS, Zusatzpakete, Monitoring, externe Dienste. Bei größeren Installationen lohnt sich zusätzlich ein Netzwerkdiagramm.
OPNsense separat installieren
Aktuell befindet sich OPNsense in der 26.7er-Reihe (seit 15. Juli 2026), zuletzt aktualisiert mit 26.7.4 am 15. September 2026. Nicht nach einer Anleitung für OPNsense 22.x oder 23.x migrieren und diese blind übertragen: Gerade bei VPN, Aliasen und Interface-Konfiguration hat sich seither einiges verändert.
Interfaces und VLANs zuerst
Physische Interfaces, WAN, LAN, VLANs, Gateways, IP-Adressen, Routing. Erst wenn diese Grundlage steht, übertragen wir Firewall-Regeln und NAT. Bei VLANs nicht nur auf sichtbare Namen achten: Interface-Zuordnung und interne Bezeichnungen können sich auf Regeln auswirken, im OPNsense-Forum werden entsprechende Probleme berichtet.
REGELN & DIENSTE
Firewall, NAT und DNS: neu anlegen statt kopieren
Die Logik einer Regel bleibt gleich (WAN → Webserver → TCP 443 → NAT → interne IP), in OPNsense wird sie aber neu angelegt, nicht aus XML importiert.
Firewall-Regeln aufräumen
Eine Migration ist eine gute Gelegenheit, alte Regeln zu hinterfragen: Wird sie noch gebraucht? Ist sie zu weit gefasst? Wird der Alias noch verwendet? Gerade bei gewachsenen Installationen findet man erstaunlich oft Regeln, deren Zweck niemand mehr kennt.
Aliase sauber importieren
OPNsense hat die Alias-Verwaltung umgebaut und bietet einen eigenen Alias-Export und -Import auf JSON-Basis inklusive Validierung. Das ist deutlich sauberer, als alte
NAT nicht vergessen
Neben Portforwards auch Outbound NAT, 1:1 NAT, NAT Reflection, automatische Regeln, Hairpin-Szenarien und IPv6 prüfen. OPNsense baut die Outbound-NAT-Konfiguration seit der 26.7-Reihe weiter zur Source-NAT-Konfiguration um, inklusive Migrationshilfe für den Übergang.
DHCP und DNS: unscheinbar, aber tückisch
Die eigentliche DHCP-Konfiguration ist meist einfach nachzubauen. Genauer hinschauen würden wir bei statischen DHCP-Zuweisungen, Hostnames, DNS-Registrierung, DHCP-Optionen, speziellen Boot-Optionen, PXE, DNS-Overrides und internen Hostnamen. Ein Migrationsprojekt kann technisch erfolgreich aussehen, während plötzlich ein Drucker, ein VoIP-Telefon oder ein Management-System nicht mehr funktioniert, weil eine DHCP-Option fehlt.
Auch OPNsense migriert intern
Seit Version 26.7.1 bietet OPNsense einen eigenen Migrationsassistenten, der ältere, „legacy“ angelegte Firewall-Regeln auf die neue MVC/API-Struktur überträgt. Das betrifft bestehende OPNsense-Installationen, nicht den Umstieg von pfSense, ist aber ein guter Grund, auch bei einer frischen OPNsense-Installation den CSV-Export der Regeln vor dem Löschen der alten Regeln zu prüfen.
DER GRÖSSTE AUFWAND
VPN ist wahrscheinlich der Punkt mit dem größten Aufwand
Bei VPNs würden wir besonders viel Zeit einplanen, vor allem wenn bestehende Clients nach der Migration weiter funktionieren sollen.
OpenVPN
Server/Client, Port, Protokoll, Tunnel-Netze, Cipher, TLS-Einstellungen, Routing, DNS-Push und Firewall-Regeln müssen stimmen. Besonders wichtig ist die PKI: Wer nicht einfach eine neue CA erzeugen will, muss CA, Zertifikate und Schlüssel sauber übernehmen oder kontrolliert neu ausstellen, sonst verbinden alte Clients nicht mehr.
IPsec
OPNsense hat die IPsec-Konfiguration über die Jahre auf die StrongSwan-basierte Struktur ausgerichtet, die ältere „Tunnel settings“ sind seit längerem auf dem Migrationspfad zu den moderneren „Connections“. Phase 1, Phase 2, IKE-Version, Verschlüsselung, PFS, IDs und Routing sollten auf beiden Seiten bewusst abgeglichen und nach der Umstellung in beide Richtungen getestet werden.
Zertifikate nicht vergessen
OpenVPN, WebGUI, Reverse Proxy, Captive Portal, IPsec und andere Dienste brauchen ihre Zertifikate, CAs und privaten Schlüssel auch auf OPNsense. Bei Let’s Encrypt ist eine kontrollierte Neuausstellung durch OPNsense selbst oft sauberer als die Übernahme der alten Zertifikate.
HA UND PAKETE
CARP/HA und zusätzliche Pakete
CARP und HA
Wer pfSense als HA-Paar mit CARP/pfsync betreibt, sollte nicht versuchen, beide Systeme gleichzeitig umzubauen. Erst eine einzelne OPNsense-Instanz vollständig aufbauen und testen, dann die HA-Ebene: CARP-VIPs, pfsync, Interface-Zuordnung, Synchronisationsnetz, XMLRPC/API-Synchronisation. Dafür ein eigenes Migrationsfenster und einen expliziten Fallback einplanen.
pfSense-Pakete
Ein installiertes pfSense-Paket wird nicht automatisch zu einem OPNsense-Paket. Bei zusätzlicher Software für IDS/IPS, Proxy, DNS, Monitoring, VPN, Dynamic DNS oder Reporting vorher prüfen, ob es ein Gegenstück unter OPNsense gibt und wie dessen Konfiguration aufgebaut ist.
Community-Skripte
Es gibt Skripte, die versuchen, pfSense-Konfigurationen automatisiert zu übertragen. Auch im OPNsense-Forum wird darauf hingewiesen, dass dabei Einschränkungen bestehen und das Ergebnis anschließend manuell geprüft werden muss. Für eine produktive Firewall wäre uns „hat bei jemandem funktioniert“ als einzige Absicherung zu wenig.
CHECKLISTE
So planen wir eine produktive Migration
Bei einer kleinen Firewall ist das an einem Wartungsabend machbar. Bei vielen VLANs, mehreren VPNs, HA und Zusatzpaketen sollte daraus ein richtiges Migrationsprojekt werden.
Vorbereitung
Backup und Konfiguration exportieren, Pakete, VPNs, Zertifikate, VLANs, Firewall/NAT dokumentieren, Netzwerkdiagramm erstellen.
Aufbau
OPNsense installieren und aktualisieren, dann Interfaces, WAN/LAN, VLANs, Routing, DNS, DHCP, Firewall, NAT, VPN, Zertifikate und Zusatzpakete einrichten.
Test
Nicht nur „GUI geht“: Internet, DNS, IPv4/IPv6, VLANs, Inter-VLAN-Routing, Portweiterleitungen, VPN (Site-to-Site und Remote Access), DHCP, interne DNS-Auflösung, Monitoring, Logging, externe Dienste.
Cutover: Wartungsfenster starten, pfSense-Konfiguration ein letztes Mal sichern, aktuelle Änderungen übernehmen, Kabel/VIPs/Routing umschalten, OPNsense aktivieren, testen, Monitoring beobachten. Die pfSense-Firewall bleibt als Fallback stehen und wird nicht sofort gelöscht: Wenn nach dem Umschalten ein VPN oder VLAN Probleme macht, sollte der Rückweg nicht darin bestehen, pfSense schnell neu zu installieren.
FAZIT
Kein simples Software-Upgrade, aber gut planbar
Beide Systeme haben denselben historischen Ursprung und viele Gemeinsamkeiten, ihre Konfigurationsstrukturen haben sich aber über Jahre auseinanderentwickelt. Eine aktuelle pfSense-config.xml betrachten wir deshalb nicht als vollständiges OPNsense-Backup.
Was dagegen sehr gut funktioniert: pfSense dokumentieren → OPNsense parallel installieren → Grundkonfiguration aufbauen → Regeln, NAT, VLANs und Dienste übertragen → VPN/PKI prüfen → testen → umschalten.
Und noch ein Punkt, den wir persönlich wichtig finden: nicht versuchen, die bestehende pfSense 1:1 nachzubauen, nur weil es technisch möglich wäre. Eine Migration ist ein guter Zeitpunkt, alte Firewall-Regeln, ungenutzte Aliase, vergessene Portfreigaben und historische Sonderlösungen zu hinterfragen. Das reduziert nicht nur den Migrationsaufwand, sondern macht auch die künftige Administration übersichtlicher.
FAQ
Häufige Fragen zur Migration
Firewall-Migration sauber planen?
Ob pfSense zu OPNsense, VLANs, VPN oder HA: Nutzen Sie unsere IT-Leistungen.
