Ein Erfahrungsbericht von Karlheinz Knapp.

Ich habe in den letzten Jahren mehr Sophos-UTM-/SG-Installationen abgelöst, als ich zählen kann – vom Drei-Mann-Steuerbüro mit einer SG 115 bis zum mehrstandortigen Mittelständler mit HA-Cluster, RED-Tunneln in jede Filiale und einem Webproxy, der seit 2014 niemand mehr angefasst hat. Dieser Artikel ist kein Hochglanz-Whitepaper. Es ist das, was ich einem Kollegen erzählen würde, der seine erste große SG-Ablösung vor sich hat: was funktioniert, was schiefgeht und in welcher Reihenfolge man vorgeht, damit am Cutover-Wochenende niemand schwitzt.

Und es ist, ehrlich gesagt, ein Weckruf. Wer jetzt noch eine Sophos SG produktiv betreibt, hat das bequeme Zeitfenster bereits verpasst.

Warum die Uhr wirklich abgelaufen ist

Der offizielle End-of-Life-Termin der gesamten Sophos-SG-Serie und der Sophos UTM ist der 30. Juni 2026 – und Sophos hat dieses Datum zuletzt im April 2026 noch einmal bestätigt. Ab diesem Tag gibt es keine Sicherheitspatches mehr, keine aktualisierten Bedrohungssignaturen und keinen Herstellersupport. Eine UTM, deren Lizenz dann ausläuft, baut keine IPsec-Tunnel mehr auf und lässt keine VPN-Einwahl mehr zu – sie wird Stück für Stück zum offenen Scheunentor.

Der eigentliche Knackpunkt, den viele unterschätzen: Reguläre Renewals sind seit dem 1. Januar 2026 nicht mehr möglich. Das letzte 6-Monats-Renewal war nur noch bis Ende 2025 buchbar – und durfte ohnehin nicht über den 30. Juni 2026 hinausreichen, weil Sophos-Lizenzen kumulativ an dieses harte EOL-Datum gebunden sind. Wer heute noch auf SG sitzt, fährt also bereits auf der letzten gekauften Laufzeit. Es gibt kein „wir verlängern nochmal kurz" mehr.

Damit bleiben realistisch zwei Wege:

1. Auf Sophos XGS / SFOS wechseln – die vom Hersteller vorgesehene Route. Bedeutet: neue Hardware, neues Betriebssystem (SFOS ist architektonisch ein komplett anderes Produkt als die UTM), und – das wird gern verschwiegen – die Rückkehr ins Xstream-Abomodell mit funktionsgebundener Lizenzierung. Zur Erinnerung: Die XGS-Preise sind ab Juli 2026 ohnehin gestiegen.
2. Auf OPNsense wechseln – raus aus der funktionsgebundenen Lizenzierung, rein in eine quelloffene Plattform, deren Lebenszyklus Sie bestimmen und nicht der Hersteller-Vertrieb.

Dieser Beitrag behandelt Weg 2. Nicht als ideologisches Bekenntnis, sondern weil eine SG-Ablösung sowieso ein Neuaufbau ist – und wenn man schon neu baut, ist die Frage „warum dann zurück in den Abozwang?" durchaus legitim.

OPNsense als Zielplattform – ehrlich eingeordnet

OPNsense ist eine quelloffene Firewall-Plattform auf FreeBSD-Basis, entwickelt von Deciso in den Niederlanden, mit dem Paketfilter pf im Kern und einem sauberen API-/Plugin-Konzept obendrauf. Halbjährliche Major-Releases (z. B. 25.1 im Januar, 25.7 im Juli) sorgen für einen planbaren Lebenszyklus. Es gibt eine kostenlose Community Edition und eine Business Edition mit kuratierten, stabileren Builds und kommerziellem Support – wichtig, wenn man als Dienstleister SLAs zusagt.

Damit Sie mir glauben, dass ich Ihnen nichts verkaufe, was es nicht hält, zuerst die Wahrheit über die Lücken – das ist der Teil, an dem Migrationen scheitern, wenn man ihn erst beim Cutover entdeckt:

• E-Mail-Security ist keine Kernfunktion. Wer die UTM-Mail-Proxy-/Anti-Spam-Funktionen nutzt, findet in OPNsense keinen vollwertigen Ersatz. Das os-rspamd-Plugin existiert, ist aber kein Mailgateway-Ersatz. Hier braucht es eine dedizierte Lösung (z. B. ein vorgelagertes Mailgateway).
• OPNsense ist kein WLAN-Controller. Sophos verwaltet AP-/APX-Access-Points zentral. OPNsense kann zwar mit unterstützter Hardware selbst Access Point spielen, ersetzt aber keinen Controller für ein Filial-WLAN. Das geht an einen separaten Controller.
• RED-Tunnel haben kein 1:1-Pendant. Sophos' proprietäre RED-Layer-2-Tunnel müssen als Site-to-Site-IPsec, WireGuard oder OpenVPN neu gedacht werden.
• Transparente AD-SSO (STAS) fehlt in der Form. Benutzerbezogene Regeln baut man über LDAP-Anbindung und Alias-Automatik nach.

Alles andere – Firewalling, NAT, VPN, IPS, Reverse-Proxy, Web-Filtering, HA, Reporting – lässt sich abbilden, oft sauberer und transparenter als vorher. Aber eben nachbauen, nicht importieren. Was uns zum wichtigsten Satz dieses Artikels bringt.

Architektur-Schock: Eine Migration ist kein Config-Import

Die häufigste Fehlannahme im Erstgespräch: „Gibt es nicht ein Tool, das die Sophos-Config nach OPNsense konvertiert?" Nein. Und das ist kein Mangel, sondern ein Vorteil.

Die Sophos UTM ist im Kern eine proxy-zentrierte UTM: Viele Dienste laufen über Application-Layer-Proxys, Regeln referenzieren Objekte und Profile in einer eigenen Logik. OPNsense ist ein regelbasierter Paketfilter mit modularen Diensten obendrauf. Die beiden denken Netzwerk fundamental unterschiedlich. Ein automatischer Import würde nur die „Altlasten" von zehn Jahren – verwaiste Regeln, Schatten-NATs, längst tote Objekte – ins neue System schleppen. Genau die wollen Sie loswerden.

Der mentale Wechsel, den jedes Team durchmachen muss: In der UTM gibt es viel Automatik und implizite Regeln im Hintergrund. In OPNsense ist (fast) alles explizit. Das fühlt sich anfangs nach mehr Arbeit an – und ist nach drei Projekten der Grund, warum die Leute nicht mehr zurückwollen, weil sie endlich sehen, was ihre Firewall tut.

Die Migration in sechs Phasen

So gehe ich in jedem Projekt vor. Halten Sie sich an die Reihenfolge – 90 % der Schmerzen entstehen, wenn Phasen übersprungen werden.

Phase 0 – Discovery & Inventur

Bevor irgendetwas gebaut wird, wird die Bestandsanlage komplett dokumentiert. Im WebAdmin der SG exportiere ich bzw. notiere ich systematisch:

• Alle Interfaces, VLANs, IP-Subnetze, Routing (statisch und dynamisch)
• Den kompletten Regelsatz inkl. NAT (DNAT/Portforwarding, SNAT/Masquerading, 1:1-NAT)
• Alle VPNs: Site-to-Site-IPsec (Phase-1-/Phase-2-Parameter!), SSL-VPN-/Sophos-Connect-Profile, RED-Tunnel
• Web Protection: Proxy-Modus (transparent/explizit), Filterkategorien, SSL-Inspection ja/nein, Ausnahmen
• IPS-Profile und -Ausnahmen
• DHCP-Bereiche inkl. statischer Reservierungen, DNS-Konfiguration
• Authentifizierung: AD-/LDAP-Anbindung, Gruppen, Captive Portal
• HA-Setup, Zertifikate/CA, Reporting-Anforderungen und gesetzliche Aufbewahrungsfristen für Logs

Ergebnis von Phase 0 ist ein sauberes Netzdiagramm plus eine Tabelle „Funktion → wird gebraucht? → Zielabbildung". Diese Tabelle ist Ihr Vertrag mit sich selbst.

Phase 1 – Zielarchitektur & Sizing

Jetzt entscheidet sich, ob am Ende alles läuft oder ruckelt. Hardware-Sizing (eigener Abschnitt weiter unten), Feature-Mapping (Tabelle weiter unten) und die bewusste Entscheidung, was nicht mitwandert. Jede tote Regel, die Sie hier streichen, ist eine Stunde Fehlersuche, die Sie sich in zwei Jahren sparen.

