Sophos Firewall mit AWS Site-to-Site VPN verbinden

Ein AWS Site-to-Site VPN verbindet ein lokales Netzwerk hinter der Sophos Firewall mit einer AWS VPC oder einem Transit Gateway. Technisch ist es ein IPsec-VPN, praktisch unterscheidet es sich aber deutlich von einem normalen Sophos-zu-Sophos-Tunnel: AWS erstellt pro VPN-Verbindung zwei Tunnel, arbeitet mit Customer Gateway und Ziel-Gateway, und das Routing hängt stark davon ab, ob statische Routen oder BGP verwendet werden.

Dieser Artikel erklärt den pragmatischen Aufbau mit Sophos Firewall und AWS. Er ergänzt die allgemeine Anleitung Sophos Firewall Site-to-Site IPsec VPN einrichten um die AWS-spezifischen Stolperfallen: zwei Tunnel, BGP-Nachbarschaften, Route Tables, Security Groups, NACLs und die Prüfung im AWS- und Sophos-Status. Wenn ein Tunnel bereits steht, aber kein Traffic fliesst, hilft zusätzlich Sophos Firewall IPsec VPN Troubleshooting.

Wann dieser Artikel passt

Der Artikel passt, wenn ein Standort, Rechenzentrum oder lokales Netzwerk über Sophos Firewall mit AWS verbunden werden soll. Gemeint ist AWS Site-to-Site VPN zu einer VPC, einem Virtual Private Gateway oder Transit Gateway. Nicht gemeint ist Sophos Firewall als virtuelle Appliance direkt in AWS.

Typische Szenarien:

• lokales Servernetz zu EC2-Instanzen in einer VPC
• Backup-, Monitoring- oder Management-Traffic zu AWS
• Hybrid-DNS, AD, Jump Hosts oder Administrationsnetze
• Migration von statischem VPN auf dynamisches BGP-Routing
• redundanter Tunnelbetrieb mit zwei AWS-Tunneln

AWS und Sophos verwenden unterschiedliche Begriffe. In AWS arbeitet man mit Customer Gateway, Virtual Private Gateway oder Transit Gateway, Site-to-Site VPN connection, Tunnel Details, Route Tables, Security Groups und Network ACLs. Auf der Sophos Firewall arbeitet man mit Amazon VPC-Verbindungen, IPsec-Profilen, XFRM-Interfaces, BGP, Routen und Firewall-Regeln.

Vor der Konfiguration planen

AWS Site-to-Site VPN sollte man nicht nur aus einer heruntergeladenen Beispielkonfiguration importieren und danach als erledigt betrachten. Die AWS-Datei ist hilfreich, aber die produktive Abnahme hängt an Routing, Security Groups, NACLs, Firewall-Regeln und Tests mit echtem Traffic.

Netze und Ziel-Gateway festlegen

Zuerst muss klar sein, welche AWS-Seite verwendet wird:

• Virtual Private Gateway für eine klassische einzelne VPC.
• Transit Gateway für mehrere VPCs, mehrere Standorte oder ein grösseres Routing-Design.
• Cloud WAN oder andere Varianten nur, wenn die AWS-Architektur das bewusst vorgibt.

Vorher dokumentieren:

• AWS VPC CIDR, zum Beispiel 10.60.0.0/16
• relevante AWS Subnets und Route Tables
• lokale Netze hinter der Sophos Firewall, zum Beispiel 172.16.20.0/24
• öffentliche IP der Sophos Firewall oder des vorgelagerten Routers
• Routing-Modus: static oder dynamic BGP
• lokale und AWS-ASN, wenn BGP genutzt wird
• erwartete Testziele auf beiden Seiten
• geplante Tunnel-Optionen, IKE-Version, Preshared Keys und Lifetimes

Überlappende Netze sollten vor dem VPN-Design bereinigt werden. NAT über IPsec kann funktionieren, erschwert aber Route Tables, Security Groups, Logs und spätere Fehlersuche.

Zwei Tunnel ernst nehmen

