# pfSense zu OPNsense: Leitfaden für eine erfolgreiche Migration

TL;DR / Management Summary Viele Administratoren wechseln aufgrund der moderneren UI, der Plugin-Philosophie und des offenen Entwicklungsmodells von pfSense zu OPNsense. Da beide auf FreeBSD basieren, ist die logische Struktur sehr ähnlich. Ein direkter Import der config.xml ist jedoch aufgrund unterschiedlicher XML-Schemas nicht ohne manuelle Nacharbeit möglich. Ein Senior Admin wählt meist den Weg der “sauberen Neuinstallation” und übernimmt Regeln und Aliase via Copy-Paste oder spezialisierten Skripten.

# 1. Warum migrieren? (Entscheidungsgrundlagen)

Die Unterschiede im Detail.

• User Interface: OPNsense nutzt ein modernes, reaktionsschnelles Design.
• Plugins: OPNsense trennt Core-Code strikt von Erweiterungen (saubereres System).
• API: OPNsense bietet eine wesentlich umfangreichere REST-API für Automatisierung.
• Kryptografie: OPNsense integriert moderne Protokolle wie WireGuard meist schneller und tiefer in den Kernel.

# 2. Der Migrations-Workflow

Systematisches Vorgehen.

# Schritt 1: Bestandsaufnahme (pfSense)

Exportieren Sie alle relevanten Daten als Text oder CSV:

• Firewall Aliase (IPs, Netzwerke).
• DHCP Statische Mappings (MAC-Adressen).
• VPN-Benutzer und Zertifikate (Export der CA und Keys).

# Schritt 2: OPNsense Grund-Setup

Installieren Sie OPNsense parallel (z.B. als neue VM in Proxmox) und konfigurieren Sie die Interfaces (WAN, LAN) identisch zur alten pfSense.

# Schritt 3: Datenübernahme

Übernehmen Sie die Einstellungen in dieser Reihenfolge:

1. Zertifikate & CAs: Importieren Sie die Root-CA, damit bestehende VPN-Clients weiter funktionieren.
2. Aliase: Legen Sie diese zuerst an, da die Regeln darauf referenzieren.
3. Regeln: Erstellen Sie die Regeln manuell nach oder nutzen Sie das XML-Snippet Verfahren (für Experten).

# 3. Deep Dive: XML-Schema Unterschiede

Warum ‘Import’ allein nicht reicht.

Obwohl beide Dateiformate .xml nutzen, unterscheiden sich die Tags.

• pfSense: Nutzt oft verschachtelte Strukturen für Pakete.
• OPNsense: Nutzt ein flacheres Modell für Core-Komponenten.
• Lösung: Es gibt Community-Skripte (z.B. auf GitHub), die eine config.xml konvertieren können. Prüfen Sie das Ergebnis jedoch zwingend auf Fehler in der Routing-Tabelle!

# 4. Day-2 Operations: Interface-Mapping

Namen sind Schall und Rauch.

In pfSense hießen Ihre Karten vielleicht em0 und em1. In der OPNsense-VM auf Proxmox heißen sie nun vtnet0 und vtnet1.

• Aktion: Nach dem Import einer (konvertierten) Config müssen Sie über die Konsole (Option 1) die Interfaces neu zuweisen. Erst danach ist die Web-GUI wieder erreichbar.

# 5. Troubleshooting & “War Stories”

Wenn der Schwenk schiefgeht.

# Top 3 Fehlerbilder

1. Symptom: VPN-Tunnel (IPsec) kommen nicht hoch.

   • Ursache: OPNsense nutzt andere Standard-Ciphers für IKEv2 als pfSense.
   • Lösung: Phase 1 und Phase 2 Einstellungen manuell auf beiden Seiten (Partner und OPNsense) abgleichen.

2. Symptom: NAT-Regeln funktionieren nicht.

   • Ursache: Die “Reflection” Einstellungen wurden nicht korrekt übernommen.
   • Fix: Artikel 559 konsultieren und Reflection neu setzen.

3. Symptom: Plugins (z.B. FRR/OSPF) starten nicht.

   • Ursache: Pfade in der Config zeigen noch auf pfSense-spezifische Verzeichnisse.

# “War Story”: Der “Hidden” Alias

Ein Admin migrierte ein riesiges Regelwerk mit über 200 Aliasen. Er nutzte ein Konvertierungs-Skript. Das Ergebnis: Ein Alias für “Interne Server” wurde fälschlicherweise als leerer Alias importiert. Die Folge: Da die Firewall-Regel nun Source: [Leer] sah, blockierte sie den gesamten Traffic zum Rechenzentrum. Der Fehler wurde erst Stunden später bemerkt, da die GUI keine Fehlermeldung für leere Aliase anzeigte. Lehre: Validieren Sie nach jeder Migration die Alias-Inhalte unter Diagnostics -> Network -> Aliases.

# 6. Monitoring & Reporting

Vergleich der Performance.

# Vorher-Nachher Benchmark

Führen Sie vor und nach der Migration einen iperf3 Test (Artikel 570) durch.

• Erkenntnis: Oft ist OPNsense bei identischer Hardware leicht schneller im Routing, da der Stack moderner optimiert ist.

# 7. Fazit & Empfehlung

Die Migration ist der perfekte Zeitpunkt für einen Frühjahrsputz.

• Empfehlung: Importieren Sie nicht blind die alte Konfiguration. Bauen Sie das Regelwerk manuell neu auf – Sie werden überrascht sein, wie viele veraltete und ungenutzte Regeln Sie dabei finden.
• Wichtig: Lassen Sie die alte pfSense als “Cold Standby” VM noch eine Woche bestehen, falls Sie ein wichtiges Detail vergessen haben.

# Anhang: Vergleichstabelle für Umsteiger

# Referenzen

• OPNsense Wiki: Moving from pfSense to OPNsense
• Reddit r/opnsense: Migration Thread & Scripts
• FreeBSD Project: Comparison of Firewall Engines