Phase 2 – Parallelaufbau im Labor

OPNsense wird parallel aufgebaut – als VM oder auf der späteren Zielhardware, in einem isolierten Test-VLAN oder auf der Bench. Hier entsteht die komplette Konfiguration: Interfaces, Aliase, Regeln, NAT, VPN-Endpunkte, IPS, Proxy. Die Sophos läuft die ganze Zeit produktiv weiter und wird nicht angefasst. Das ist Ihr Sicherheitsnetz.

Phase 3 – Pilot & Test

Einzelne Clients oder ein Test-VLAN gehen über die neue OPNsense. VPN-Tunnel werden out-of-band getestet (ein zweiter Tunnel parallel zum produktiven – IPsec lässt das zu, solange die Selektoren sauber getrennt sind). Hier finden Sie die Asymmetrien, die MTU-Probleme und die vergessene Regel, bevor der Chef sie findet.

Phase 4 – Cutover

Im Wartungsfenster. Mein Standardablauf:

1. Tage vorher: DNS- und DHCP-Lease-TTLs auf der alten Anlage absenken, damit Clients nach dem Schwenk schnell umlernen.
2. Im Fenster: WAN- und LAN-Verkabelung auf die OPNsense schwenken bzw. die produktive IP übernehmen. VPN-Gegenstellen umstellen.
3. Validieren: Internet, internes Routing, jeder VPN-Tunnel, Portforwardings, Proxy, Authentifizierung – nach Checkliste, nicht nach Bauchgefühl.
4. Sophos bleibt verkabelt und betriebsbereit als Sofort-Rollback.

Phase 5 – Hypercare

Ein bis zwei Wochen erhöhte Aufmerksamkeit: Logs beobachten, Feinjustage an IPS-Regeln (False Positives), Webfilter-Ausnahmen nachziehen. Erst danach wird die Sophos wirklich abgebaut. Ich habe es noch nie bereut, eine Woche länger gewartet zu haben – aber schon mehrfach, es nicht getan zu haben.

Hardware & Sizing – wo Projekte schon vor dem Start scheitern

OPNsense läuft auf Standard-x86-Hardware, auf Deciso-Appliances oder virtualisiert (Proxmox, vSphere). Drei Dinge entscheiden über Wohl und Wehe:

• NICs: Intel-Chipsätze (igb, ix) sind erste Wahl. Von Billig-Realtek-Karten unter Last lasse ich die Finger – das ist die Quelle von 30 % aller „die Firewall ist langsam"-Tickets.
• Krypto-Beschleunigung: AES-NI ist Pflicht für ordentlichen VPN-Durchsatz; QAT-fähige Plattformen bringen bei vielen Tunneln nochmal deutlich mehr.
• RAM & Storage: Für IPS (Suricata) und Proxy großzügig RAM rechnen. Als Dateisystem ZFS – wegen Snapshots vor jedem Update und der Robustheit gegen unsaubere Stromausfälle.

Faustregel: Lieber eine Nummer größer dimensionieren, als beim ersten produktiven Lasttag festzustellen, dass Suricata im Inline-Modus die CPU sättigt. Die Mehrkosten für Hardware sind lächerlich gegenüber den Kosten eines zweiten Wartungsfensters.

Die zehn klassischen Stolpersteine (mit Lehrgeld bezahlt)

1. NAT-Reflection / Hairpin-NAT

Der Klassiker. Intern wird ein eigener Dienst über die öffentliche IP aufgerufen (z. B. der Webserver in der DMZ). Die Sophos regelt das im Hintergrund, OPNsense nicht automatisch. Lösung: NAT-Reflection (Pure NAT) je Portforwarding aktivieren – oder, besser, mit Split-DNS arbeiten. Ich habe mehr als einen Cutover erlebt, bei dem Montagmorgen „die Telefonanlage / das Webportal nicht erreichbar" gemeldet wurde, und es war jedes Mal das.

2. Regelreihenfolge & implizite Regeln