AWS erstellt pro Site-to-Site-VPN-Verbindung zwei Tunnel mit unterschiedlichen AWS-Endpunkten. Beide Tunnel sollten auf der Sophos Firewall konfiguriert und geprüft werden. Nur einen Tunnel zu bauen ist für einen Labortest bequem, aber im produktiven Betrieb verschenkt man damit die AWS-Redundanz.

Wichtig ist die Erwartung: Der Rückweg von AWS bevorzugt je nach Routing und AWS-Seite einen Tunnel und kann bei Fehlern umschalten. Das bedeutet nicht automatisch, dass beide Tunnel immer gleichmässig genutzt werden. Entscheidend ist, dass beide Tunnel hochkommen, BGP oder statische Routen korrekt sind und ein Failover getestet wurde.

Static Routing oder BGP

AWS Site-to-Site VPN unterstützt statische Routen und dynamisches Routing mit BGP. BGP ist meistens die bessere Wahl, wenn mehrere Präfixe, spätere Erweiterungen oder Transit Gateway im Spiel sind. Statische Routen sind einfacher, müssen aber bei jeder Netzänderung manuell gepflegt werden.

In der Praxis gilt:

• BGP braucht passende ASN-Werte auf beiden Seiten.
• Die Sophos Firewall muss die gewünschten lokalen Präfixe sauber annoncieren.
• AWS Route Tables müssen propagierte oder statische Routen wirklich verwenden.
• Security Groups und NACLs müssen den Traffic zusätzlich erlauben.
• Identische statische und BGP-Routen können zu unerwarteter Priorität führen.

AWS-Seite vorbereiten

Die folgenden Schritte beschreiben den üblichen Ablauf. Je nach AWS-Design unterscheiden sich Details zwischen Virtual Private Gateway und Transit Gateway, das Prinzip bleibt aber gleich.

Customer Gateway erstellen

Das Customer Gateway beschreibt die lokale Sophos-Seite in AWS.

Eintragen:

1. In der AWS-Konsole zu VPC > Virtual private network (VPN) > Customer gateways gehen und Create customer gateway wählen.
2. Name tag setzen, zum Beispiel cgw-sophos-hq.
3. Wenn BGP geplant ist, unter BGP ASN genau die lokale Sophos-ASN eintragen. AWS zeigt dieses Feld auch für statisch geroutete Verbindungen an; bei statischem Routing wird jedoch kein BGP-Peering aufgebaut.
4. Unter IP address die statische, aus dem Internet erreichbare Adresse der Sophos-Seite eintragen. Steht die Firewall hinter einem vorgeschalteten NAT-Gerät, wird für das AWS Customer Gateway dessen öffentliche IP-Adresse eingetragen, nicht die dahinterliegende Adresse des Sophos-WAN-Interfaces.
5. Optional Device als verständliche Gerätebezeichnung pflegen und die Ressource mit Create customer gateway erstellen.

Wenn die Sophos Firewall hinter einem Router oder Providergerät steht, muss klar sein, welche öffentliche IP AWS sieht und ob NAT-T sauber funktioniert. Für das Customer Gateway müssen UDP 500 und bei NAT-T zusätzlich UDP 4500 zwischen dem lokalen Netz und den AWS-Site-to-Site-VPN-Endpunkten passieren können. Das vorgeschaltete NAT-/Firewall-Gerät muss diese Ports zwischen dem Sophos-WAN-Interface und beiden AWS-Tunnel-Endpunktadressen aus der Konfigurationsdatei erlauben und weiterleiten.

Ziel-Gateway erstellen oder auswählen

Bei einer einzelnen VPC wird typischerweise unter VPC > Virtual private network (VPN) > Virtual private gateways ein Virtual Private Gateway erstellt und anschliessend über Actions > Attach to VPC an die VPC angehängt. Bei grösseren AWS-Umgebungen wird häufig ein Transit Gateway verwendet.

Prüfen:

• Gateway ist mit der richtigen VPC oder dem richtigen Transit Gateway verbunden.
• ASN auf AWS-Seite kollidiert nicht mit der Sophos-ASN.
• Route Tables der VPC oder des Transit Gateway sind geplant.
• Subnetze, über die getestet wird, verwenden die richtige Route Table.

Site-to-Site VPN Connection erstellen

In AWS geht man danach zu VPC > Virtual private network (VPN) > Site-to-Site VPN connections und wählt Create VPN connection.

Wichtige Punkte:

• Unter Target gateway type das zuvor geplante Virtual Private Gateway oder Transit Gateway auswählen.
• Unter Customer gateway die Option Existing und das zuvor erstellte Customer Gateway auswählen.
• Routing options auf Dynamic (requires BGP) oder Static setzen; bei Static IP prefixes ausschliesslich die lokalen Präfixe eintragen, die AWS über das VPN erreichen soll.
• Tunnel Options bewusst prüfen, besonders IKE-Version, Encryption, Integrity, DH/PFS und DPD.
• Preshared Keys pro Tunnel dokumentieren oder bewusst automatisch erzeugen lassen.

Bei dynamischem Routing verlangt Sophos für Local IPv4 Network Cidr und Remote IPv4 Network Cidr in der AWS-Verbindung jeweils 0.0.0.0/0, damit das BGP-Peering aufgebaut werden kann. Ist auf der Firewall bereits ein Local AS konfiguriert, wird genau diese ASN beim AWS Customer Gateway eingetragen.

Nach dem Erstellen Download configuration wählen. Für den automatischen Sophos-Import als Vendor Sophos, Platform Sophos Firewall, Software v19+ und die tatsächlich geplante IKE version wählen. Die Datei ist nur eine Beispielkonfiguration: Algorithmen, DH-Gruppen, Zertifikate und IP-Familie müssen zum produktiven Design passen. Hinter NAT vor dem Import in beiden customer-gateway-seitigen tunnel_outside_address-Blöcken die lokale Adresse des Sophos-WAN-Interfaces eintragen. Die AWS-seitigen Outside-Endpunkte unverändert lassen; nicht jeden gleichnamigen XML-Block pauschal ersetzen. Im AWS Customer Gateway bleibt dagegen die öffentliche Adresse des vorgeschalteten NAT-Geräts. Für statische Routen Generic wählen und manuell konfigurieren. Auch dynamisches BGP lässt sich mit dem nachfolgend beschriebenen Generic-Download manuell aufbauen; der Sophos-Import ist nicht der einzige BGP-Weg.

Route Tables, Security Groups und NACLs prüfen

Ein grüner VPN-Tunnel bedeutet in AWS noch nicht, dass eine EC2-Instanz erreichbar ist.

Für die Abnahme prüfen:

• VPC Route Table enthält Route zum lokalen Netz über Virtual Private Gateway oder Transit Gateway.
• Bei Virtual Private Gateway ist Route Propagation aktiviert oder die Route statisch gesetzt.
• Transit Gateway Route Tables enthalten passende Attachments und Propagations.
• Security Group der Zielinstanz erlaubt den gewünschten Traffic aus dem lokalen Netz.
• Network ACLs erlauben Hin- und Rückweg.
• Betriebssystem-Firewall der Instanz blockiert den Test nicht.

Dieser Teil wird oft übersehen, weil Sophos und AWS beide einen Tunnel als verbunden anzeigen können, obwohl die Instanz wegen Security Group oder Rückroute nicht antwortet.

Sophos Firewall konfigurieren

Sophos bietet für AWS zwei praktische Wege: Import über Site-to-site VPN > Amazon VPC oder manuelle Konfiguration als route-based IPsec-Verbindung. Für viele AWS-Setups ist der Import der sauberste Einstieg, danach sollten die automatisch erzeugten Objekte aber kontrolliert werden.

AWS-Konfiguration importieren

