Zum Inhalt springen
Avanet

Virtuelle IP über IPsec auf mehrere Server weiterleiten

Sophos Firewall

Eine virtuelle IP kann über einen route-based IPsec-Tunnel auf mehrere interne Server zeigen. Der entfernte Standort adressiert nur die virtuelle IP. Auf der Firewall am Serverstandort übersetzt eine DNAT-Regel neue Verbindungen per Round robin auf eine IP-Liste der Backends.

Der entscheidende Punkt: DNAT, Firewall-Regel und Routing lösen drei verschiedene Aufgaben. DNAT übersetzt das Ziel, erlaubt aber keinen Traffic. Die Firewall-Regel erlaubt den Dienst und verwendet als Destination zone die Zone des übersetzten Ziels. Die Route bestimmt, welche Pakete in das XFRM-Interface gelangen.

Kurzablauf

  1. Einen funktionsfähigen route-based Any-to-Any-IPsec-Tunnel mit adressiertem XFRM-Interface verwenden.
  2. An beiden Standorten enge Routen für die tatsächlich benötigten Ziele konfigurieren.
  3. Auf der Server-Firewall die virtuelle IP und die Backends unter Hosts and services > IP host anlegen.
  4. Eine manuelle DNAT-Regel von der virtuellen IP auf die Backend-IP-Liste erstellen.
  5. Auf der Client-Firewall den Zugriff vom Clientnetz auf die VIP von LAN nach VPN erlauben. Auf der Server-Firewall die passende Regel von VPN zur Serverzone erstellen. Beide Regeln eng fassen und vor überlappenden Regeln platzieren.
  6. Health Check und mehrere wirklich neue Verbindungen mit Logs und Packet Capture prüfen.

⚠️ Eine grüne IPsec-Verbindung beweist weder DNAT noch Backend-Erreichbarkeit. Ändere die produktive Route erst, wenn der echte Anwendungsfluss inklusive Rückweg getestet ist.

Wann dieses Design passt

Das Design passt, wenn Clients an einem entfernten Standort einen internen Dienst über eine feste Adresse erreichen sollen und mehrere gleichartige Backends denselben Dienst anbieten. Für einen einzigen bekannten Server genügt meist Routing plus Firewall-Regel. Für eine Internet-Veröffentlichung gelten stattdessen der klassische DNAT- oder WAF-Ablauf.

Die Anleitung verwendet einen route-based Tunnel mit Any als Local subnet und Remote subnet. SFOS erstellt dafür ein adressierbares XFRM-Interface; statische, SD-WAN- oder dynamische Routen entscheiden anschliessend über den Tunnelpfad. Bei Traffic Selectors erstellt SFOS die Route selbst und die hier beschriebenen XFRM-Gateway-Schritte passen nicht unverändert. Die allgemeine Tunnelplanung erklärt Site-to-Site IPsec VPN einrichten.

Beispiel und anpassbare Werte

Clientstandort                 Route-based IPsec               Serverstandort
192.0.2.0/24  →  xfrm2 10.255.255.2  ⇄  10.255.255.1 xfrm1  →  VIP 198.51.100.10
                                                                          │ DNAT
                                                       ┌──────────────────┴──────────────────┐
                                                       10.0.20.21:443         10.0.20.22:443

192.0.2.0/24 und 198.51.100.0/24 sind Dokumentationsnetze; 10.0.20.0/24 ist das beispielhafte Servernetz. Alle Werte werden durch die eigene Adressplanung ersetzt. Das XFRM-Transfernetz darf nirgends sonst verwendet werden. Die virtuelle IP darf mit keinem Interface, Host, VPN-Netz und keiner anderen NAT-Veröffentlichung kollidieren.

Im Beispiel bleiben die Clientadressen durch Translated source (SNAT): Original sichtbar. Daher müssen beide Backends ihren Rückweg zu 192.0.2.0/24 über die Server-Firewall haben. Ist das organisatorisch nicht möglich, kann ein bewusst geplantes SNAT erforderlich sein; das verbirgt jedoch die Clientadresse und ist keine pauschale Reparatur für falsches Routing.

Voraussetzungen sichern