In OPNsense gilt First-Match je Interface. Es gibt keine versteckten Auto-Regeln für VPN-Dienste wie bei Sophos – Sie müssen den VPN-Verkehr explizit erlauben. Achten Sie auf die Anti-Lockout-Regel und verstehen Sie den Unterschied zwischen Interface-Regeln und Floating Rules (mit quick). Wer die Logik nicht verinnerlicht, baut Regeln, die nie greifen.

3. Asymmetrisches Routing & Multi-WAN

Bei mehreren WAN-Leitungen muss eingehender Verkehr über dieselbe Leitung zurück. In OPNsense gehört das über reply-to und sauber konfigurierte Gateway-Gruppen geregelt. Symptom bei Fehlkonfiguration: Verbindungen, die „manchmal" gehen. Die nervigste Klasse von Tickets überhaupt.

4. MSS-Clamping & MTU

PPPoE (1492), IPsec-Overhead – wenn große Pakete durchfallen, laden Webseiten halb oder VPN-Übertragungen hängen. MSS auf Interface- und VPN-Ebene clampen. Klassisches Symptom: „SSH geht, aber das Webinterface lädt nicht zu Ende."

5. Zertifikate & Private Keys

Aus der Sophos bekommen Sie private Schlüssel nicht sauber heraus. Plan: CA und Zertifikate in OPNsense neu erzeugen, OpenVPN-Client-Profile neu ausrollen. Das ist kein technisches, sondern ein Logistikproblem – kalkulieren Sie die Zeit für den Client-Rollout ein.

6. SSL/TLS-Inspection

Die transparente HTTPS-Aufbrechung der UTM lässt sich mit Squid (SSL-Bump) oder Zenarmor nachbauen – inklusive Verteilung des CA-Zertifikats auf alle Clients. Mein ehrlicher Rat: In vielen Umgebungen lohnt sich der Aufwand nicht, und DNS-basiertes Filtering plus Endpoint-Schutz erreicht 90 % des Effekts mit 10 % des Ärgers. Erwartung im Vorfeld klären.

7. Web-Filter-Kategorien

Die Kategoriendatenbank von Sophos ist gewachsen und gut gepflegt. Zenarmor kommt dem am nächsten (kommerziell), SquidGuard-Blocklisten sind freier, aber gröber. Versprechen Sie keine 1:1-Kategorienparität mit der kostenlosen Variante – das fällt Ihnen auf die Füße.

8. DHCP-/DNS-Reservierungen

Statische Leases und Reservierungen müssen manuell übernommen werden. Beachten Sie zudem den laufenden Umstieg von ISC DHCP auf Kea in neueren Versionen. Vergessene Reservierungen für Drucker, Kameras und Telefone sind ein garantierter Montagmorgen-Spaß.

9. HA mit CARP – anderes Modell

Sophos Active/Passive ist nicht gleich CARP. In OPNsense brauchen Sie virtuelle CARP-IPs je Interface, einen dedizierten pfsync-Link für die Statussynchronisation und die XMLRPC-Config-Sync. Outbound-NAT muss auf die CARP-VIP zeigen, sonst bricht beim Failover die Maskierung. MASTER/BACKUP über advskew sauber definieren. Das ist der Punkt, an dem ich am meisten Zeit im Labor verbringe – und am wenigsten beim Kunden.

10. Logging & Reporting-Erwartung

Die hübschen Sophos-Reports gibt es so nicht. OPNsense liefert mit Insight (NetFlow), Bordmitteln, ntopng oder Anbindung an ein SIEM/Graylog hervorragende Daten – aber anders präsentiert. Klären Sie die gesetzlichen Aufbewahrungsfristen und dimensionieren Sie den Log-Speicher (ZFS!) entsprechend.

Best Practices, die ich mir hart erarbeitet habe

• Niemals ohne Rollback. Die alte Anlage bleibt verkabelt und scharf, bis Hypercare durch ist.
• DNS-TTLs vor dem Cutover absenken. Kostet zwei Minuten, spart zwei Stunden.
• Alles dokumentieren – als Audit-Trail. Nicht nur fürs Projekt, auch für die Compliance.
• VPN immer out-of-band testen, bevor produktiv geschwenkt wird.
• Den Webfilter zuletzt scharfstellen. Erst Konnektivität sichern, dann Filterlogik feinjustieren – sonst sucht man Routing-Fehler, wo gar keine sind.
• Updates mit ZFS-Snapshot. Vor jedem Major-Release Snapshot ziehen. Wer das einmal gebraucht hat, macht es nie wieder ohne.