Unter Site-to-site VPN > Amazon VPC kann die Sophos Firewall die Verbindung entweder mit Use AWS security credentials oder mit Use VPC configuration file importieren. Für den Credential-Weg wird ein eigener AWS-IAM-Benutzer mit den für die Site-to-Site-VPN-Einstellungen benötigten Rechten verwendet; Access Key und Secret Key werden wie andere administrative Secrets geschützt und rotiert.

Der Import ist eine Momentaufnahme. Werden Tunneloptionen oder andere Verbindungswerte in AWS geändert, müssen die Einstellungen erneut importiert und anschliessend vollständig geprüft werden. Ein alter Import wird nicht automatisch an die AWS-Konfiguration angeglichen.

Der folgende Ablauf verwendet die heruntergeladene AWS-Konfigurationsdatei:

Vorgehen:

1. Sophos Firewall öffnen.
2. Zu Site-to-site VPN > Amazon VPC gehen.
3. Use VPC configuration file auswählen.
4. AWS-Konfigurationsdatei hochladen.
5. Import starten.
6. Erstellte Verbindungen, IPsec-Profile, XFRM-Interfaces und BGP-Einstellungen prüfen.

Der Import erzeugt IPsec-Profile, BGP-Einstellungen und XFRM-Interfaces. Danach werden unter Routing > BGP > Networks die lokalen Präfixe hinzugefügt. Unter Administration > Device access muss IPsec für WAN und Dynamic Routing für VPN aktiviert sein. Diese Freigaben betreffen den Tunnel- und Routing-Control-Traffic; sie ersetzen keine Firewall-Regel für den Nutztraffic.

Hinter NAT in jedem der beiden Tunnelabschnitte den customer-gateway-seitigen tunnel_outside_address mit der lokalen Sophos-WAN-Adresse kontrollieren. AWS-seitige Outside-Adressen nicht ändern; die öffentliche NAT-Adresse bleibt die AWS-Customer-Gateway-Adresse. Datei und Importobjekte bei unklarer Zuordnung nicht aktivieren, sondern die Kundenseite und AWS-Seite zuerst eindeutig identifizieren.

Zwei IPv4-VGW-Tunnel manuell mit BGP aufbauen

Diese Alternative beschreibt eine IPv4-Verbindung zu einem an die VPC angehängten Virtual Private Gateway mit Dynamic (requires BGP). Sie ist kein IPv6-/Transit-Gateway-/Cloud-WAN-Runbook und keine pauschale Aussage, AWS unterstütze kein IPv6. AWS-Berechtigungen, lokale Adminrechte, erreichbare Outside-Endpunkte, nicht überlappende Netze und ein genehmigter Rückweg sind Voraussetzungen. Den Import und einen manuellen Parallelaufbau nicht gleichzeitig für dieselben Routen aktivieren.

1. In AWS bei der vorgesehenen VPN-Verbindung Download configuration öffnen: Vendor Generic, Platform Generic, Software Vendor agnostic, IKE version ikev2. Dies gilt ausdrücklich auch für manuelles dynamisches BGP. Die Datei enthält PSKs: verschlüsselt und zugriffsbeschränkt ablegen.
2. Für jeden Tunnel getrennt Outside-Endpunkt, PSK, Inside-CIDR, Customer-Inside-Adresse, AWS-Inside-Adresse und ASNs aus der tatsächlich erzeugten Konfiguration erfassen. Zwei verschiedene von AWS akzeptierte /30-Netze aus 169.254.0.0/16 verwenden; reservierte oder bereits genutzte Bereiche nicht übernehmen. Die folgende Zuordnung ist ein lesbares Planungsbeispiel, keine Zuweisung durch AWS:

Zuordnungstabelle: Outside-IP baut IPsec auf; Inside-IP adressiert XFRM und BGP. Ausschliesslich die tatsächlich von AWS ausgegebenen Adressen verwenden: nicht aus der Reihenfolge der Demo-Adressen auf die eigene Zuteilung schliessen. Die SFOS-XFRM-Adresse ist die Customer-Inside-Adresse, niemals die AWS-Inside-Adresse oder die öffentliche IP. Der BGP-Neighbor ist die AWS-Inside-Adresse, nicht der Outside-Endpunkt.

