Virtuelle IP über IPsec auf mehrere Server weiterleiten

Eine virtuelle IP kann über einen bestehenden route-based IPsec-Tunnel auf mehrere interne Server zeigen. Der entfernte Standort verwendet dabei nur eine stabile Zieladresse. Sophos Firewall routet den Traffic über das XFRM-Interface und übersetzt die virtuelle Adresse anschliessend per DNAT auf eine Serverliste.

Das ist kein gewöhnliches Internet-DNAT: Tunnel, XFRM-Adressen, SD-WAN-Routen, VPN-Regeln und NAT müssen auf beiden Firewalls als ein gemeinsamer Pfad funktionieren.

Kurzablauf

1. Einen route-based Any-to-Any-Tunnel mit adressierten XFRM-Interfaces auf beiden Firewalls abnehmen.
2. Für jede Peer-XFRM-Adresse ein Gateway erstellen.
3. SD-WAN-Routen für Remote-Netz, lokale Netze und virtuelle IP spiegelbildlich konfigurieren.
4. Enge Firewall-Regeln für Remote-Quelle, virtuelle IP und benötigten Dienst erstellen.
5. Auf der Serverseite eine DNAT-Regel von der virtuellen IP auf eine Serverliste mit Round-robin anlegen.
6. Mehrere neue Verbindungen mit Log Viewer, Rule IDs, NAT Rule ID und Packet Capture prüfen.

⚠️ Eine grüne IPsec-Verbindung oder ein aktives XFRM-Gateway beweist noch nicht, dass DNAT und Rückweg funktionieren. Vor dem produktiven Wechsel muss der echte Anwendungsfluss in beiden Richtungen nachvollziehbar sein.

Wann dieses Design passt

Der Ablauf passt, wenn Hosts an einem entfernten Standort einen internen Dienst über eine feste virtuelle Adresse erreichen sollen, während die realen Serveradressen verborgen bleiben. Eine Serverliste kann neue Verbindungen beispielsweise auf zwei gleichwertige Anwendungsserver verteilen.

Für eine einzelne direkte Verbindung zu einem bekannten Server reicht meist eine normale Route plus Firewall-Regel. Soll ein Dienst aus dem Internet veröffentlicht werden, gilt stattdessen der klassische DNAT- oder WAF-Ablauf. Die allgemeine Tunnelplanung steht unter Site-to-Site IPsec VPN einrichten.

Nicht passend ist dieses Design für policy-based IPsec oder route-based Tunnel mit konkreten Traffic Selectors. Der hier beschriebene Pfad setzt einen route-based Tunnel mit Any als lokale und entfernte Netze, adressierte XFRM-Interfaces und explizites Routing voraus.

Beispieltopologie

Im Beispiel greifen Clients aus 192.168.3.0/24 auf die virtuelle Adresse 10.10.10.1 zu. Hinter Firewall 1 stehen die Server 172.16.16.2 und 172.16.16.3. Die XFRM-Transferadressen sind 10.255.255.1/30 und 10.255.255.2/30.

Remote clients                 Route-based IPsec                 Server site
192.168.3.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 10.10.10.1
                                                                        │ DNAT
                                                        ┌───────────────┴───────────────┐
                                                        172.16.16.2           172.16.16.3

Alle Adressen sind Beispielwerte und werden durch die echten Netze ersetzt. Die XFRM-Adressen müssen ein eigenes, nicht anderweitig verwendetes Transfernetz bilden. Die virtuelle IP darf nicht mit einem realen Host, Interface, VPN-Netz oder einer anderen NAT-Veröffentlichung kollidieren.

Tunnel und XFRM vorbereiten

Any-to-Any-Tunnel und Transferadressen

Auf Firewall 1 wird der Tunnel als Route-based (Tunnel interface) mit Respond only angelegt, auf Firewall 2 mit Initiate the connection. Auf beiden Seiten stehen Local subnet und Remote subnet auf Any.

