Zyxel Firewall [VPN Routing] - Routing des Datenverkehrs vom VPN-Tunnel zu einem anderen VPN-Standort [VPN Routing]

Dieser Artikel erklärt, wie man Datenverkehr von einem Site-to-Site-Tunnel in einen anderen Tunnel leitet, um Geräte hinter einer Site-to-Site-Verbindung zu erreichen. Er erklärt, wie man den Datenverkehr von Standort A nach Standort B durch die HQ-Firewall / das Gateway leitet (Route Site-to-Site durch Site-to-Site-Tunnel), Fehlerbehebung/Probleme, Routing-Regeln, wenn Sie möchten, dass Ihre Client-VPNs einen Server erreichen, der sich an einem anderen Standort befindet (Client-to-Site durch Site-to-Site), SecuExtender IPSec Konfiguration.

Alternative 1: Routing des Datenverkehrs vom Remote-VPN-Tunnel zu einem anderen Site-to-Site-VPN

1) Einrichten von VPN-Tunneln

Vorraussetzung: Es muss bereits eine Site-to-Site-Verbindung zwischen den Standorten bestehen.

Sobald der Tunnel aufgebaut ist, werden wir ihn mit L2TP über IPSec verbinden.

Eine Anleitung zum Einrichten eines VPN finden Sie unter:

VPN - IPSec Standort-zu-Standort-VPN konfigurieren

Hier finden Sie Informationen zu L2TP über IPSec:

VPN - Konfigurieren von L2TP über IPSec VPN mit PSK [Stand-alone-Modus]

Um den Prozess zu vereinfachen, können Sie den Assistenten zum Erstellen eines VPN-Tunnels und L2TP over IPSec verwenden.

2) Konfigurieren von Routing-Richtlinien

Um den Datenverkehr zwischen dem Hauptsitz (HQ) und Standort B zu ermöglichen, müssen Sie Richtlinien und Routen für den VPN-Tunnel einrichten.

Auf der HQ-Firewall:

1. Erstellen Sie eine Richtlinienroute, die eingehende Anfragen aus dem L2TP-Tunnel in den Site-B-Tunnel leitet. So werden eingehende Anfragen vom L2TP-Tunnel durch die HQ-Firewall in den Tunnel von Standort B geleitet

   • Quelle: L2TP-Client-Subnetz
   • Ziel: Standort B-Subnetz
   • Nächstes Ziel: VPN-Tunnel "Standort B-Tunnel".

Beachten Sie, dass die Zieladresse die Adresse unseres Kunden ist.

2. Erstellen Sie eine Richtlinie, die Antworten von Standort B zulässt und sie in den Tunnel zu Standort B leitet. Dies ist entscheidend für den Verkehr, der von Standort B zum Hauptquartier zurückkehrt.

• • Quelle: Beliebig
  • Ziel: L2TP-Tunnel
  • Nächster Punkt: VPN-Tunnel "L2TP-Tunnel"

Am Standort B:

1. Erstellen Sie außerdem eine Richtlinienroute, die eingehende Anfragen vom Hauptquartier zulässt und sie in den Tunnel zu Standort B weiterleitet:

Stellen Sie sicher, dass das asymmetrische Routing für eine nahtlose Konnektivität aktiviert ist. Sie können diese Option hier finden:

Konfiguration > Sicherheitsrichtlinie > Richtlinienkontrolle

Wenn Sie diese Funktion aktivieren, wird die "dreieckige" Route aktiviert, so dass die Firewall eine asymmetrische Routentopologie im Netzwerk verwenden kann und ein Zurücksetzen der Verbindung verhindert wird, wenn Antworten zurückkommen.

Wenn Sie diese Schritte befolgen, können Sie den Datenverkehr zwischen Ihren VPN-Tunneln effektiv routen und eine reibungslose und sichere Verbindung zwischen dem Hauptsitz und Standort B aufrechterhalten.

Alternative 2: Routing vom VPN-Tunnel zu einem anderen VPN-Standort

1) Verkehr von Standort A zu Standort B über den Hauptstandort leiten

Wenn Sie möchten, dass Standort A Standort B erreicht und umgekehrt, müssen Sie auf jeder Firewall Richtlinienrouten erstellen, damit die HQ-Firewall weiß, wohin sie die eingehenden Anfragen und die Antworten senden soll.

1.1 Richtlinienrouten - HQ-Firewall

Auf der HQ-Firewall müssen Sie zunächst eine Regel konfigurieren, die von Standort A kommende Anfragen an Standort B zulässt. Diese müssen im Tunnel an Standort B weitergeleitet werden, was sowohl für ICMP-Anfragen (von Standort A kommend) als auch für ICMP-Antworten (von Standort B kommend und nun wieder an Standort B zurückgehend) wichtig ist.

