nixlos
Goto Top

VPN mehrere Standorte und mobile Clients

Hallo allseits,

vielleicht kann mir jemand den nötigen Denkanstoß geben...

Also folgende Ausgangssituation:

4 Standorte, eine Zentrale (A), 3 HomeOffice (B,C,D), externe Clients mit VPN Client
Hardware, Zyxel USG in verschiedener Dimension, NCP als VPN Client

Aktuell ist jeder Standort mit der Zentrale
jeweils local policy: Subnetz_Zentrale / remote policy: Subnetz_Standort

analog die externen Clients.

Die Standorte/Clients können problemlos mit der Zentrale kommunizieren.

Nun zum Ziel:

Die Standorte und externen Clients sollen untereinander kommunizieren können.

Ab jetzt benötige ich eure Hilfe.

Ich hätte grundsätzlich 3 "halbe" Ideen

1. Zusätzliche VPN Verbindungen zwischen den Standorten B,C, D untereinander, Nachteil sehr viele VPN Verbindungen
2. Routing über die Zentrale, Nachteil: erhöhter Traffic, wäre jedoch aufgrund der zu erwartenden Datenmenge kein Thema
Problem: hier benötige ich doch mehrere remote policies, richtig? ich weiß nicht wie ich diese bei Zyxel konfigurieren kann.
3. Concentrator Netzwerk - erfolgreich innerhalb der Standorte getestet, an den externen Clients scheitere ich derzeit.


Bei allen Lösungen schaffe ich es nicht die externen Clients anzubinden.
Stehe ich total auf dem Schlauch oder geht das nicht? Zusätzlich muss ich gestehen das VPN nicht gerade zu meinen Steckenpferden zählt.

Hoffe es kann mir jemand helfen face-smile

Vielen Dank im Voraus.

Grüße
nixlos

Content-Key: 258907

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

Ausgedruckt am: 28.03.2024 um 23:03 Uhr

Mitglied: aqui
aqui 05.01.2015 um 08:55:41 Uhr
Goto Top
Die Standorte und externen Clients sollen untereinander kommunizieren können.
Das sollten sie jetzt auch schon können !! Du schreibst ja "Die Standorte/Clients können problemlos mit der Zentrale kommunizieren.". Wenn sie das können muss auch eine Kommunikation untereinander möglich sein. Wenn das nicht der Fall ist zeigt das auf das du ein Fehler in der Routing Konfig der Komponenten gemacht hast und Routen schlicht und einfach fehlen.
Auch bei einer sternförmigen VPN Vernetzung können immer alle Außenstellen auch über die Zentrale kommunizieren ! Sicher, nicht ideal (hast du ja im Punkt 2. auch richtig erkannt) klappt aber wenn man alles richtig gemacht hat. Das mit den Remote Policies ist natürlich Unsinn, denn das betrifft einzig nur das IP Routing.
Besser ist natürlich von den Außenstellen auch noch direkte VPN Peers (Tunnel) zu den anderen Außenstellen aufzubauen. Auf solche banalen Grundlagen kommt man aber als Netzwerker auch selber ?!
Die remoten Clients bindet man zentral an die Zentrale an und fertig. Eigentlich sind das 3 Mausklicks...wenn man mal ins Handbuch sieht ?!
Mitglied: sk
sk 05.01.2015 um 11:10:41 Uhr
Goto Top
Hallo Nixlos,

eine Hub-and-Spoke-Konfiguration wäre hier schon das richtige. Full-Mesh ist auf Dauer administrativ nicht zu beherrschen.

Wie sieht denn das IP-Adressierungskonzept aus? Welche IP-Netze verwenden die Zentrale, die Homeoffices und die VPN-Clients? Verwenden letztere überhaupt definierte virtuelle IPs oder kommen sie derzeit noch mit der öffentlichen IP rein?

Gruß
sk
Mitglied: nixlos
nixlos 05.01.2015 um 14:34:12 Uhr
Goto Top
Hallo sk,

also die Zentrale sowie alle Außenstellen haben jeweils ein 24er Netz. Die Netze sind aufsteigend von der Zentrale ab 20.0/24 21.0/24 usw.
Wie Du richtig vermutete hast, die VPN-Clients kommen derzeit mit der öffentlichen IP rein.