Häufige Fragen zur Migration von Sophos SG auf OPNsense

Gibt es ein Tool, das meine Sophos-Konfiguration automatisch zu OPNsense konvertiert? Nein. Eine SG-Ablösung ist immer ein bewusster Neuaufbau. Das verhindert, dass jahrealte Altlasten mitwandern, und ist langfristig der saubere Weg.

Kann ich die Restlaufzeit meiner Sophos-Lizenz auf OPNsense anrechnen lassen? Nein – das ist kein Herstellerwechsel innerhalb desselben Ökosystems. OPNsense Community ist kostenlos; die Business Edition läuft als eigenes, funktionsunabhängiges Abo ohne Lizenzfallen pro Feature.

Wie lange dauert eine typische Migration? Eine einfache Single-Firewall ohne Proxy ist ein langer Tag plus Vorbereitung. Multi-Standort mit HA, vielen Tunneln und SSL-Inspection sind mehrere Wochen Projekt – der Löwenanteil davon ist Phase 0 bis 3, nicht der Cutover selbst.

Ist OPNsense sicherheitstechnisch auf dem Niveau einer NGFW? Mit Suricata (IPS), Zenarmor (L7/App-Control), Reverse-Proxy/WAF und konsequenter Segmentierung lässt sich ein modernes NGFW-Sicherheitsniveau erreichen. Die offene Architektur ist dabei eher Vorteil als Nachteil – Sie sehen und kontrollieren jeden Baustein.

Was passiert, wenn ich meine SG einfach weiterlaufen lasse? Technisch läuft sie zunächst weiter. Sicherheits- und Compliance-seitig ist das ab dem 30. Juni 2026 nicht vertretbar: keine Patches, keine Signaturen, kein Support – und sobald die letzte Lizenzlaufzeit endet, fallen zentrale Funktionen wie VPN aus.

Fazit: Aus dem Zwang eine Chance machen

Das EOL der Sophos SG ist kein Grund zur Panik, aber jeder weitere Monat des Zögerns verschlechtert Ihre Position – die Renewals sind weg, Dienstleister-Kapazitäten werden knapper, und die Uhr läuft auf den 30. Juni 2026 zu. Wer die Migration sauber in Phasen plant, das Feature-Mapping ehrlich macht und die zehn Stolpersteine kennt, bevor sie zuschlagen, kommt nicht nur ohne Ausfall durch den Cutover – sondern aus dem Abozwang heraus und in eine Plattform, deren Lebenszyklus er selbst kontrolliert. Genau das nenne ich digitale Souveränität: keine Marketing-Floskel, sondern die Firewall, die Ihnen gehört.

Wenn Sie vor genau dieser Ablösung stehen und einen Sparringspartner wollen, der die Stolpersteine schon kennt: Wir begleiten Sophos-SG-Migrationen auf OPNsense von der Discovery bis zum Hypercare – inklusive Managed Service danach. Reden wir, solange das Fenster bis zum 30. Juni 2026 noch offen ist.

Referenzen

EDNT begleitet Unternehmen bei der Einführung und Weiterentwicklung flexibler Open-Source-Lösungen, die sich an realen Geschäftsprozessen orientieren. Im Bereich OPNsense profitieren Kunden besonders von unserer Fähigkeit, technische Systeme sauber aufzusetzen und gleichzeitig die operative Realität im Unternehmen mitzudenken.

Geschätzt werden vor allem die strukturierte Projektvorgehensweise, unsere Kompetenz bei individuellen Anpassungen, unsere Erfahrung mit Schnittstellen und Workflows sowie die langfristige Begleitung im Betrieb.

Jetzt OPNsense Beratung anfragen

Sie möchten OPNsense einführen, ein bestehendes System professionell erweitern, Prozesse digitalisieren oder eine flexible Firewall für Ihr Unternehmen aufbauen?

Dann sprechen Sie mit EDNT.

Wir unterstützen Sie bei OPNsense Beratung, OPNsense Einführung, OPNsense Anpassung, OPNsense Schulung, OPNsense SLA und der langfristigen Betreuung Ihrer Umgebung.