Eingehend: any - Quelle: "Standort A Subnetz" -> Ziel: "Standort B-Subnetz" - Next-hop Tunnel - "Standort B VPN-Tunnel"

Zweitens müssen Sie eine Regel konfigurieren, die Antworten von Site B erlaubt, die an Site A gehen (wenn Sie eine Anfrage von Site A gesendet haben), und diese müssen in den Site A-Tunnel geroutet werden. Dies ist sowohl für ICMP-Anfragen (die von Standort B kommen) als auch für ICMP-Antworten (die von Standort B kommen und nun wieder an Standort A zurückgehen) wichtig.

Eingehend: any - Quelle: "Standort B Subnetz" -> Ziel: "Standort A-Subnetz" - Next-hop Tunnel - "Standort A-VPN-Tunnel"

1.2 Richtlinien-Routen - Standort A Firewall

Dann müssen Sie eine Regel konfigurieren, die Anfragen von Standort B zulässt, die an Standort A gehen (wenn Sie eine Anfrage von Standort B gesendet haben). Dies ist sowohl für ICMP-Anfragen (die von Standort B kommen) als auch für ICMP-Antworten (die von Standort B kommen und nun wieder an Standort Bzurückgehen) wichtig.

Eingehend: any - Quelle: "Standort B Subnetz" -> Ziel: "Standort A-Subnetz" - Next-hop "Standort A-VPN-Tunnel"

1.3 Richtlinien-Routen - Standort-B-Firewall

Dann müssen Sie eine Regel konfigurieren, die Anfragen von Standort A erlaubt, die an Standort B gehen (wenn Sie eine Anfrage von Standort A gesendet haben). Dies ist sowohl für ICMP-Anfragen (von Standort A kommend) als auch für ICMP-Antworten (von Standort A kommend und nun wieder nach Standort Azurückgehend) wichtig.

Eingehend: any - Quelle: "Standort A Subnetz" -> Ziel: "Standort B-Subnetz" - Next-hop "Standort B-VPN-Tunnel"

2) Verifizierung / Fehlerbehebung

Wenn Sie alle Richtlinienrouten konfiguriert haben, ist es wichtig zu überprüfen, ob das Routing tatsächlich funktioniert. Vielleicht gibt es in Ihren Firewall-Regeln widersprüchliche Routen (Überschneidungen von Subnetzen, bestehende Richtlinien/statische Routen usw.) oder es ist etwas anderes falsch.

Beachten Sie, dass dies sehr verwirrend sein kann, da es viele Routen gibt, um die Sie sich kümmern müssen. Am einfachsten ist es, wenn Sie alle Paketströme manuell auf einem Blatt Papier aufzeichnen (PC -> Gateway A - das Gateway muss an die Zentrale weiterleiten, die Zentrale muss an den Standort B weiterleiten - der Standort B muss die Antwort wieder an die Zentrale zurückleiten ... usw.) und sich fragen: "Wer ist für das Routing verantwortlich, und ist das Routing vorhanden?".

Unten finden Sie zwei Szenarien, in denen Sie möglicherweise die Konfigurationen ändern müssen, damit das Routing funktioniert.

2.1 Test durch Anpingen der Firewall

Das erste Szenario ist ein Ping-Test von einem PC an Standort A zu einem Server oder PC an Standort B:

Roter Pfeil - ICMP [ping] Anfrage

Grüner Pfeil - ICMP-[ping]-Antwort

2.2mRichtlinien-Routen - Firewall Standort A

Wenn Sie das Gateway von Standort B vom Gateway von Standort A aus anpingen (integriertes ICMP-Tool), gilt das Policy Routing auf Standort A nicht für die Antworten von Standort B, wenn Standort B versucht, das Gateway von Standort A anzupingen.

Daher benötigen wir eine Richtlinienroute, die wie folgt aussieht:

Eingehend: ZyWall- Quelle: "Standort B-Subnetz" -> Ziel: "Standort A-Subnetz" - Next-hop "Standort A-VPN-Tunnel"

2.3 Richtlinien-Routen - Standort-B-Firewall

Der erste Test, den Sie durchführen können, besteht darin, die Firewall anzupingen. Da das Routing, das Sie jetzt erstellt haben, jedoch NUR für eingehende Verbindungen gilt (mit Ausnahme von Zywall), bedeutet dies, dass das Routing nicht angewendet wird, wenn der Ping von Standort A kommt, die Firewall von Standort B erreicht und die Firewall dann für die Beantwortung dieser Anfrage verantwortlich ist. Die ICMP-Antwort sieht dann wie folgt aus:

ICMP-Anfrage