grüße
Mitglied: nixlos
nixlos 05.01.2015 um 15:48:48 Uhr
Goto Top
Hallo aqui,

was soll ich dazu nun sagen...leider tut's nicht...

Ich suche mal in Richtung Routing weiter
Mitglied: sk
Lösung sk 05.01.2015, aktualisiert am 06.01.2015 um 02:27:29 Uhr
Goto Top
Zitat von @nixlos:
Wie Du richtig vermutete hast, die VPN-Clients kommen derzeit mit der öffentlichen IP rein.

Und wie soll dann den Homeoffices die Rückroute bekannt gemacht werden? Das ginge nur, wenn die Homeoffices auch über die Zentrale ins Internet gehen. Ich kann mir kaum vorstellen, dass das gewünscht ist.

Du must also dafür sorgen, dass die Absender-IPs der VPN-Clients "greifbar" sind. Um das Routing zu vereinfachen, sollte diese IP-Range aber so gelegt werden, dass das IP-Konzept der Gesamtstruktur per Supernetting durch ein einziges Netz beschrieben werden kann. Dabei ist auch an ein weiteres Wachstum des Netzes oder an eine Diversifizierung der Netzstruktur zu denken.
Es böte sich hier z.B. an, für die VPN-Clients das Netz x.y.16.0/24 zu reservieren. Bereits mit einer /21-Maske ließe sich dann die gesamte Struktur beschreiben, wobei noch Reserve für 3 weitere /24-Netze wäre (z.B. für weitere Homeoffices). Wenn diese 3 freien Netze irgendwann nicht mehr reichen würden, könnte man nach hinten ausbauen und die Gesamtstruktur mit einer /20-Maske definieren (16-31 im 3. Oktett). Ich würde mir von vorneherein 20 Bit für meinen Adressraum nehmen und mir gedanklich die 25 aufwärts im 3. Oktett für künftige HomeOffices und Niederlassungen reservieren. Die 3 freien /24-Netze von 17 bis 19 im 3. Oktett würde ich mir für weitere Netze in der Zentrale aufheben.

Die Phase2-Policies der Site-to-Site-IPSec-Tunnel definierst Du dann folgendermaßen:
a) Zentrale
local Subnet = x.y.16.0/20
remote Subnet=x.y.z.0/24 (die jeweilige Außenstelle)
b) Außenstellen/Homeoffices
local Subnet = x.y.z.0/24 (das jeweilige lokale Netz)
remote Subnet = x.y.16.0/20

Dadurch wissen alle Außenstellen, dass alle Teilnetze von x.y.16.0/20 über den VPN-Tunnel zu erreichen sind. Die Überschneidung von Remotenetz und lokalem Netz ist zumindest bei Verwendung von Zywalls, welche auf ZLD2.2x und höher basieren, unschädlich, weil das lokal direkt konnektierte Netz per Default eine höhere Routingpriorität hat, als die aus der Phase2-Policy gelernten Routen.
Man hätte das Ganze übrigens auch über Policy-Routen lösen können, aber der dargestellte Weg ist eleganter sowie interoperabler zu Drittanbietergateways.

Was nun natürlich noch fehlt, ist die Anpassung der VPNs zwischen der Zentrale und den VPN-Clients.
Im (mir nicht bekannten) NCP-Client muss man irgendwo die lokale IP-Adresse konfigurieren können. Das ist dann eine einzelne Adresse aus dem Netz x.y.16.0/24. Als Remotenetz ist das Netz x.y.16.0/20 anzugeben.
Auf Zywall-Seite ist in der Phase2-Policy selbstverständlich ebenfalls auf x.y.16.0/20 umzustellen. Das Remotenetz bleibt dynamisch und wird der Zywall erst beim Einwahl durch den Client bekannt.

Gruß
sk

P.S. Ggf. muss auch das Firewallregelwerk an den beteiligten Zywalls angepastst werden.
Mitglied: Dani
Dani 05.01.2015 um 19:44:20 Uhr
Goto Top
Moin sk,
Full-Mesh ist auf Dauer administrativ nicht zu beherrschen.
Tztz... das ist so nicht richtig. Solange man alles sauber dokumentiert, passiert nichts.