3. Unter Profiles > IPsec profiles > Add ein eindeutig benanntes benutzerdefiniertes Profil anlegen. Ein begrenztes Beispiel für beidseitig so konfigurierte Tunnel ist IKEv2, Phase 1 AES256 / SHA2 256 / DH 14 (DH2048) und Phase 2 AES256 / SHA2 256 / PFS 14 (DH2048). Re-key connection aktivieren; Key negotiation tries 0 und Use strict profile deaktiviert nur übernehmen, wenn der freigegebene Betriebsplan dies vorsieht. Die ausgewählten Algorithmen und DH/PFS-Gruppen müssen eine gemeinsame erlaubte Proposal bilden, nicht bloss denselben Profilnamen tragen.
4. Lifetimes und Rekey/DPD getrennt dokumentieren. Ein historisches Beispiel nennt AWS Phase 1 28800 Sekunden, aber SFOS Key life 28000; Phase 2 jeweils 3600, Rekey Margin 360 und Fuzz 50 Prozent. Unterschiedliche lokale IKEv2-Rekey-Timer sind nicht automatisch ein Proposal-Fehler und kein Beleg für getestete Interoperabilität. Keinen widersprüchlichen Timer stillschweigend als universellen Standard übernehmen: die tatsächlich konfigurierten AWS-Werte und einen dazu freigegebenen SFOS-Rekey-Plan verwenden; bei unklaren Bedingungen stoppen und klären. Ein DPD-Beispiel ist AWS Restart sowie SFOS DPD aktiviert, Prüfabstand 30, Antwortwartezeit 120 Sekunden und Re-initiate. Diese Werte sind ein zu prüfendes Profilbeispiel, keine universelle Vorgabe. Vor Produktivbetrieb Rekey-/DPD-Verhalten im eigenen Änderungsfenster bestätigen.
5. Unter Site-to-site VPN > IPsec > Add je Tunnel eine eigene Verbindung mit Connection type Route-based (Tunnel interface), IP version IPv4 und Gateway type Initiate the connection erstellen. Unter Profile das gerade geprüfte benutzerdefinierte Profil auswählen, nicht blind ein anderes Standardprofil namens IKEv2. Authentication type Preshared key und genau den PSK dieses Tunnels setzen. Listening interface ist die lokale WAN-Schnittstelle; Gateway address ist der jeweilige AWS-Outside-Endpunkt. Local/Remote IKE IDs nur nach dem tatsächlich erwarteten Identitätsplan setzen, niemals zufällige IPs verwenden; hinter NAT ist die lokale WAN-Adresse nicht mit der öffentlichen Customer-Gateway-Adresse gleichzusetzen. Activate on save erst im freigegebenen Fenster nach Prüfung wählen; beide Verbindungen speichern und aktivieren.
6. Unter Network > Interfaces den zur jeweiligen Verbindung gehörenden XFRM öffnen und den Verbindungslink kontrollieren. Unter IPv4/netmask die Customer-Inside-IP und /30 (255.255.255.252) dieses Tunnels eintragen. Beim zweiten XFRM dessen eigene Inside-IP verwenden; Zuordnungen nicht vertauschen.
7. Unter Routing > BGP > Global configuration den bereits verwendeten Local AS beibehalten beziehungsweise die genehmigte Customer-Gateway-ASN setzen. Eine eindeutige, stabile Router ID aus dem eigenen Plan verwenden. Einen vorhandenen globalen ASN nicht für dieses VPN überschreiben; AWS muss denselben lokalen ASN-Wert nutzen. Keine ASN-Spanne oder Demo-ASN ungeprüft kopieren: Verfügbarkeit, AWS-Zulässigkeit und Konfliktfreiheit zuerst prüfen. Unter Neighbors je AWS-Inside-IP einen IPv4-Neighbor mit Remote AS gleich der tatsächlichen VGW-ASN erstellen.
8. Unter Routing > BGP > Networks nur die genehmigten lokal erreichbaren Präfixe annoncieren. Unter Administration > Device access IPsec für WAN und Dynamic Routing für VPN erlauben; keine pauschale LAN-Freigabe ergänzen, wenn dort kein lokaler Routing-Peer vorgesehen ist. BGP TCP 179 als Nutztraffic weltweit oder zwischen allen LAN/VPN-Netzen zu öffnen ersetzt diese Control-Plane-Freigabe nicht. Die im folgenden Abschnitt beschriebenen eng begrenzten Datenregeln zusätzlich erstellen.
9. Für jeden Neighbor unter Routing > Information > BGP > Neighbors Established sowie die erwarteten gelernten und annoncierten Präfixe kontrollieren. In AWS unter Tunnel Details beide Tunnel UP und BGP-Routen prüfen; VGW-Route-Propagation der betroffenen Subnet-Route-Tables kontrollieren. Erst danach erlaubten Anwendungstraffic und eine unerlaubte Quelle testen. Im vereinbarten Fenster einen Tunnel kontrolliert deaktivieren, Fortbestand der erwarteten Route/Anwendung über den anderen prüfen, wieder aktivieren und beide Nachbarschaften erneut prüfen; ohne tatsächlichen Failover-Test keine Redundanzabnahme behaupten.

