105549
Goto Top

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.
c509961cfedb860e5e196c87bd026479


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

Content-Key: 183462

Url: https://administrator.de/contentid/183462

Printed on: April 23, 2024 at 11:04 o'clock

Member: sk
sk Apr 12, 2012 at 22:04:51 (UTC)
Goto Top
Hallo,

sieht doch gut aus. Was ist nun konkret das Problem? Das Routing durch den Tunnel? Die Konfiguration der Zywalls?
Die Netze lassen sich doch wunderbar zu /20-Netzen zusammenfassen. Oder Du definierst die Ranges und verwendest diese in den Phase2-Policies.

Gruß
sk
Member: brammer
brammer Apr 13, 2012 at 05:03:48 (UTC)
Goto Top
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
Mitglied: 105549
105549 Apr 13, 2012 at 07:47:06 (UTC)
Goto Top
Danke für eure antworten aber ich habe es leider immer noch nicht ganz geschafft

Ich bin mir ich bin mir nicht ganz sicher ob ich euch richtig versteh aber ich hab jetzt folgendes versuch versucht:
Firewall Standort A
LAN1 von 10.10.10.1/24 auf 10.10.10.1/19 geändert
Remote Policy Objekt von SUBNET, 10.100.10.0/24 auf SUBNET, 10.100.0.0/19 geändert

Firewall Standort B
LAN1 von 10.100.10.1/24 auf 10.100.10.1/19 geändert
Remote Policy Objekt von SUBNET, 10.10.10.0/24 auf SUBNET, 10.10.0.0/19 geändert

1/ Ist das soweit Richtig?

/2 Ich kann seit der änderung auf das 19er netz den VPN Tunnel nicht mehr aufbauen. Ich habe glaubs irgend wo was vergessen zu ändern.
IKE Log:

ISAKMP SA [VPN_GW_SchulhausB] is disconnected
The cookie pair is : 0x7e7ea6c1e63889c3 / 0x0000000000000000
Send:[SA][VID][VID][VID][VID][VID][VID][VID][VID]
The cookie pair is : 0x7fcb9d8c0301f940 / 0x238ef2b9bb341c4f
Recv:[SA][VID][VID][VID][VID][VID][VID][VID][VID]
The cookie pair is : 0x238ef2b9bb341c4f / 0x7fcb9d8c0301f940
Recv Main Mode request from [10.10.9.10]
The cookie pair is : 0x7fcb9d8c0301f940 / 0x0000000000000000

/3 Static Routing Setting habe ich wie folgt angepasst:
Firewall Standort A
Destination IP 10.100.0.0
Subnet Mask 255.255.224.0
Gateway 10.100.10.1

Firewall Standort B
Destination IP 10.10.0.0
Subnet Mask 255.255.224.0
Gateway 10.10.10.1

Beim erstellen kommt immer die Fehlermeldung:
Warning Message
CLI Number: 0
Warning Number: 48000
Warning Message: 'Static route adding failed

Ich hoffe das ich mir nicht allzu dumm anstelle
Member: aqui
aqui Apr 13, 2012 at 08:42:27 (UTC)
Goto Top
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 !!
Member: sk
sk Apr 13, 2012 at 10:17:45 (UTC)
Goto Top
Zitat von @105549:
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
Member: aqui
aqui Apr 13, 2012 at 12:31:09 (UTC)
Goto Top
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... face-sad
Member: brammer
brammer Apr 13, 2012 at 12:41:13 (UTC)
Goto Top
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
Member: sk
sk Apr 13, 2012 at 14:00:48 (UTC)
Goto Top
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.

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

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
Mitglied: 105549
105549 Apr 16, 2012 at 08:02:06 (UTC)
Goto Top
Hallo Zusammen

Nach dem ich die beiden ZyWall zurückgesetz habe funkioniert der tunnel jetzt wuderbar.

1/ Sorry wagen dem falschen diagramm: Linke Siete ist Standort A und die Rechte Seite ist Standoet B

2/ Die Zywalls habe die Firmware 3.0

3/ ich habe jetzt nur noch das Problem das ich von den einzelne VLAN nicht mehr auf den Router kommen.
Wenn ich von dem Switch mit einer Sorce IP von einem anderem VLAN als der Router pinge, dann klappt es Tip Top
Aber die Cleints von den Verschiednen VLAN könen den Route nicht mehr erreichen.

Woran kann das liegen?

die IP Route Entries auf dem L3 Swicht

a-sw01# sh ip route

IP Route Entries

Destination Gateway VLAN Type Sub-Type Metric Dist.
------------------ --------------- ---- --------- ---------- ---------- -----
0.0.0.0/0 10.10.10.1 10 static 1 1
10.10.10.0/24 VLAN10 10 connected 1 0
10.10.11.0/24 VLAN11 11 connected 1 0
10.10.12.0/24 VLAN12 12 connected 1 0
10.10.13.0/24 VLAN13 13 connected 1 0
10.10.14.0/24 VLAN14 14 connected 1 0
10.10.15.0/24 VLAN15 15 connected 1 0
127.0.0.0/8 reject static 0 0
127.0.0.1/32 lo0 connected 1 0

Danke vielmals für euere Hilfe. Tut mir leid das ich vielleicht ein bisschen schwer von begriff bin. Das ist mein erstes Projekt mit InterVLAN Routing
Mitglied: 105549
105549 Apr 16, 2012 at 12:51:12 (UTC)
Goto Top
Ich habs jetzt hingekriegt und verstanden

Danke vielmals für eure hilfe
Member: aqui
aqui Apr 16, 2012 at 14:31:50 (UTC)
Goto Top
Die Clients brauchen IMMER die Switch VLAN IP als Gateway IP !! Dann klappt das auch !!