Gruß,
Dani
Mitglied: nixlos
nixlos 05.01.2015 aktualisiert um 20:04:21 Uhr
Goto Top
Hallo sk,

Wow, vielen Dank für die aufsührliche Antwort!

Du scheinst Zyxel öfter einzusetzen, zur Info, die USGs laufen alle auf ZLD3.30.

würdest Du mir noch die Alternative mit Policy-Routen noch verraten?

Zwei Gründe:
1. Vielleicht ist dieser nicht so "riskant" wenn bei der VPN Umstellung etwas schief geht sitze ich nen Tag im Auto face-wink
2. ich lerne immer gerne dazu

besten Dank und Grüße
nixlos
Mitglied: sk
sk 05.01.2015 aktualisiert um 21:24:05 Uhr
Goto Top
Zitat von @nixlos:
würdest Du mir noch die Alternative mit Policy-Routen noch verraten?
... Vielleicht ist dieser nicht so "riskant" wenn bei der VPN Umstellung etwas schief geht sitze ich nen Tag im Auto face-wink

Ist in der Tat ungefährlicher, wenn man für Durchführung der Änderungen selbst durch den zu ändernden VPN-Tunnel zugreift.

Per Default haben Policyrouten eine höhere Priorität als die solche, die die Zywall automatisch aus der Phase2-Policy der Tunnelkonfiguration ableitet. Oder anders ausgedrückt: Man kann letztere per Policyroute "übersteuern". Voraussetzung dafür ist allerdings, dass man in der IPSec-Phase2-Policy das Policy-Enforcement deaktiviert hat (was aber die Default-Einstellung ist).

Wie geht das nun?

Auf den Zywalls der Homeoffices erstellst Du unter Configuration->Network->Routing->Policy-Route jeweils folgende neue Regel:
Incoming Interface = any
Source Address = any
Destination Address = x.y.16.0/20
Service = any
Next Hop = VPN-Tunnel
VPN Tunnel = <der Tunnel zur Zentrale>

Achte darauf, dass die (globale) Option "Use Policy Route to Override Direct Route" NICHT aktiviert ist, denn diese erhöht die Priorität der Policyrouten über die der direkt verbundenen Netze!

Auf der Zywall in der Zentrale sind 3 Policyrouten erforderlich. Für jedes Homeoffice eine mit dem jeweiligen Remotenetz der Außenstelle als Ziel. Zwar weiss die Zywall bereits aus der Tunneldefinition, dass dieses Zielnetz hinter dem Tunnel liegt, jedoch assoziiert sie diesen Weg nur für das lokale Netz der Zentrale als Source, da nur dieses Netz bisher in der IPSec-Phase2-Policy erfasst ist.
Alternativ kannst Du auch eine "Concentrator-Konfiguration" einrichten. Dann sparst Du Dir die Policyrouten in der Zentrale.
Die Konfiguration des Client-to-Site-VPNs würde ich wie zuvor beschrieben anpassen. Zywall-seitig könnte man zwar auch hier mit einer Policyroute arbeiten, aber es bringt keine Vorteile. An die Client-Konfiguration musst Du ohnehin in jedem Fall ran, um die vorgetäuschte lokale IP zu konfigurieren.

Gruß
Steffen
Mitglied: nixlos
nixlos 06.01.2015 um 02:27:13 Uhr
Goto Top
Hallo sk,

vielen Dank für die Erklärung der Policy Route Config.
Leider habe ich es nicht über diesen Weg nicht geschafft.

Falls Du noch Lust hast fände ich super wenn mir noch nen Tipp hierzu hast - rein akademisch.

Die gute Nachrict - es läuft, habe es über deine Lösung mit dem .16.0/20 Netz gelöst. Was soll ich sagen, tut alles wie es soll - perfekt!

VIELEN DANK.

Jetzt noch ein paar Clients umstellen und die Welt ist in Ordnung.

Auf die Gefahr hin das ich mich wiederhole - DANKE.

Grüße
Ralph