VPN mehrere Standorte und mobile Clients

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

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.

Moin sk,
Tztz... das ist so nicht richtig. Solange man alles sauber dokumentiert, passiert nichts.


Gruß,
Dani

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