Danach erhalten die XFRM-Interfaces unter Network > Interfaces ihre Transferadressen:

• Firewall 1, xfrm1: 10.255.255.1/30
• Firewall 2, xfrm2: 10.255.255.2/30

Die Phase-1- und Phase-2-Parameter, IDs und Authentifizierung müssen bereits sauber abgenommen sein. Änderungen an den XFRM-Adressen erfolgen nicht an einem ungeprüften produktiven Tunnel.

XFRM-Gateways erstellen

Für die SD-WAN-Routen braucht jede Firewall ein Gateway zur Peer-XFRM-Adresse:

• Firewall 1: Gateway IP 10.255.255.2 über xfrm1
• Firewall 2: Gateway IP 10.255.255.1 über xfrm2

Der Gateway-Status prüft nur das gewählte Monitoring-Ziel. Objekt, Health Check und Test werden im Artikel Custom Gateway erstellen und prüfen vollständig erklärt.

Regeln und SD-WAN-Routen aufbauen

Firewall 1 auf der Serverseite

Die eingehende Firewall-Regel erlaubt nur den vorgesehenen Datenstrom:

• Source zone: VPN
• Source networks and devices: 192.168.3.0/24
• Destination zone: Any, wie im Sophos-Beispiel für die virtuelle Adresse
• Destination networks: 10.10.10.1 und nur bei Bedarf weitere lokale Netze
• Services: nur der Anwendungsdienst, beispielsweise HTTPS
• Log firewall traffic: aktiviert

Any bei der Destination zone ist hier kein Grund für breite Quellen, Ziele oder Dienste. Die virtuelle IP ist keinem normalen Interface zugeordnet. Deshalb muss die Rule ID mit echtem Traffic bestätigt werden.

Die SD-WAN-Route auf Firewall 1 führt den Rückverkehr zum entfernten Netz über das XFRM-Gateway. Als Source networks werden die tatsächlich benötigten lokalen Netze und 10.10.10.1 eingetragen, als Destination networks 192.168.3.0/24.

Firewall 2 am entfernten Standort

Die ausgehende Regel verwendet LAN als Source zone und VPN als Destination zone. Quelle ist 192.168.3.0/24, Ziel mindestens 10.10.10.1, der Dienst entspricht der Anwendung und Logging bleibt für die Einführung aktiviert.

Die SD-WAN-Route auf Firewall 2 führt Traffic aus 192.168.3.0/24 zu 10.10.10.1 über das XFRM-Gateway. Route only through specified gateways verhindert einen Ausweichpfad über eine andere Route, wenn der Dienst ausschliesslich über diesen Tunnel erreichbar sein darf.

Ob diese Option gewünscht ist, gehört in den Ausfallplan. Ohne sie kann eine andere Route übernehmen; mit ihr verwirft SFOS den Traffic, wenn das angegebene Gateway nicht verfügbar ist. Den vollständigen Aufbau erklärt SD-WAN Route einrichten und testen.

Virtuelle IP per DNAT auf die Serverliste übersetzen

Auf Firewall 1 wird unter Rules and policies > NAT rules > Add NAT rule > New NAT rule eine gezielte Regel erstellt:

• Original source: 192.168.3.0/24
• Translated source: Original
• Original destination: 10.10.10.1
• Original service: der echte Anwendungsdienst, beispielsweise HTTPS
• Translated destination: Serverlistenobjekt mit 172.16.16.2 und 172.16.16.3
• Translated service: Original
• Load balancing method: Round-robin

DNAT erlaubt keinen Traffic von selbst. Firewall-Regel, SD-WAN-Route und Rückweg bleiben separate Voraussetzungen. NAT auf Sophos Firewall verstehen erklärt Original- und übersetzte Werte sowie die Regelreihenfolge.

