
105549
12.04.2012
Routen von remote subnetzen
Hallo Zusammen
ich habe zwei Standorte die mit einem IPSec Site to Site tunnel verbunden sind. Beide Standorte haben einen L3 Switch mit je 5 VLANs.
Das Problem ist das alle Clients in den verschieden VLANs über den Site to Site Tunnel in die versichenen VLAN von dem anderem Standort zugreifen müssen (z.B von Standort B VLAN 15 10.100.15.X/24 nach Standort B VLAN 10 10.10.10.X/24).
Mir ist klar das diese VLANs geroutet werden müssen aber ich weiss nicht wie und wo sie geroutet werden muss.
Ich hoffe das ihr mir weiterhelfen könnt
Liebe grüsse
Basti
ich habe zwei Standorte die mit einem IPSec Site to Site tunnel verbunden sind. Beide Standorte haben einen L3 Switch mit je 5 VLANs.
Das Problem ist das alle Clients in den verschieden VLANs über den Site to Site Tunnel in die versichenen VLAN von dem anderem Standort zugreifen müssen (z.B von Standort B VLAN 15 10.100.15.X/24 nach Standort B VLAN 10 10.10.10.X/24).
Mir ist klar das diese VLANs geroutet werden müssen aber ich weiss nicht wie und wo sie geroutet werden muss.
Ich hoffe das ihr mir weiterhelfen könnt
Liebe grüsse
Basti
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 183462
Url: https://administrator.de/forum/routen-von-remote-subnetzen-183462.html
Ausgedruckt am: 26.04.2025 um 23:04 Uhr
11 Kommentare
Neuester Kommentar
Hallo,
mal abgesehen das bei Zywall bei dir Standort B Heißen ist das doch nur eine Fingerübung...
Du hast auf beiden Seiten Netze die du zu einem /20 Zusammenfassen kannst und brauchst nur jeweils eine Route auf den Zywalls anlegen dass das /20 Netz auf der anderen Seiten des Tunnels zu erreichen ist.
Die genaue Formulierung bzw. eine Erläuterunf wie das geht, findest du hier.
brammer
mal abgesehen das bei Zywall bei dir Standort B Heißen ist das doch nur eine Fingerübung...
Du hast auf beiden Seiten Netze die du zu einem /20 Zusammenfassen kannst und brauchst nur jeweils eine Route auf den Zywalls anlegen dass das /20 Netz auf der anderen Seiten des Tunnels zu erreichen ist.
Die genaue Formulierung bzw. eine Erläuterunf wie das geht, findest du hier.
brammer
Das ist doch ganz einfach:
1.) Beide HP Switches haben eine default Route auf die jeweilige Firewall. Damit routen sie ALLES was sie lokal nicht kennen auf die jeweilige Firewall, was ja auch gut und richtig ist !
2.) Zentraler Routing Punkt sind also immer nur deine beiden Firewalls ! Nur hier kommen die statischen Routen hin !
3.) Hier (nur auf den Firewalls) gibst du nun folgende Routen ein:
(Dummerweise heissen alle beide "Standort B" in der Zeichnung, aber nehmen wir mal an das die FW an Switch A auch "Standort A" ist ?!)
Standort A:
Zielnetz: 10.100.0.0, Maske: 255.255.0.0, Gateway: <Tunnel IP Adresse B> oder Tunnelinterface
analog am
Standort B:
Zielnetz: 10.10.0.0, Maske: 255.255.0.0, Gateway: <Tunnel IP Adresse A> oder Tunnelinterface
Fertig ist der Lack was das Routing anbetrifft !
Achtung:
Ggf. musst du natürlich zusätzlich die Firewall Regeln entsprechend anpassen das Standort A und B die jeweils 10.10er und 10.100er Pakete passieren lässt !!
1.) Beide HP Switches haben eine default Route auf die jeweilige Firewall. Damit routen sie ALLES was sie lokal nicht kennen auf die jeweilige Firewall, was ja auch gut und richtig ist !
2.) Zentraler Routing Punkt sind also immer nur deine beiden Firewalls ! Nur hier kommen die statischen Routen hin !
3.) Hier (nur auf den Firewalls) gibst du nun folgende Routen ein:
(Dummerweise heissen alle beide "Standort B" in der Zeichnung, aber nehmen wir mal an das die FW an Switch A auch "Standort A" ist ?!)
Standort A:
Zielnetz: 10.100.0.0, Maske: 255.255.0.0, Gateway: <Tunnel IP Adresse B> oder Tunnelinterface
analog am
Standort B:
Zielnetz: 10.10.0.0, Maske: 255.255.0.0, Gateway: <Tunnel IP Adresse A> oder Tunnelinterface
Fertig ist der Lack was das Routing anbetrifft !
Achtung:
Ggf. musst du natürlich zusätzlich die Firewall Regeln entsprechend anpassen das Standort A und B die jeweils 10.10er und 10.100er Pakete passieren lässt !!
Zitat von @105549:
Remote Policy Objekt von SUBNET, 10.100.10.0/24 auf SUBNET, 10.100.0.0/19 geändert
Remote Policy Objekt von SUBNET, 10.100.10.0/24 auf SUBNET, 10.100.0.0/19 geändert
Ok, es handelt sich also um eine Linux-basierte Zywall ("USG-Serie") nicht um ein älteres Modell mit ZyNOS.
Die USGs können seit ZLD2.20 hinsichtlich des VPN-Routings - anders als die alten ZyNOS-Geräte - sowohl "routebased" als auch "policybased" arbeiten.
"Policybased" bedeutet in diesem Zusammenhang, dass die Routinginformationen aus der IPSec-SA entnommen werden.
"Routedbased" bedeutet, dass man den Traffic explitzit in den Tunnel "stopft". Dies geht mit einer sog. Policyroute - nicht aber wie hier bislang emfohlen mit einer statischen Route!
Das Funktionieren sowohl des einen Weges als auch des anderen ist an gewisse Rahmenbedingungen hinsichtlich der übrigen Konfiguration geknüpft. Unter anderem deshalb, weil es keine fixe Abarbeitungsreihenfolge der verschiedenen Routinginformationen gibt! Selbstverständlich gibt es eine Defaultkonfiguration, aber ob die Konfig derzeit noch in diesem Zustand ist, weiss vermutlich noch nicht mal der TO. Die Routingprioritäten lassen sich nämlich ändern und werden sogar (zwecks Lagacysupport) teilweise vom System selbst ohne Zutun des Admins geändert, wenn man ein Inplaceupdate von einer Konfiguration vor 2.20 auf eine Firmware >=2.20 durchführt!
Policyrouten haben per Default die zweithöchste Priorität nach der "direct route". Naheliegend wäre es deshalb, dem TO den Weg des routebased VPN zu empfehlen. Jedoch ist dies der "dreckige Weg", den man nach Möglichkeit vermeiden sollte, weil man sich mit unbedachten Policyrouten schnell der Möglichkeiten des geänderten Systemdesigns seit ZLD2.20 beraubt!
Auch wenn das Szenario hier wirklich simpel erscheint, kann man deshalb seriös eigentlich keine Konfigurationsempfehlung geben, ohne den Firmwarestand und die gesamte Konfig beider Seiten zu kennen!
@105549:
Schick mir mal die Datei startup-config.conf beider Seiten an sk-zyxelforum@arcor.de oder per PN übers Forum.
Kennwörter, PSKs usw. solltest Du selbstverständlich im Konfigfile "ausiXXXsen". Ist ein normales Textfile...
Gruß
sk
Man ist das kompliziert bei den Zywall Gurken.....hört sich bei Zywall nach dem Motto warum einfach machen wenn es megakompliziert auch geht...an ?! Ein Grund von sowas die Finger zu lassen. Das können andere und auch Freeware Produkte wie Astaro, pfSense usw. aber einfacher und effizienter, aber nundenn, muss der Batsian wohl dann mit leben mit soner Krücke
Können die Zywall Kisten ggf. dynamisches Routing ?? Das wär ja die einfache Lösung....
Dann aktivier doch einfach RIPv2 (OSPF werden sie ja sicher nicht können, oder ?) und lass die Routen dynamisch austauschen. Das geht dann auf Mausklick....oder vermutlich auch wieder nicht bei Zywall...
Können die Zywall Kisten ggf. dynamisches Routing ?? Das wär ja die einfache Lösung....
Dann aktivier doch einfach RIPv2 (OSPF werden sie ja sicher nicht können, oder ?) und lass die Routen dynamisch austauschen. Das geht dann auf Mausklick....oder vermutlich auch wieder nicht bei Zywall...
Hallo,
@aqui
laut Doku, weiter oben der link, kann das Ding doch OSPF.
Aber dann wird hier mit großen Kanonen auf kleine Spatzen geschossen!
brammer
@aqui
laut Doku, weiter oben der link, kann das Ding doch OSPF.
Aber dann wird hier mit großen Kanonen auf kleine Spatzen geschossen!
brammer
Zitat von @aqui:
Können die Zywall Kisten ggf. dynamisches Routing ?? Das wär ja die einfache Lösung....
Dann aktivier doch einfach RIPv2 (OSPF werden sie ja sicher nicht können, oder ?) und lass
die Routen dynamisch austauschen.
Können die Zywall Kisten ggf. dynamisches Routing ?? Das wär ja die einfache Lösung....
Dann aktivier doch einfach RIPv2 (OSPF werden sie ja sicher nicht können, oder ?) und lass
die Routen dynamisch austauschen.
Selbstverständlich können die OSPF. Dafür müsste man aber unter anderem einen GRE-Tunnel über den IPSec-Tunnel legen. Viel zu kompliziert und völlig unnötig!
Die Zywall leitet die Routinginformationen automatisch aus der Phase2-Policy ab. Man darf sie nur nicht aus Versehen daran hindern.
Zitat von @aqui:
Man ist das kompliziert bei den Zywall Gurken.... Das können andere und auch Freeware Produkte wie
Astaro, pfSense usw. aber einfacher und effizienter
Man ist das kompliziert bei den Zywall Gurken.... Das können andere und auch Freeware Produkte wie
Astaro, pfSense usw. aber einfacher und effizienter
Das hörte sich wahrscheinlich wiedereinmal schlimmer an, als es ist. Die USGs sind keinesfalls schwieriger zu konfigurieren, als etwa Astaro oder pfSense.
Im Gegenteil: Gerade die einfache Bedienung ist im Allgemeinen einer der Gründe, die für die Wahl einer Zywall sprechen! Bei einem Firmwarestand >=2.20 und einem so einfachen Szenario wie hier ist die Zywall genauso einfach zu konfigurieren, wie jeder TP-Link, Netgear, Draytek oder sonstige SOHO-Router. Hier bedarf es nur eines einzigen VPN-Tunnels und einer statischen Route, die auf den L3-Switch zeigt. Für den VPN-Tunnel gibt es sogar einen Wizard.
Allerdings bieten die USGs eben einiges mehr an Funktionsumfang, als die meisten SOHO-Router oder die alten ZyNOS-basierten Zywalls. Damit gibt es aber eben auch mehr Möglichkeiten, sich das Leben selbst schwer zu machen. Und was tut der Anwender, wenn er keinen Plan hat? Er klickt auf alles, "was nicht bei Drei auf den Bäumen ist"...
Das muss im vorliegenden Fall nicht so sein - meine Erfahrung ist aber, dass es fast immer so ist. Insbesondere, wenn die Leute eine Altkonfig vor 2.20 mit sich herumschleppen, denn da war es in der Tat etwas komplizierter.
Wenn man halbwegs auf aktuellem Firmwarestand ist und sich noch nah an deren Defaultkonfig befindet, konfiguriert das jede Oma blind in 2 Minuten!
Anspruchsvoller wird es halt nur, wenn man komplexere Szenarien abbilden muss oder man eine verhunzte Altkonfig mitschleppt. Was die Sache auch nicht unbedingt erleichtert ist, dass noch so viele Konfigurationsanleitungen im Web zu finden sind, die auf dem alten Systemdesign vor ZLD2.20 basieren. Die von Brammer verlinkte Anleitung ist so eine...
Gruß
Steffen