Bei IPsec-Fehlern zuerst pro Tunnel Endpunkt, PSK, Proposals, IDs und NAT-T prüfen; bei BGP Active zuerst XFRM-Inside-Adressen, ASN, Peer-Aktivierung und Device Access. Eine provisorische statische Route mit Ping ist keine allgemeine BGP-Reparatur und kann den falschen Pfad verdecken. Bei verschwundenen Bestandsrouten oder unklarer Lifetime-/ID-Zuordnung keine weiteren Werte ausprobieren, sondern die neue Konfiguration stoppen und mit dem gesicherten Stand abgleichen.

IPsec-Profil und Tunnel prüfen

Nach dem Import oder bei manueller Konfiguration sollte man nicht blind auf den Status vertrauen.

Prüfen:

• Beide AWS-Tunnel existieren.
• IKE-Version passt zur AWS-Konfiguration.
• Encryption, Authentication, DH Group und PFS bilden pro Tunnel eine beidseitig erlaubte Proposal; Lifetimes und lokale Rekey-Timer werden separat gegen den genehmigten Plan geprüft und nicht allein auf numerische Gleichheit reduziert.
• Preshared Key ist pro Tunnel korrekt.
• Gateway type und Remote Gateway zeigen auf die jeweiligen AWS-Tunnelendpunkte.
• XFRM-Interfaces sind vorhanden und sinnvoll benannt.

Werden AWS-Tunneloptionen geändert, müssen die Sophos-Proposals weiterhin kompatibel sein und die getrennt dokumentierten Rekey-/DPD-Timer zum genehmigten Betriebsplan passen. Einseitige Änderungen an Algorithmus, DH/PFS, PSK oder Identität können Phase 1 oder Phase 2 verhindern; unterschiedliche lokale IKEv2-Lifetimes allein belegen keinen solchen Proposal-Fehler.

BGP oder statische Routen konfigurieren

Bei BGP prüft man unter Routing > BGP, ob lokale ASN, Neighbor, Remote ASN und annoncierte Netze stimmen. Die vollständige Einrichtung und Abnahme erklärt BGP auf Sophos Firewall konfigurieren. Unter Routing > Information > BGP sollten Neighbor, Summary und Routes erwartete Werte zeigen.

Bei statischem Routing müssen Routen zu AWS-Netzen über das passende XFRM-Interface gesetzt werden. Zusätzlich muss AWS die lokalen Präfixe kennen, entweder über statische VPN-Routen oder über die passende Route Table.

Für beide Varianten gilt: Routing muss in beide Richtungen stimmen. Ein Tunnel kann verbunden sein, während der Rückweg über Internet, NAT Gateway oder eine falsche Route Table läuft.

Firewall-Regeln erstellen