Vor der Änderung werden ein Konfigurationsbackup und folgende Ausgangswerte dokumentiert: IPsec-Status, XFRM-Adressen, Routing- und SD-WAN-Reihenfolge, Firewall- und NAT-Rule-IDs, bestehende Trefferzähler sowie die Default-Gateways der Backends. Bestehende Sessions werden nicht als Test verwendet.

Auf beiden Firewalls muss unter Site-to-site VPN > IPsec der bereits getestete Tunnel als Route-based (Tunnel interface) mit Any für beide Subnetze bestehen. Unter Network > Interfaces erhält das automatisch erstellte XFRM-Interface eine Transferadresse, im Beispiel 10.255.255.1/30 beziehungsweise 10.255.255.2/30. Das XFRM-Interface gehört immer zur Zone VPN.

IP-Objekte anlegen

Auf der Server-Firewall unter Hosts and services > IP host > Add werden drei Objekte angelegt:

  • VIP-App: IP version IPv4, Type IP, IP address 198.51.100.10.
  • Remote-Clients: Type Network, IP address 192.0.2.0, Subnet /24.
  • App-Backends: IP version IPv4, Type IP list, IP-Adressen 10.0.20.21,10.0.20.22.

Eine IP-Liste nimmt in SFOS 22 bis zu 800 kommagetrennte IP-Adressen auf und kann nicht Mitglied einer IP host group sein. Für dieses Design wird die Liste direkt als Translated destination (DNAT) verwendet. Nimm nur Server auf, die denselben veröffentlichten Dienst anbieten; Routing oder Anwendungszustand wird durch die Liste nicht automatisch vereinheitlicht.

Tunnelrouten festlegen

Beim Any-to-Any-Tunnel muss jede Seite den zu verschlüsselnden Traffic explizit zum XFRM-Interface routen. Mindestens erforderlich sind:

  • Clientstandort: Route für VIP-App (198.51.100.10/32) zum Serverstandort.
  • Serverstandort: Route für Remote-Clients (192.0.2.0/24) zum Clientstandort.

Ob dafür statische, dynamische oder SD-WAN-Routen verwendet werden, hängt von der vorhandenen Architektur ab. Sie werden nicht parallel ohne klare Präzedenz konfiguriert. Für eine statische Route werden unter Routing > Static routes Zielnetz, Peer-XFRM-Adresse als Gateway und das lokale XFRM-Interface angegeben.

Falls SD-WAN bereits der Routingstandard ist

Für ein XFRM-Gateway wird unter Routing > Gateways > Add die Peer-XFRM-Adresse als Gateway IP und das lokale XFRM-Interface als Interface gewählt. Ein aktivierter Health Check bewertet nur die konfigurierten Monitoring conditions. Als Ziel dient ein dauerhaft erreichbarer Host hinter dem Gateway; ein erfolgreiches ICMP- oder TCP-Probe beweist nicht, dass HTTPS auf beiden Backends funktioniert. Custom Gateway erstellen und testen erklärt das Gateway-Objekt, den Health Check und den Funktionstest ausführlich.

Auf der Client-Firewall wird die Route unter Routing > SD-WAN routes > IPv4 > Add eng gefasst: Incoming interface ist das clientseitige Interface, Source networks ist Remote-Clients, Destination networks ist VIP-App, Services ist HTTPS und unter Primary and backup gateways wird das XFRM-Gateway gewählt. Route only through specified gateways verwirft Traffic, wenn kein angegebenes Gateway erreichbar ist; ohne diese Option prüft SFOS weitere SD-WAN-Routen und danach die Default Route. Diese Entscheidung ist daher Teil des Ausfallplans.

Die Server-Firewall benötigt weiterhin eine wirksame Route zu Remote-Clients. Eine spiegelbildliche SD-WAN-Route verarbeitet Antwortpakete nicht automatisch: Das geschieht nur, wenn set routing sd-wan-policy-route reply-packet enable aktiviert ist. Prüfe diese globale Einstellung, bevor SD-WAN für den Rückweg eingesetzt wird; andernfalls gilt das vorhandene statische oder dynamische Routingkonzept.

