Von Check Point zu Sophos: Firewall-Migration in der Praxis

Firewall-Migration in der Praxis – was wir aus einem Check Point-Projekt gelernt haben

Firewall-Migrationen gehören zu den anspruchsvollsten Aufgaben in der Netzwerksicherheit. Nicht, weil sie technisch unlösbar wären – sondern weil jede Plattform anders denkt.

Wer den Datenfluss einer Firewall versteht, kann Migrationen stabil und planbar umsetzen. Wer ihn nur kopiert, riskiert Fehlverhalten und Performance-Verluste.

In einem unserer Projekte haben wir eine Check Point-Firewall auf eine routingbasierte Architektur mit BGP und redundanten VPNs migriert. Dabei wurde deutlich, dass eine Migration mehr bedeutet als Regelimport und Konfigurationsübernahme – sie ist ein Perspektivwechsel.

Ausgangssituation: Policy-Logik trifft Routing-Design

Die bestehende Umgebung war eine klassische Check Point-VPN-Community, in der Pakete einer festen Prüf- und Entscheidungsreihenfolge folgten:

Anti-Spoofing → Session-Lookup → Policy → NAT → Inspection → Encryption → Routing

Diese Policy-Kaskade war stabil, aber starr.

In der neuen Umgebung sollte das System routingbasiert mit BGP und dynamischer Pfadwahl arbeiten.

Die Sophos XGS Firewall – mit moderner Xstream-Architektur – verarbeitet Pakete je nach Situation unterschiedlich:

• Über den SlowPath laufen die ersten Pakete durch die DPI-Engine (Deep Packet Inspection), vertrauenswürdige Flows werden anschließend über den FastPath hardwarebeschleunigt weitergereicht.
• Dieser Wechsel von Policy-first zu Flow-first war einer der größten Unterschiede – und die Quelle technischer Herausforderungen

Herausforderung: Default Route, BGP und das AWS-Zielnetz 0.0.0.0/0

• Die IPSec-Tunnel zur AWS-Cloud standen stabil, aber BGP blieb auf Active – kein Austausch der Nachbarschaften, keine dynamischen Routen. 
• Die Ursache lag nicht in der Firewall, sondern in der AWS-Seite:
• AWS legt in VPN-Tunnels häufig 0.0.0.0/0 als Zielnetz fest, wodurch sämtliche Prefixe über den Tunnel angekündigt werden.
• Damit eine BGP-Verbindung funktioniert, muss eine statische Route zum Zielnetz existieren, sonst weiß die Firewall schlicht nicht, über welches Interface sie den Peer erreichen soll. 

In unserem Fall war die Lösung technisch klar, aber konzeptionell sensibel: 

• Wir mussten eine statische 0.0.0.0/0-Route über das XFRM-Tunnelinterface eintragen, um den BGP-Austausch zu initialisieren. 
• Erst danach konnte der BGP-Prozess den AWS-Peer erreichen, die Nachbarschaft aufbauen und die dynamischen Routen übernehmen.

NAT-Verhalten im Vergleich: Check Point vs. Routingbasierte Systeme

Der NAT-Prozess in der Sophos Firewall folgt einer routingbasierten, dynamischen Verarbeitung, die sich deutlich von der regelbasierten NAT-Logik klassischer Check Point-Systeme unterscheidet. 

Während Check Point NAT erst nach der Access-Policy-Prüfung anwendet, erfolgt bei Sophos ein DNAT-Lookup bereits vor der Regelbewertung, um die korrekte Zielzone und das Routing frühzeitig festzulegen – eine Voraussetzung für dynamische Next-Hop-Entscheidungen und bidirektionales Session-Handling. 

Der typische Ablauf in Sophos SFOS (ab v18) lässt sich in sieben logische Schritte gliedern: 

1. Packet Arrives – Das Paket trifft an der eingehenden Schnittstelle ein. 
2. Marking – Das System markiert den Datenstrom für spätere NAT- und Regelzuordnung. 
3. NAT Lookup – Überprüfung auf bestehende DNAT- oder Full-NAT-Regeln.
4. Zone DNAT – Falls eine DNAT-Regel zutrifft, wird die Zielzone gemäß der übersetzten Adresse angepasst.
5. Firewall Rule Matching – Das Paket wird anhand der (post-DNAT) Zielzone, aber (pre-NAT) IP-Adresse mit den Firewall-Regeln verglichen.
6. NAT Application – Anwendung der endgültigen NAT-Übersetzung (DNAT/SNAT/Full NAT). 
7. Packet Delivered – Zustellung an Routing- und Forwarding-Prozess. 

Unsere wichtigste Erkenntnis

„Man migriert nicht die Konfiguration – man migriert den Datenfluss.“ 

Eine erfolgreiche Migration hängt nicht von Tools oder Imports ab, sondern davon, wie gut man das Verhalten des alten Systems versteht und es im neuen reproduzieren kann. 

Wer weiß, wann NAT, Routing und Inspection greifen, kann diese Mechanismen gezielt nachbilden – und genau das macht den Unterschied zwischen stabiler Migration und endlosem Troubleshooting.

Fazit:  Erfahrung schafft Vertrauen

Diese Migration hat gezeigt, dass Firewall-Wechsel weit mehr sind als ein technischer Austausch.

• Während der Umsetzung traten einige Punkte auf, die zunächst genauer analysiert und abgestimmt werden mussten – insbesondere im Zusammenspiel von Routing, NAT und BGP.
• Durch strukturiertes Troubleshooting und eine klare, nachvollziehbare Vorgehensweise konnte die Umgebung Schritt für Schritt stabilisiert und optimiert werden.

Heute läuft das System zuverlässig und transparent – mit einer Architektur, die sich leicht erweitern lässt und langfristig planbar ist.

Erfahrung bedeutet nicht, alles sofort perfekt zu wissen – sondern zu erkennen, wo man ansetzen muss, um nachhaltige Ergebnisse zu erreichen.

Tipp aus der Praxis: 

Wer Migrationen plant oder bestehende Systeme modernisieren möchte, sollte vorab eine technische Analyse des Paketflusses durchführen – inklusive Routing- und NAT-Verhalten. So lassen sich BGP- und VPN-Probleme vermeiden, bevor sie entstehen. 

Benötigen Sie Unterstützung bei Planung oder Validierung? 

Unser Team hilft Ihnen gern weiter: Support anfragen 

Quellen:

1. Sophos Documentation – “NAT Traffic Processing”, SFOS 20.0 Help: 
2. Sophos Community (EAP v18 Thread): "When a packet arrives, the Sophos Firewall performs a NAT lookup for DNAT or Full NAT rules and translates the zone before rule matching.” – Sophos Community 
3. Sophos Docs – Inbound vs. Outbound NAT behavior, siehe Abschnitt „Incoming Traffic: DNAT lookup first, then firewall rule matching“. 
4. Sophos Docs – Outbound Traffic: Firewall rule first, then SNAT rule applied.
5. Check Point Community Thread – Order of Operations: „When packet arrives at interface, it's first matched against access policy, then destination NAT is considered, then routing, source NAT and off it goes.“ community.checkpoint.com 
6. Check Point R81 Admin Guide – Configuring NAT Policy: „The Security Gateway enforces the NAT Rule Base in the order you place the rules.“ - sc1.checkpoint.com