PC (ICMP-Anfrage) -> Standort A-Gateway -> VPN-Tunnel zum HQ -> HQ-Gateway sendet Verkehr an Standort B-Gateway

ICMP-Antwort

Standort B-Gateway (ICMP-Antwort) -> Standort B-Gateway -> VPN-Tunnel zu HQ -> HQ-Gateway sendet Datenverkehr an Standort A-Gateway -> Standort A-Gateway sendet Pakete zurück an PC

Daher ist diese Richtlinienroute erforderlich:

Eingehend: ZyWall- Quelle: "Standort A Subnetz" -> Ziel: "Standort B-Subnetz" - Next-hop "Standort B-VPN-Tunnel"

2.4 Test durch Anpingen eines Servers / PCs

Da sich der PC im Netzwerk 192.168.20.0/24 und der Server im Netzwerk 192.168.30.0/24 befindet, erkennt der Server das Netzwerk 192.168.20.0/24 nicht und wird daher sehr wahrscheinlich ICMP-Pakete blockieren, die von unbekannten Subnetzen kommen. Führen Sie daher bei Tests immer:

• Deaktivieren Sie alle integrierten Firewalls (z. B. Windows Defender / Firewall)
• Deaktivieren Sie andere auf dem Server / PC installierte Antiviren- und Endpunktsicherheitssoftware.

Weiterleitung des Client-to-Site-Verkehrs durch einen Site-to-Site-Tunnel

Achtung! Dies funktionierte nicht mit Dynamic VPN! Bitte wählen Sie nur Site2Site VPN!

1) Konfigurieren Sie SecuExtender IPSec VPN

Um IPSec VPN-Clients in einen anderen Tunnel zu leiten, müssen sie feste IP-Adressen verwenden.

Wenn viele verschiedene Clients geroutet werden sollen, empfiehlt es sich, IPs zu verwenden, die nahe beieinander liegen, so dass ein Bereich erstellt werden kann. Dadurch wird die Anzahl der erforderlichen Routen reduziert.

Das Subnetz, in dem sich die IP-Adressen befinden, muss nicht auf der Firewall vorhanden sein.

Geben Sie die feste IP-Adresse auf dem IPSec VPN Client ein

2) Konfigurieren Sie das Firewall-Routing

Navigieren Sie auf der Firewall zu

Configuration > Object > Address

und klicken Sie auf

Add

um den Bereich für die IPSec VPN Client IP-Adressen zu erstellen.

Nun können wir die notwendigen Routen unter

Configuration > Network > Routing

mit einem Klick auf das Feld

Add

2.1 Vor Ort eine Firewall

Wir müssen zwei Routen erstellen:

• Eine für den ausgehenden Verkehr, also vom dynamischen VPN-Client-Tunnel zum entfernten Subnetz über den Site-to-Site-Tunnel.

• Eine für den eingehenden Verkehr, also vom entfernten Subnetz über den Site-to-Site-Tunnel in den VPN-Client-Tunnel.

Die neuen Routen sollten in etwa so aussehen:

Eine weitere Möglichkeit, den eingehenden Verkehr aus dem entfernten Subnetz über den entfernten VPN-Tunnel zu leiten, ist die Aktivierung der "asymmetrischen Route":

Dadurch wird die "dreieckige" Route aktiviert, wodurch die Firewall die Verwendung einer asymmetrischen Routentopologie im Netzwerk zulässt und die Verbindung nicht zurücksetzt, wenn die Antwort zurückkommt.

2.2 Firewall am Standort B

Am entfernten Standort kann es notwendig sein, ähnliche Routen zu erstellen, damit das Gerät am Hauptstandort weiß, wie es den Verkehr der VPN-Clients, die von der Zweigstelle kommen, behandeln soll.

Am Hauptstandort erstellen wir den IP-Bereich für die entfernten VPN-Clients, damit wir ihn für die Weiterleitung des Datenverkehrs verwenden können.

Nun erstellen wir die entsprechenden Routen auch am Standort der Hauptniederlassung.

Eine ausgehende Route, also vom HQ-Subnetz über den Site-to-Site-Tunnel zu den entfernten VPN-Clients.

Und eine eingehende Route, also vom entfernten VPN-Client-Bereich über den Site-to-Site-Tunnel in das lokale LAN der Zentrale. Wenn der Verkehr in ein lokales Subnetz geroutet wird, wählen wir "Auto" als Next-Hop, das USG verwaltet dies automatisch.

Die Routen sollten in etwa wie folgt aussehen:

+++ Sie können Lizenzen für Ihre Zyxel VPN Clients (SSL VPN, IPsec) mit sofortiger Lieferung per 1-Klick kaufen: Zyxel Webstore +++