SFOS wertet SD-WAN-Routen in Listenreihenfolge aus. Eine Route mit Destination networks: Any kann bei entsprechender Route precedence auch internen Traffic zum WAN lenken. Verwende hier deshalb die /32-VIP und platziere die spezifische Route vor breiteren Regeln. Der Traffic Count zeigt nur Traffic, dessen Quelle und Ziel zur Route passen; er ist kein Beweis für beide Richtungen oder für Backend-Gesundheit. Den allgemeinen Aufbau erklärt SD-WAN Route einrichten und testen.

DNAT-Regel erstellen

Unter Rules and policies > NAT rules wird IPv4 gewählt und mit Add NAT rule > New NAT rule eine Regel angelegt:

  • Rule name: DNAT-VPN-VIP-App
  • Rule position: oberhalb breiterer, ebenfalls passender NAT-Regeln
  • Original source: Remote-Clients
  • Translated source (SNAT): Original
  • Original destination: VIP-App
  • Translated destination (DNAT): App-Backends
  • Original service: HTTPS
  • Translated service (PAT): Original
  • Inbound interface: Any
  • Outbound interface: Any
  • Load balancing method: Round robin

Für VPN-Traffic verlangt SFOS bei den NAT-Interfaces Any, weil VPNs in diesem NAT-Feld nicht als Interfaces gelten. Das macht die Regel nicht breit, solange Quelle, Ziel und Dienst eng definiert sind.

Round robin sendet passende neue Anfragen der Reihe nach an die Server. Für Failover wird zusätzlich Health check aktiviert, im Beispiel mit Probe method TCP, Port 443 sowie bewusst gewählten Werten für Probe interval, Response time-out und Deactivate host after. Ohne Health Check betrachtet SFOS alle Listeneinträge als verfügbar und kann Traffic an einen ausgefallenen Server senden. Ein TCP-Check bestätigt nur, dass der Port antwortet; fachliche Anwendungsprüfungen bleiben separat nötig.

NAT-Regeln gelten nur für das erste Paket einer Verbindung. Regel- oder Listenänderungen verschieben bestehende Sessions deshalb nicht auf ein anderes Backend. SFOS prüft NAT-Regeln von oben nach unten und beendet die Suche beim ersten Treffer. NAT auf Sophos Firewall verstehen erklärt diesen Verbindungszustand und die Regelreihenfolge ausführlicher.

Passende Firewall-Regel erstellen

Auf der Client-Firewall wird eine Regel von Source zone LAN und Remote-Clients zu Destination zone VPN, Ziel VIP-App und Dienst HTTPS erstellt oder geprüft. Auf der Server-Firewall wird unter Rules and policies > Firewall rules > IPv4 > Add firewall rule > New firewall rule eine spezifische Accept-Regel angelegt:

  • Rule name: Allow-VPN-VIP-App
  • Rule position: oberhalb überlappender Regeln
  • Action: Accept
  • Log firewall traffic: aktiviert
  • Source zones: VPN
  • Source networks and devices: Remote-Clients
  • Destination zones: die Zone von App-Backends, im Beispiel LAN
  • Destination networks: VIP-App
  • Services: HTTPS

Bei eingehendem DNAT ermittelt SFOS zuerst die übersetzte Zieladresse und daraus die Destination zone. Die Destination networks der Firewall-Regel bleiben dagegen die ursprüngliche virtuelle IP. Any als Destination zone wäre hier unnötig breit. Firewall-Regeln werden ebenfalls von oben nach unten bis zum ersten Treffer ausgewertet; nach automatischer oder manueller Erstellung wird die Position deshalb nochmals kontrolliert.

Den vollständigen Pfad validieren

  1. Tunnelstatus, Gateway-Health und die effektive Route zu 198.51.100.10 prüfen.
  2. Trefferzähler der neuen NAT-, Firewall- und gegebenenfalls SD-WAN-Regel zurücksetzen oder Ausgangswerte notieren.
  3. Vom Clientstandort mehrere neue HTTPS-Verbindungen zur VIP öffnen; Keep-alive und Verbindungspools für den Test schliessen.
  4. Im Log Viewer Source, Firewall Rule ID und NAT Rule ID prüfen. VIP vor NAT und übersetztes Backend werden mit Packet Capture verglichen; ein uneindeutiges Destination-Feld allein ist kein Übersetzungsnachweis.
  5. Unter Diagnostics > Packet capture eng nach Client, VIP und beiden Backend-IP-Adressen filtern. Erwartet werden Eintritt über XFRM, DNAT auf einen Live-Server und Antworten über dieselbe Firewall.
  6. Auf jedem Backend Anwendungslog und Quelladresse prüfen. Der SD-WAN Traffic Count oder ein Ping zur VIP ersetzt diesen Anwendungstest nicht.