Round-robin verteilt neue passende Verbindungen auf die Mitglieder der Serverliste. Ein wiederverwendeter Browser- oder Anwendungskanal ist deshalb kein sauberer Verteilungstest. Ausserdem bestätigt die Auswahlmethode nicht automatisch die Gesundheit der Anwendung auf jedem Backend. Beide Server werden separat mit neuen Sessions geprüft.

Den vollständigen Pfad abnehmen

Vor dem Test werden Tunnelstatus, XFRM-Adressen, Gateway-Status, Position der SD-WAN-Routen sowie Rule IDs dokumentiert. Danach entstehen mehrere neue Anwendungsverbindungen aus dem entfernten Netz zur virtuellen IP.

Im Log Viewer müssen Source 192.168.3.0/24, Destination 10.10.10.1, die erwartete Firewall Rule ID und die NAT Rule ID sichtbar sein. Der Traffic Count der SD-WAN-Route muss steigen. Ein enger Packet Capture zeigt, ob die Pakete am XFRM-Interface eintreffen, per DNAT an den ausgewählten Server gehen und die Antworten wieder über denselben Tunnel zurücklaufen.

Der Test wird mit beiden Backends wiederholt. Auf den Servern müssen die erwartete Clientadresse, der Dienst und der Rückweg stimmen. Ein Ping zur virtuellen IP ist kein Ersatz für einen echten HTTPS-, SAP- oder anderen Anwendungstest.

Für die kombinierte Prüfung von Regel, NAT und Paketpfad hilft Firewall-Regel mit Log Viewer und Packet Capture testen.

Fehler systematisch eingrenzen

Tunnel ist grün, aber die virtuelle IP antwortet nicht

Zuerst die SD-WAN-Route auf Firewall 2 prüfen: Matchen Source, Destination, Service und XFRM-Gateway? Danach Rule ID und NAT Rule ID auf Firewall 1 kontrollieren. Fehlt die NAT Rule ID, passen Original source, Original destination, Dienst oder Regelposition nicht.

DNAT trifft, aber der Server antwortet nicht

Serverlistenobjekt, lokalen Serverdienst und Gateway des Servers prüfen. Der Rückweg muss über Firewall 1 laufen, damit die bestehende NAT-Session die Antwort wieder auf 10.10.10.1 übersetzen kann. Eine zusätzliche breite MASQ-Regel kann die Diagnose verfälschen und wird nicht als Abkürzung ergänzt.

Nur ein Server erhält Verbindungen

Mehrere wirklich neue Sessions verwenden und bestehende Keep-alive-Verbindungen schliessen. Danach Serverliste, Load balancing method und NAT Rule ID vergleichen. Funktioniert ein Backend direkt nicht, ist zuerst dessen Dienst oder lokaler Pfad zu reparieren.

Traffic nimmt eine andere Route

Position und Traffic Count der SD-WAN-Routen sowie die ausgewählten XFRM-Gateways prüfen. Der Policy Tester bildet SD-WAN-Routen nicht vollständig ab; Log Viewer, Route lookup und Packet Capture gemeinsam verwenden.

Sicher zurückrollen

Vor der Änderung werden Konfigurationsbackup, Tunnelzustand, XFRM-Adressen, Gateway-Objekte, Regeln und Routen dokumentiert. Falls der neue Pfad nicht funktioniert:

1. Die neue DNAT-Regel deaktivieren.
2. Die beiden neuen SD-WAN-Routen deaktivieren.
3. Die spezifischen Firewall-Regeln auf den Vorzustand setzen.
4. XFRM-Gateways und Transferadressen nur entfernen, wenn keine andere Route sie verwendet.
5. Den ursprünglichen Tunnel- und Anwendungsfluss erneut testen.

Ein Gateway oder XFRM-Interface wird nicht gelöscht, solange Object usage noch Abhängigkeiten zeigt. Der sichere Backup- und Wiederherstellungsweg steht unter Sophos Firewall Backup und Restore.

FAQ