Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen (A bis Z)

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

VPN mehrere Standorte und mobile Clients

Frage Netzwerke Router & Routing

Mitglied: nixlos

nixlos (Level 1) - Jetzt verbinden

05.01.2015, aktualisiert 06.01.2015, 1143 Aufrufe, 9 Kommentare

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

Vielen Dank im Voraus.

Grüße
nixlos
Mitglied: aqui
05.01.2015 um 08:55 Uhr
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 ?!
Bitte warten ..
Mitglied: sk
05.01.2015 um 11:10 Uhr
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
Bitte warten ..
Mitglied: nixlos
05.01.2015 um 14:34 Uhr
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
Bitte warten ..
Mitglied: nixlos
05.01.2015 um 15:48 Uhr
Hallo aqui,

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

Ich suche mal in Richtung Routing weiter
Bitte warten ..
Mitglied: sk
LÖSUNG 05.01.2015, aktualisiert 06.01.2015
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.
Bitte warten ..
Mitglied: Dani
05.01.2015 um 19:44 Uhr
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
Bitte warten ..
Mitglied: nixlos
05.01.2015, aktualisiert um 20:04 Uhr
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
2. ich lerne immer gerne dazu

besten Dank und Grüße
nixlos
Bitte warten ..
Mitglied: sk
05.01.2015, aktualisiert um 21:24 Uhr
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

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
Bitte warten ..
Mitglied: nixlos
06.01.2015 um 02:27 Uhr
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
Bitte warten ..
Ähnliche Inhalte
Router & Routing
gelöst Standort VPN- ein einziger Rechner nicht erreichbar (11)

Frage von lienas zum Thema Router & Routing ...

Windows Netzwerk
DNS Auflösung - mehrere Standorte (7)

Frage von detox91 zum Thema Windows Netzwerk ...

Router & Routing
Handy - falscher Standort wegen VPN (7)

Frage von Donaufisch zum Thema Router & Routing ...

Router & Routing
gelöst Drei Standorte über VPN miteinander Verbinden (9)

Frage von Diamond72 zum Thema Router & Routing ...

Neue Wissensbeiträge
Windows Update

Novemberpatches und Nadeldrucker bereiten Kopfschmerzen

(14)

Tipp von MettGurke zum Thema Windows Update ...

Windows 10

Abhilfe für Abstürze von CDPUsersvc auf Win10 1607 und 2016 1607

(7)

Tipp von DerWoWusste zum Thema Windows 10 ...

RedHat, CentOS, Fedora

Fedora 27 ist verfügbar

Information von Frank zum Thema RedHat, CentOS, Fedora ...

Heiß diskutierte Inhalte
Server
Bilder aus dem Web mit CSV runterladen (30)

Frage von Yannosch zum Thema Server ...

Windows Update
WSUS 4 (Server 2012 R2) - Windows 10 Updates nicht möglich (12)

Frage von c0d3.r3d zum Thema Windows Update ...

Windows Userverwaltung
gelöst Administrator hat alle Rechte verloren (10)

Frage von mrdead zum Thema Windows Userverwaltung ...