Die kombinierte Log- und Paketpfadprüfung zeigt Firewall-Regel mit Log Viewer und Packet Capture testen.

Fehler systematisch eingrenzen

Keine NAT Rule ID

Stimmen Original source, VIP-App, HTTPS und die NAT-Regelposition? Prüfe ausserdem, ob eine frühere NAT-Regel zuerst matcht. Nach einer Korrektur muss eine neue Verbindung entstehen, weil eine bestehende Session nicht neu gegen NAT ausgewertet wird.

NAT trifft, Firewall-Regel nicht

Die Destination zones müssen zur Zone der übersetzten Backend-Adressen passen, nicht zur VIP oder pauschal zu VPN. Destination networks bleibt VIP-App. Anschliessend Rule ID und Drop-Ereignis im Log Viewer erneut prüfen.

Ein Backend bleibt unerreichbar

Health-Check-Status, Probe-Methode und Port mit dem echten Dienst vergleichen. Ohne Health Check darf SFOS auch ein ausgefallenes Mitglied auswählen. Mit erfolgreichem TCP-Probe können dennoch Anwendung, TLS oder Autorisierung fehlschlagen; deshalb das Backend direkt im Servernetz und danach erneut über eine neue VIP-Session testen.

Antwort verlässt den falschen Weg

Default-Gateway oder spezifische Route des Backends, Route zu Remote-Clients und Packet Capture auf der Server-Firewall prüfen. Keine breite MASQ-Regel als Diagnoseabkürzung hinzufügen. Bei SD-WAN zusätzlich Listenposition, Route precedence, Gateway-Monitoring und die Wirkung von Route only through specified gateways kontrollieren.

Zustandsbewusst zurückrollen

Ein Rollback beginnt nicht mit dem Löschen von Objekten. Zuerst wird entschieden, ob bestehende Sessions kontrolliert auslaufen dürfen oder in einem Wartungsfenster beendet werden: Änderungen an NAT betreffen nur neue Verbindungen.

  1. Die neue DNAT-Regel deaktivieren, damit keine neuen VIP-Sessions entstehen.
  2. Aktive Anwendungssessions beobachten und gemäss Wartungsplan auslaufen lassen oder beenden.
  3. Die neue Firewall-Regel und ausschliesslich für diesen Pfad angelegte SD-WAN- oder statische Routen deaktivieren.
  4. Die zuvor dokumentierte Regel- und Route-Reihenfolge wiederherstellen und den ursprünglichen Anwendungsfluss testen.
  5. Neu angelegte Gateway- und IP-Objekte sowie neu vergebene XFRM-Adressen erst entfernen, wenn Object usage und die dokumentierte Ausgangskonfiguration keine Abhängigkeiten zeigen. Das XFRM-Interface wird vom Tunnel erstellt; einen bestehenden Tunnel nicht löschen, wenn andere Netze ihn verwenden.

Der sichere Sicherungsweg steht unter Sophos Firewall Backup und Restore.

FAQ

Muss die virtuelle IP auf einem Interface liegen?

Nein. Sie ist hier ein IP-Hostobjekt und wird durch die Route über den Tunnel erreichbar. Die Server-Firewall verwendet sie als Original destination der DNAT- und Firewall-Regel.

Ist Round robin bereits Hochverfügbarkeit?

Nein. Round robin bestimmt die sequenzielle Auswahl für neue Anfragen. Erst ein aktivierter Health Check verhindert die Auswahl eines als ausgefallen erkannten Servers; die Anwendung selbst, ihre Daten und der Rückweg müssen zusätzlich überwacht werden.