Route-based IPsec erstellt keine produktiven Firewall-Regeln automatisch, die fachlich sauber genug wären. Man sollte die Regeln bewusst erstellen und protokollieren.

Empfohlen:

1. Unter Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule eine Regel vom lokalen Netz zu AWS erstellen: Source zones LAN, Source networks and devices das lokale Netzwerkobjekt, Destination zones VPN und Destination networks das AWS-Netzwerkobjekt.
2. Unter Services nur die tatsächlich benötigten Dienste auswählen; Any eignet sich höchstens befristet zur Eingrenzung und sollte danach ersetzt werden.
3. Die Gegenrichtung mit Source zones VPN und Destination zones LAN nur erlauben, wenn AWS aktiv lokale Systeme erreichen muss.
4. Log firewall traffic für die Abnahme aktivieren.
5. Regelposition vor allgemeinen Drop- oder Catch-all-Regeln prüfen.

Wenn die passende Regel nicht greift, hilft Sophos Firewall Regel greift nicht: So findet man die Ursache.

Verbindung prüfen

Die Abnahme sollte immer beide Plattformen und echten Anwendungstraffic einbeziehen. Nur ein grüner Tunnelstatus ist zu wenig.

AWS prüfen

In AWS prüfen:

• VPC > Site-to-Site VPN Connections > Tunnel Details zeigt beide Tunnel.
• Tunnelstatus ist UP.
• Bei BGP sind Routen sichtbar.
• VPC- oder Transit-Gateway-Route-Table enthält erwartete Routen.
• Security Groups und NACLs erlauben den Test.
• CloudWatch-Metriken oder VPN-Logs zeigen keine wiederholten IKE-/DPD-Probleme.

Sophos Firewall prüfen

Auf der Sophos Firewall prüfen:

• Site-to-site VPN > Amazon VPC oder Site-to-site VPN > IPsec zeigt aktive Tunnel.
• Routing > Information > BGP zeigt Neighbor und gelernte Routen, falls BGP genutzt wird.
• Network > Interfaces zeigt XFRM-Interfaces.
• Log Viewer zeigt die erwartete Firewall-Regel.
• Packet Capture bestätigt Ein- und Ausgangsinterface, wenn Logs nicht reichen.

Testtraffic sauber wählen

Ein Test sollte mit einem konkreten Quellhost, Zielhost und Service geplant werden, zum Beispiel ICMP, RDP, SSH, HTTPS oder DNS. Wenn ICMP blockiert ist, ist ein Ping-Test nicht aussagekräftig. Besser ist ein Test mit dem Service, der später wirklich verwendet wird.

Typische Fehler

AWS-VPN-Fehler wirken oft wie IPsec-Probleme, obwohl Routing oder AWS-Security-Controls die Ursache sind. Die folgenden Fälle sind besonders häufig.

Nur ein Tunnel ist aktiv

Ein Tunnel reicht für einen ersten Test, aber nicht für sauberen Betrieb. Beide AWS-Tunnel haben eigene Endpunkte und eigene Parameter. Man prüft pro Tunnel Preshared Key, IKE/IPsec-Parameter, XFRM-Interface, BGP-Neighbor und Status in AWS.

BGP kommt nicht hoch

Wenn der Tunnel verbunden ist, aber BGP nicht peert, zuerst ASN, Neighbor-IP, lokale Annoncen und die Inside-Tunnel-Adressen prüfen. Ein eng begrenzter Sophos-Fall liegt vor, wenn der AWS-VPC-Tunnel auf der Firewall aktiv und verbunden ist, der BGP-Neighbor in Active bleibt, AWS das VPN als down und IPsec gleichzeitig als up zeigt und die laufende BGP-Konfiguration no bgp default ipv4-unicast enthält.

Nur wenn alle diese Merkmale passen, werden die aktuelle BGP-Konfiguration, Local AS und Neighbor-IP gesichert. Danach öffnet man über 3. Route Configuration > 1. Configure Unicast Routing > 3. Configure BGP die BGP-Konsole und aktiviert exakt den betroffenen AWS-Neighbor:

enable
conf t
router bgp <as-number>
neighbor <ip-address> activate
write

<as-number> wird durch die lokale Sophos-ASN und <ip-address> durch die Inside-Tunnel-Adresse des betroffenen AWS-Neighbors ersetzt. Anschliessend müssen BGP-Summary, gelernte und annoncierte Präfixe, AWS-Tunnelstatus und echter Traffic erneut geprüft werden. Fehlt no bgp default ipv4-unicast oder stimmen die AWS-Adressen und ASNs nicht, wird dieser Befehlssatz nicht angewendet. Der Befehl stammt aus der eng umrissenen SFOS-22-Fehlerbehebung für Amazon-VPC-Verbindungen und ist keine allgemeine BGP-Reparatur.

Vor conf t werden die aktuelle BGP-Konfiguration und der für die eigene Umgebung freigegebene Wiederherstellungsweg dokumentiert. Wenn der Neighbor danach nicht Established erreicht oder bestehende Routen verschwinden, wird nicht improvisiert, sondern ausschliesslich dieser vorab getestete Rückweg verwendet. Gibt es keinen solchen Rückweg, endet die Diagnose vor der Änderung und wird an Sophos Support eskaliert.

Tunnel grün, Instanz nicht erreichbar

Dann liegt die Ursache oft ausserhalb von IPsec: falsche AWS Route Table, fehlende Route Propagation, Security Group, NACL, Betriebssystem-Firewall, falsches Quellnetz oder fehlende Sophos-Firewall-Regel.

Rückweg läuft falsch

AWS muss den Rückweg zum lokalen Netz über VPN kennen. Lokal muss der Rückweg zur AWS-VPC über XFRM oder BGP laufen. Asymmetrisches Routing sieht im Tunnelstatus oft unauffällig aus, bricht aber reale Sessions.

MTU oder Fragmentierung stören Anwendungen

AWS Site-to-Site VPN und IPsec-Overhead können MTU-Probleme sichtbar machen. Wenn kleine Tests funktionieren, grössere Transfers oder bestimmte Anwendungen aber hängen, sollte man MSS/MTU, Fragmentierung und Paketmitschnitte prüfen.

Betrieb und Review

Nach der Inbetriebnahme sollte der Tunnel in einen normalen Betriebsprozess überführt werden. Dazu gehören ein Owner, ein dokumentierter Preshared-Key-Prozess, ein Änderungsfenster für IPsec-Parameter, Monitoring der Tunnel, regelmässige Failover-Tests und ein klarer Ablauf bei AWS- oder ISP-Änderungen.

Bei jeder Änderung an VPC-CIDR, Transit-Gateway-Routing, Route Tables, Security Groups, lokalen Netzen oder BGP-Announcements sollte man die VPN-Abnahme wiederholen. Cloud-VPN ist kein einmaliger Klick, sondern Teil der Netzarchitektur.

Neue Tunnel und Routen gezielt zurücknehmen

Vor der Änderung Backup, IPsec-Profile und Tunnelzuordnung, XFRM-Adressen, BGP-Nachbarn/Annoncen, Firewall-Regeln und AWS-Route-Tables samt Propagation sichern. Bei unerwarteten Annoncen, falschem Ziel oder unterbrochenem Bestandsverkehr zuerst die neu eingeführten Präfixe zurückziehen beziehungsweise die neue Verbindung deaktivieren und nur die geänderten Regeln/Routen auf den dokumentierten sicheren Stand zurücksetzen. Dabei bestehende BGP-Nachbarn, den globalen ASN und gemeinsam genutzte Gateways/VPC/Subnetze nicht löschen oder zurücksetzen. Die vorgesehenen Bestandsrouten, erlaubten Anwendungen und die Blockierung einer unerlaubten Quelle erneut kontrollieren. Ohne genehmigten Rückweg die Änderung vor der Aktivierung stoppen. Restore und Failover als getrennte Abläufe mit eigenen Erfolgskriterien planen.

FAQ