Apr 03, 2013

6656

OpenVPN mit Windows Servern und Routing RAS oder doch VPN der Router

OpenVPN mit Windows Servern und Routing/RAS oder doch die VPN-Funktion der Router verwenden - Was sagt ihr??

Hallo zusammen!

ich habe vor einiger Zeit mal eine OpenVPN Verbindung zwischen zwei Standorten nach dieser Anleitung erstellt und konnte von einem Win7-Client in Standort B auf Netzlaufwerke des 2008-Servers in Standort A zugreifen. Das hat bisher gut funktioniert und gereicht... Nun besteht die Anforderung, dass nicht mehr nur dieser eine Client von Standort B auf den Server in A zugreifen muss, sondern noch weitere (Win7-)Clients... Ich gehe jetzt einfach mal davon aus, dass es zudem nicht lange dauern wird, bis der Zugriff auch in die andere Richtung benötigt wird.

Um dies zu realisieren, habe ich mir folgendes überlegt, weiß jedoch nicht, ob das a) überhaupt so sinnvoll ist wie ich es mir denke und b) ich es umzusetzen ist:

Die Verbindung wurde bisher zw. Client Standort B (Win7) und Server Standort A (2008) hergestellt. Jetzt habe ich gedachte, man stellt eine Verbdindung zw. Server Standort A (2008) und Server Standort B (2008) her, so dass z.B. Client 1B, Client 2B usw. Server B als "Sprungbrett/Gateway" nutzen, um auf die Daten auf Server A zuzugreifen. Und das ganze auch andersherum, also von Standort A auf Server B.... Ich habe gelesen, dass man einem Windows Server eine Rolle als Router ("Routing/RAS") installieren kann....... Ganz simpel wäre es ja, die Netzlaufwerke von Server A auf Server B einzubinden und diese dann irgendwie an die Clients 1B, 2B usw. zu verteilen, aber meines Wissens geht sowas gar nicht, "Netzlaufwerke von Netzlaufwerken" zu erstellen, oder?

Denke ich in die richtige Richtung oder bin ich ganz weit weg? Wie würdet ihr den Zugriff der jeweiligen Clients auf den jeweils entfernten Server realisieren? Vielleicht mit den VPN Möglichkeiten der jeweiligen Router der Standorte? Dies sind auf der einen Seite ein Modell von Cisco, auf der anderen Seite eins von Netgear. Die genauen Beschreibungen hab ich jetzt nicht zur Hand. Zur Info: Beide Standorte verfügen über feste IP Adressen, das Thema DynDNS ist also nicht relevant.

Ich freue mich über jeden nützlichen Tipp und bin gespannt, ob ich mit meiner Idee gar nicht so falsch liege bzw. diese auch realisieren kann

Vielen Dank euch allen!!!

PS: Ich habe mich mal für diesen Thread für den Bereich "Microsoft Windows Server" entschieden, da mein Lösungsansatz ja in diese Richtung geht. Ihr könnt mich aber gerne in einen besseren/passenderen Bereich verschieben, liebe Admins

Please also mark the comments that contributed to the solution of the article

Content-Key: 204353

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

Printed on: April 25, 2024 at 14:04 o'clock

38 Comments

Latest comment

Hi,

also VPN mit zwei verschiedenen Router-Herstellern, dazu auch noch (vermutlich) Home-Router/SOHO-gerät (Netgear), gestaltet sich nicht so einfach bis unmöglich.
Eine saubere Lösung wäre z.B. 2x Cisco/Sophos/Zyxel/LANCOM/whatever mit einem permanenten Tunnel zwischen den Geräten.
Alternative: 2 PCs/Server mit OpenVPN, die entsprechend den permanenten Tunnel zwischen sich aufbauen.
Grundsätzlich geht das auch mit Routing & RAS, ich selbst würde - IMHO - die Lösung mit den zwei Gateways bevorzugen. Gerade, wenn noch weitere Clients hinzukommen sollten.

Hallo Manuel!

Danke für deine Antwort, hab mir schon gedacht, dass das nicht so einfach ist, ein permanentes VPN zwischen den Routern zu realisieren.

Was genau meinst du bitte mit "die Lösung mit den zwei Gateways"?

Danke und schönen Abend ;)

Hallo hannsgmaulwurf ,

also nimm es mir jetzt nicht übel aber könntest Du einmal bitte genauer beschreiben was das
für eine Ausgangssituation ist!?

Sind das zwei Standorte (Betriebe oder Arbeitsstellen) oder ist das ein Heimarbeitsplatz und eine
Betriebsstelle!

Firma - Firma
Router(Cisco)-----VPN---(IPSec)-----Router(Netgear)

SOHO Arbeitsplatz - Firma
SOHO PC mit VPN Klient-----VPN---(IPSec)-----Firma

Gruß
Dobby

Nabend dobby,

ich nehme dir deine frage keineswegs übel sondern freue mich über jedes feedback ;)

Es handelt sich um eine kleine Firma mit einer Außenstelle, von der aus in erster Linie ein permanenter Zugriff mehrerer Clients auf den Firmenserver gewährleistet sein soll.

Besten Dank und liebe Grüße.

Hallo,

Es handelt sich um eine kleine Firma mit einer Außenstelle, von der aus in erster Linie ein permanenter Zugriff mehrerer Clients auf den Firmenserver gewährleistet sein soll.

Ok dann würde ich versuchen eine permanente VPN Verbindung herzustellen unter Gebrauch bzw.
Einsatz von IPSec.

Da ich selber Netgear verwende würde ich Dir nur zu einer Firewall von denen raten
zumindest wenn es um den Unternehmenseinsatz geht und das die SRX5308.
Ich selber nutze die FVS336Gv2 zu Hause und bin damit bis jetzt nicht enttäuscht worden und zufrieden,
aber wohl gemerkt zu Hause und da würde ich wenn Ihr eh schon ein Modell von Cisco im Einsatz habt
würde ich Euch raten einfach dasselbe Modell noch einmal zu kaufen und damit dann die VPN Verbindung
herzustellen wenn dort der Einsatz von IPSec unterstützt wird.

VPN ist in der Regel immer etwas mit Aufwand verbunden und ebenso mit Kosten doch das macht sich
dann durch eine lange Laufzeit und einen performanten Durchsatz wieder bezahlt.

Und sollten dazu noch Fragen bezüglich der Konfiguration entstehen ist das alles auch nicht so schlimm
da bekommst Du hier im Forum oder auf den sehr üppig und gut gestalteten Cisco Webseiten auch recht gute Hilfe und Erklärungen mit Beispielen, doch dann würde ich Dir dringend raten die richtige Bezeichnung und das richtige Modell dabei zu haben und diese auch zu nennen.

Viel Erfolg und Gruß
Dobby

Moin

Was genau meinst du bitte mit "die Lösung mit den zwei Gateways"?

Ich meinte damit, wie es dobby schrieb, dass du zwei VPN-fähige Router (auch VPN-Gateway, kurz Gateway genannt) nimmst, die vom selben Hersteller (und am besten selben Typ) sind.

Guten Morgen zusammen.

Zitat von @108012:
Ich selber nutze die FVS336Gv2 zu Hause und bin damit bis jetzt nicht enttäuscht worden und zufrieden,
aber wohl gemerkt zu Hause und da würde ich wenn Ihr eh schon ein Modell von Cisco im Einsatz habt
würde ich Euch raten einfach dasselbe Modell noch einmal zu kaufen und damit dann die VPN Verbindung
herzustellen wenn dort der Einsatz von IPSec unterstützt wird.

Bei der Außenstelle handelt es sich beim Router genau um den von dir im Heimeinsatz genutzten Netgear FVS336Gv2. Am anderen Standort steht ein Linksys RV082 V03 von Cisco.

Nach kurzer Rücksprache soll die Anschaffung eines neuen, identischen Routers für die Außenstelle nach Möglichkeit vermieden werden...

Ich werde mich mal belesen, ob man die beiden Router irgendwie zusammen bekommt oder wie ich das mit OpenVPN realisieren kann.

Danke erstmal bis hierher.

Im sauerländer Volksmund nennt man das Friemellösung.
Ich pflege zu sagen "Wer mit Panuts bezahlt, wird von Affen bedient".

OpenVPN ist natürlich dann, wie beschrieben, die bessere Lösung, wenn's nichts kosten soll...
An deiner Stelle würde ich meinen Chef überzeugen, Geld in die Hand zu nehmen und zwei Gateways zu kaufen. Z.B. 2x LANCOM 1781A + VPN-Lizenz ~ 1000€
Ne Astaro/Cisco ist deutlich teurer...

Moin Hans,

die beiden Router beherrschen das IPSEC VPN Verfahren.
Somit sollte es doch problemlos möglich, zwischen diesen beiden VPN-Routern einen Tunnel aufzubauen.

Auf www.vpncasestudy.com stehen sehr viele Anleitungen zu Netgear VPN-Routern.

Wer allerdings noch nie einen IPSEC-VPN-Tunnel eingerichtet hat, wird es anfangs - vor allem bei der Nutzung verschiedener Hersteller - nicht leicht haben.

BTW: Beide Router sind aus der selben Geräteklasse (SMB), haben sogar fast identische Preise. Beim Cisco (Linksys) Router ist jedoch der NAT- und auch VPN-Durchsatz wesentlich höher, was aber nur bei dicken WAN-Anbindungen (weit jenseits von ADSL) zum Tragen kommen dürfte. Dafür hat der Netgear GBit-Anschlüsse und man kann sich per SSL-VPN einwählen.

Zitat von @manuel1985:

Im sauerländer Volksmund nennt man das Friemellösung.
Ich pflege zu sagen "Wer mit Panuts bezahlt, wird von Affen bedient".

OpenVPN ist natürlich dann, wie beschrieben, die bessere Lösung, wenn's nichts kosten soll...
An deiner Stelle würde ich meinen Chef überzeugen, Geld in die Hand zu nehmen und zwei Gateways zu kaufen. Z.B. 2x
LANCOM 1781A + VPN-Lizenz ~ 1000€
Ne Astaro/Cisco ist deutlich teurer...

Was ist denn das für ein unsinniger Beitrag?

Warum sollte sich der TO 2 andere VPN-Router (noch dazu sehr teure) kaufen, wo doch zwei vorhanden sind, die seine Wünsche erfüllen können?

Zitat von @goscho:
Wer allerdings noch nie einen IPSEC-VPN-Tunnel eingerichtet hat, wird es anfangs - vor allem bei der Nutzung verschiedener
Hersteller - nicht leicht haben.

Hallo goscho!

Vielen Dank für deinen Beitrag. Dass beide IPSEC können habe ich auch schon rausgefunden, aber wenn ich mir nur mal die Konfigurationsmöglichkeiten beim VPN des Cisco ansehe muss ich ehrlich sagen, dass ich mit vielen Dingen überhaupt nichts anfangen kann

Ich werde wohl erstmal die OpenVPN Lösung wählen, um eine schnelle Lösung zu haben und dann kann ich mich ja noch mal ausgiebig mit der Gateway-to-Gateway-Lösung befassen.

Die Seite mit den Netgearanleitungen hatte ich zwar auch schon mal ergooglet, aber noch nicht weiter durchgeforstet. Ist auf jeden Fall vorgemerkt

Dann solltest du vielleicht etwas lesen vorab um deinen IPsec Horizont etwas zu erweitern:
IPSEC Protokoll - Einsatz, Aufbau, benötigte Ports und Begriffserläuterungen
Damit ist eine VPN Tunnelkonfig auf Cisco_Routern oder anderen preiswerten Routern wie Mikrotik, pfSense, FritzBox oder was auch immer ein Kinderspiel.
IPsec Konfigs auch zum simplen Abtippen als Laie findest du hier:
IPsec VPNs einrichten mit Cisco, Mikrotik, pfSense Firewall, FritzBox, Smartphone sowie Shrew Client Software
Oder wenn es doch lieber OpenVPN sein soll was das problemlos auch kann: (Standortvernetzung)
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Such dir das schönste raus...! Und nein...NetGear gehört bei VPNs sicher nicht dazu.

Hi aqui

Zitat von @aqui:
Such dir das schönste raus...! Und nein...NetGear gehört bei VPNs sicher nicht dazu.

Warum?

PS: Ich habe einige Dutzend VPN-Tunnel von und zu Netgear Routern (vorwiegend FVS336G) eingerichtet, die alle problemlos funktionieren.

Zitat von @aqui:
Such dir das schönste raus...!

Hallo aqui und vielen Dank für die Links!!!! Sehr interessant. Aber es handelt sich ja immer im die Konfiguration der Router oder sehe ich das falsch?

Vorerst werde ich mal die Router außen vor lassen (abgesehen von der Firewall Konfiguration) und mich nur damit beschäftigen, OpenVPN auf Windwos Servern und -Clients einzurichten.

Aber auf lange Sicht werde ich mich da mal einlesen, um in Zukunft schon vor dem Routerkauf etc. Bescheid zu wissen und entsprechend steuern zu können.

Hallo nochmal,

@hannsgmaulwurf
Zwei identische Router von ein und dem selben Hersteller lassen
sich natürlich wesentlich leichter einrichten und konfigurieren.

VPN ist nicht das einfachste von der Welt, aber auch nichts was unmöglich ist und schon gar nicht wenn man
in einem Forum wie hier angemeldet ist und dazu gibt es ja auch noch den Support von Netgear und die haben
ja auch ein Forum, also daran soll es ja nun wirklich nicht liegen und wenn die Tunnel erst einmal stehen ist das auch nicht mehr als ein Wochenende auf das man sich an dem Wochenende vorher gut vorbereitet hat.

Ich denke bei den meisten Leuten die einen IPSec VPN Tunnel aufbauen sollen, wollen oder müssen scheitert
es immer wieder an zwei Sachen!
1. Kein Geld,aber das ganze soll die Firma voranbringen um welches zu verdienen.!!
2. Keine Zeit und vor allem anderen keine Lust sich einmal die Bedienungsanleitung anzuschauen!!!!!!!!!!!

Also ich denke mit OpenVPN ist das so eine Sache, ich schaffe mir doch nicht eine echte Firewall an
und lasse dann immer schön vorne ein paar Ports offen an eben dieser bloß weil ich zu faul bin, mir
einmal eine englische Bedienungsanleitung durchzulesen, sondern lieber über Dr. Google eine deutschsprachige Anleitung bevorzugen die Ihnen schnell erklärt wie man mit OpenVPN was aufsetzt, also
wenn schon OpenVPN dann auch auf einer pfSense, mOnOwall oder IPFire Lösung die auch dichthält, so
wie der @aqui das in seinen Anleitung auch benutzt und das wird wohl auch seine Berechtigung und seinen Grund haben, aber heutzutage sehe ich wirklich nur in einigen Ausnahmefällen einen Grund warum man vorne noch Ports offen stehen haben sollte an der Firewall oder dem Router.

Und mal im Ernst zwei Cisco RV220W kosten nicht die Welt und zwei Netgear FVS336Gv2 auch nicht man muss sich eben nur entscheiden können und auch den Willen haben. Das Jahr ist noch Jung und der Etat auch.
Sprich doch einfach einmal mit Deinem Chef.

Gruß
Dobby

..."Aber es handelt sich ja immer im die Konfiguration der Router oder sehe ich das falsch?..."
JA, das siehst du komplett Falsch !!!
Jedenfalls was das Beispiel OpenVPN anbetrifft !! Wüsstest du auch wenn du dich mit OpenVPN wirklich näher beschäftigt hättest oder mal die OpenVPN Doku auf der Webseite oder ein Buch dazu gelesen hättest !

OpenVPN hat die gleiche Konfigurationsoberfläche bzw. Kommandos. Dabei ist es völlig egal ob das auf einem Router Firewall, Linux- oder Winblows Server oder egal welcher Hardware auch immer rennt.
Die Konfig Schritte und ToDos sind immer vollkommen identisch !!
Ein großer Vorteil von OpenVPN....

Guten Morgen zusammen!

Ich habe das jetzt mit OpenVPN realisiert und dafür u.a. diese Anleitungen genutzt (Danke nochmal für die Links!!!):
OpenVPN - Teil 1 - Installation, Konfiguration und erstellung der Zertifikate
OpenVPN - Teil 2 - OpenVPN Konfiguration
OpenVPN.net HOWTO

OpenVPN läuft jetzt auf Server und Clients als Dienst und wenn sich ein User am Client anmeldet, sind die Netzlaufwerke des entfernten Servers sofort da.
Positiver Nebeneffekt: Da auch ein, zwei Notebooks unter den Clients sind, können diese auch mal auf eine Dienstreise mitgenommen werden und haben trotzdem Zugriff auf die Daten.

Eine abschließende Einschätzung eurerseits hätte ich da aber gerne noch: Wie sicher bzw. unsicher ist das ganze denn nun mit den folgenden Werten:
- Der Server lauscht auf einem von mir gewählten Port, sagen wir mal 9999 UDP (also nicht der Std. Port) und dieser ist auch als einziger auf der Firewall offen und zwar nur für die IP des anderen Standortes (müsste für Dienstreisen etc. natürlich angepasst bzw. temporär auf ANY IP gesetzt werden)
- Diffie hellman Parameter: dh dh2048.pem
- Verschlüsselung: cipher AES-128-CBC

Also nochmals besten Dank für eure Zahlreichen Tipps, Hinweise, Denkanstöße und Meinungen!!!!! Und schon mal ein schönes Wochenende euch allen!!!

Ist alles gut und OK. Nur für den Port solltest du keinen offizellen Port in der registrieten IANA Range vergeben.
Die IANA empfiehlt immer für eigene Anwendungen Ports aus dem sog. Ephemeral Port Range von 49152 bis 65535 zu vergeben !
Positiver Nebeneffekt:
Diese Ports sind sehr selten in Hacker Tools und Scannern von Script Kiddies usw. Damit reduziert sich dann das Ausmass von Angriffen auf ein Minimum.

Zitat von @aqui:

Danke für den Hinweis aqui, dann werde ich den Port noch ändern.

Also nochmals vielen Dank euch allen und ein schönes WE!!!

Hallo zusammen,

wie damals schon vermutet soll nun auch der Zugriff in die andere Richtung realisiert werden. Aber nochmal eine kurze Zusammenfassung:

- 2 Firmenstandorte A & B mit je einem Server 2008 R2 und div. Win7 Clients
- Server A ist OpenVPN Server
- Server B und Clients B können sich mit jeweils eigenen Zertifikaten per OpenVPN mit Server A verbinden

Nun sollen auf Seite B noch einige Clients hinzukommen, sodass auf allen neuen Clients wieder erst OpenVPN eingerichtet werden müsste.
Zusätzlich sollen nun auch die Clients von Standort A auf Server B zugreifen.

Also ist die bisherige Lösung, jeden Client einzeln mit Server A zu verbinden, nicht mehr praktikabel. Daher dachte ich mir, ich stelle nur noch die Verbindung zwischen den Servern her und konfiguriere die Server so, dass sie ihre Clients zum jeweils entfernte Server routen.

Ist das überhaupt möglich oder bin ich auf dem Holzweg? Hier noch die IP Konfigs der Server, die sich auch beide sehen, pingen usw. können:

Server A

LAN-Adapter (physikalisches Netz)
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.1.1
   DNS-Server  . . . . . . . . . . . : 192.168.1.10

LAN-Adapter (OpenVPN)
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.3.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . :
   DHCP-Server . . . . . . . . . . . : 192.168.3.2

Server B

LAN-Adapter (physikalisches Netz)
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.2.1
   DNS-Server  . . . . . . . . . . . : 192.168.2.10

LAN-Adapter (OpenVPN)
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.3.22(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . :
   DHCP-Server . . . . . . . . . . . : 192.168.3.21

Vielen Dank für jeden Hinweis und einen schönen Abend!

Also ist die bisherige Lösung, jeden Client einzeln mit Server A zu verbinden, nicht mehr praktikabel.

Ist eine sehr sinnvolle Entscheidung !

Ist das überhaupt möglich oder bin ich auf dem Holzweg?

Natürlich ist das möglich und eine Paradedisziplin für Open VPN. Was du dann machst ist einen sog. LAN zu LAN oder Site to Site VPN Kopplung.
Dieses Tutorial erklärt dir alle Schritte dazu:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
http://andreas-lemke.net/content/uni/openvpn.pdf
usw.

Besten Dank aqui, nur kann ich damit irgendwie nicht viel anfangen... Die Links passen doch gar nicht richtig zu meinem Thema?!? Bzw. zum Thema natürlich, aber meine Frage war eigentlich, ob ich die bestehende Konfig verwenden kann. Also die bestehende, funktionierende Verbindung zwischen Server A (als OpenVPN Server) und Server B (als Client) für die Clients zu verwenden. Also z.B. wenn ein Client aus B auf Server A zugreifen will, soll er Server B als Gateway für das 3er Netz nutzen. Ich hab gestern auch schonmal Routing und RAS installiert und mit LAN-Routing aktiviert, ohne noch irgendwelche weiteren Einstellungen dabei vorzunehmen. Ich habe lediglich beim Client das GW gändert (vom Router auf den Server):

Server A
  IP lokal: 192.168.1.10
  IP VPN: 192.168.3.  1
Client A
  IP lokal: 192.168.1.100
  GW:       192.168.3.   1
Server B
  IP lokal: 192.168.2.10
  IP VPN: 192.168.3.22

Client A kann auch die 3.1 erreichen (ping), aber nicht die 3.22. Sobald Routing und RAS deaktiviert wird, kann er auch die 3.1 nicht mehr erreichen, also scheint das ja schon zu greifen, nur nicht so, wie ich mir das gedacht habe...

Um auf meine Frage zurückzukommen: Wenn ich die bestehende Konfig nicht nutzen kann und OpenVPN erst umkonfigurieren muss, würde ich gleich lieber alles auf Windows setzen und Routing und RAS auf beiden Servern für Site-to-Site konfigurieren ("Sichere Verbindung zwischen zwei Standorten herstellen"). Oder wäre das Quatsch?

ob ich die bestehende Konfig verwenden kann. Also die bestehende, funktionierende Verbindung zwischen Server A (als OpenVPN Server) und Server B (als Client) für die Clients zu verwenden

Ja, klar geht das. Du koppelst ja über deinen OVPN Tunnel die beiden gesamten lokalen Netze. Clients in diesen Netzen "denken" also sie sind direkt miteinander verbunden.
Das ist der tiefere Sinn von einer LAN zu LAN Kopplung. Und ja...das geht mit der klassischen OVPN Konfig wie auch bei dir.
Die Clients brauchen dann natürlich KEINEN dedizierten VPN Client mehr, denn zentral tunneln die Server ja alle Clients.

Oder wäre das Quatsch?

Da du ja ein funktionierendes OVPN hast wäre das natürlich Quatsch und würde dein problem auch nicht lösen. Bei dir fehlen lediglich ein simpler Routing Eintrag. Wenn die .22 eine lokales Endgerät ist hat das vermutlich ein Default Gateway was auf den Router zeigt und dort fehlt das Routing zum OVPN internen IP Netz. Deshalb rennt dein Ping ins Nirwana weil die Route dort fehlt.
Nimm Traceroute (tracert) und / oder Pathping und check ganz einfach aus wo die Route hängen bleibt. Dort ist auch der Routing Fehler !

Hallo aqui,

vorab: Ich hatte mich oben verschrieben: Client A hat natürlich die lokale IP des (Routing-und-RAS-)Servers A als Gateway und nicht dessen VPN-IP:

Server A 
  IP lokal: 192.168.1.10 
  IP VPN: 192.168.3.  1 
Client A 
  IP lokal: 192.168.1.100 
  GW:       192.168.1. 10
Server B 
  IP lokal: 192.168.2.10 
  IP VPN: 192.168.3.22

Ein tracert von Client A zur 192.168.3.1 (VPN Interface Server A) bei aktivem Routing und RAS Dienst auf Server A ergibt folgendes:

Routenverfolgung zu SERVERA [192.168.3.1] über maximal 30 Abschnitte:

  1     *        *        *     Zeitüberschreitung der Anforderung.
  2    <1 ms    <1 ms    <1 ms  SERVERA [192.168.3.1]

Ablaufverfolgung beendet.

Ein tracert von Client A zur 192.168.3.22 (VPN Interface Server B) bei aktivem Routing und RAS Dienst auf Server A ergibt folgendes:

Routenverfolgung zu 192.168.3.22 über maximal 30 Abschnitte

  <1 ms     *       <1 ms  servera.domaina.local [192.168.1.10]
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *        *     Zeitüberschreitung der Anforderung.
   *        *        *     Zeitüberschreitung der Anforderung.
   *     ^C

Und hier noch ein tracert von Server A zu Server B bei bestehender VPN Verbindung:

Routenverfolgung zu SERVERA [192.168.3.22] über maximal 30 Abschnitte:

  1   130 ms    66 ms     7 ms  SERVERA [192.168.3.22]

Ablaufverfolgung beendet.

Also scheint der Server A zwar zu wissen, wie er selbst per VPN Tunnel zu Server B (3.22) kommt, kann den Client (dessen GW er ja ist) aber nicht dorthin weiterleiten?!? Aber komischerweise schreibt er beim Ziel 3.22, was ja das OpenVPN-Interface von Server B ist, "SERVERA"....

Nochmal zur Verdeutlichung: Server A hat eine OpenVPN Konfig als Server, Server B als Client. Muss vielleicht was an der/den Konfig(s) angepasst werden? Kann sie hier auch gerne posten wenn verlangt.

Hier noch die IPv4 Routing-Tabelle von Server A mit laufendem OpenVPN-Dienst...

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10    261
          0.0.0.0          0.0.0.0   Auf Verbindung       192.168.3.1    286
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.10    261
     192.168.1.10  255.255.255.255   Auf Verbindung      192.168.1.10    261
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
      192.168.3.0    255.255.255.0      192.168.3.2      192.168.3.1     30
      192.168.3.0  255.255.255.252   Auf Verbindung       192.168.3.1    286
      192.168.3.1  255.255.255.255   Auf Verbindung       192.168.3.1    286
      192.168.3.3  255.255.255.255   Auf Verbindung       192.168.3.1    286
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung       192.168.3.1    286
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.10    261
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung       192.168.3.1    286
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     256
          0.0.0.0          0.0.0.0      192.168.1.1  Standard
          0.0.0.0          0.0.0.0      192.168.3.1  Standard
===========================================================================

...und ohne:

IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10    261
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.10    261
     192.168.1.10  255.255.255.255   Auf Verbindung      192.168.1.10    261
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.10    261
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     256
          0.0.0.0          0.0.0.0      192.168.1.1  Standard
          0.0.0.0          0.0.0.0      192.168.3.1  Standard
===========================================================================

Vielen vielen Dank!!!!!

Das sieht nach den Traceroutes so aus als ob schon am ersten Hop was schiefläuft !!
Sind die OVPN Server hinter einem NAT Internet Router ??
Wenn das der Fall ost musst du auf den jeweiligen Routern eine statische Route eintragen ala:
Zielnetz: 192.168.3.0, Maske: 255.255.255.0, Gateway: 192.168.1.10
Respektive auf der anderen Seite am Router im 2.0er Netz:
Zielnetz: 192.168.3.0, Maske: 255.255.255.0, Gateway: 192.168.2.10
Ist das passiert ?
Auf dem ersten Hop fehlt irgendwie eine Route da es da ja schon nicht weitergeht ?!
Denk auch dran das wenn du eine LAN zu LAN Kopplung machst du auf beiden Seiten mit dem push route... Kommando arbeiten kannst oder eben mit dem route... oder iroute... Kommando in der Konfig Datei !
Du musst auf den OVPN Gateways IMMER die Route in das jeweils andere Netz auf der anderen Seite mit "route print" sehen via dem .3.0er Netz !
Fehlt das, ist ja klar das dann Pakete für das jeweils andere NICHT in den Tunnel geroutet werden und dein LAN zu LAN VPN schlägt dann fehl !
Wie du siehst fehlt das wie befürchtet oben bei dir !
Stelle das also sicher mit den Routen in den jeweiligen Konfig Dateien, dann klappt das auch auf Anhieb.
https://community.openvpn.net/openvpn/wiki/RoutedLans
http://serverfault.com/questions/593314/solved-openvpn-routing-for-lan- ...

Hallo aqui und vielen Dank für deine Hilfe!!

Ich bin erst wieder nächste Woche vor Ort um das zu prüfen und zu testen und gebe dann natürlich feedback.

Sind die OVPN Server hinter einem NAT Internet Router ??

Ja, beide Server/Netze hängen hinter Routern mit festen IP-Adressen.

Wenn das der Fall ost musst du auf den jeweiligen Routern eine statische Route eintragen ala: Zielnetz: 192.168.3.0, Maske: 255.255.255.0, Gateway: 192.168.1.10
Respektive auf der anderen Seite am Router im 2.0er Netz: Zielnetz: 192.168.3.0, Maske: 255.255.255.0, Gateway: 192.168.2.10
Ist das passiert ?

Nein das ist (noch) nicht passiert.
Also das ist ja das, was ich irgendwie nicht verstehe: Zwischen ServerA mit der 3.1 und ServerB mit der 3.22 besteht ja die OVPN-Verbindung. Und nun sollen die Clients auf den jeweils entfernten Server zugreifen und nichts weiter. Daher dachte ich, dass das mit der bestehenden OVPN-Verbindung reicht, wenn man auf den Servern noch die Routing und RAS Rolle einrichtet...

Denk auch dran das wenn du eine LAN zu LAN Kopplung machst du auf beiden Seiten mit dem push route... Kommando arbeiten kannst
oder eben mit dem route... oder iroute... Kommando in der Konfig Datei !

Eine Zeile mit "push route" gibt es definitiv in der Konfig-Datei des OVPN-Servers, das weiß ich. Aber warum müssen denn die OVPN-Konfigs angepasst werden? Die Verbindung klappt doch zwischen den Routern. Das ist ja das, was ich nicht verstehe

Du musst auf den OVPN Gateways IMMER die Route in das jeweils andere Netz auf der anderen Seite mit "route print"
sehen via dem .3.0er Netz !
Fehlt das, ist ja klar das dann Pakete für das jeweils andere NICHT in den Tunnel geroutet werden und dein LAN zu LAN VPN
schlägt dann fehl !
Wie du siehst fehlt das wie befürchtet oben bei dir !

Aber die Route ist doch da:

Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik 
192.168.3.0    255.255.255.0      192.168.3.2      192.168.3.1     30 

Allerdings weiß ich jetzt nicht, wo die 3.2 herkommt - der Server hat ja die 3.1....

Und nun sollen die Clients auf den jeweils entfernten Server zugreifen und nichts weiter. Daher dachte ich,

Nicht denken sondern nachdenken...!
Beispiel mit OVPN Server hinter NAT Router:

Lokales Netz: 192.168.3.0 /24
Router im lokalen Netz 192.168.3.254
VPN Server im lokalen Netz: 192.168.3.200
Client im lokalen Netz: 192.168.3.10 mit default Gateway auf Router 192.168.3.254
Remoter Client aus dem anderen Netz der über den OVPN Server kommt: 192.168.2.10

Was passiert jetzt....:

Remoter Client mit der Absender IP 192.168.2.10 kommt über den VPN Tunnel via Server rein und hat als Ziel IP die 192.168.3.10.
Dort landet das Paket auch und der lokale Client mit der 192.168.3.10 will nun dem remoten Client 192.168.2.10 antworten.
Dazu steht in seinem zu sendenden Paket dann als Ziel die 192.168.2.10 und als Absender die 192.168.3.10
Client "sieht" das die 192.168.2.10 nicht sein lokales Netz ist und sieht in seine Routing Tabelle...
Dort steht nur ein Default Gateway, sprich also alles was er nicht kennt ab damit zur 192.168.3.254 die alles kennt.
Paket kommt jetzt am Router an und auch der merkt kein lokales IP Netz also sehe ich mal in der Routing Tabelle bei mir nach...
Dort steht nur die Default Route zum Internet Provider, also ab mit dem 192.168.2.10 Paket dahin
Paket kommt am Provider Router an, der sieht die 192.168.2.10 und erkennt das das eine private RFC 1918 IP ist, die im Internet nicht geroutet wird. Solche Pakete kann er nicht routen und die landen bei ihm sofort im IP Pakete Mülleimer auf Nimmerwiedersehen....
VPN ist tot....

Du erkennst vermutlich das Dilemma was einem aber schnell klar wird versetzt man sich auch nur einfach mal ein ganz kleines bischen in die simple IP Kommunikation die abläuft !!
Du siehst sofort: der Knackpunkt ist der Internet Router mit der fehlenden statischen Route !!!
Hätte der jetzt eine statische Route ala:
Zielnetz: 192.168.2.0, Maske: 255.255.255.0, Gateway: 192.168.3.200
dann sähe alles ab dem Router so für unser .2.10er Paket aus:

Paket kommt jetzt am Router an und auch der merkt kein lokales Netz also sehe ich mal in der Routing Tabelle bei mir nach...
Dort steht die Default Route zum Internet Provider, und auch eine weitere Route das alles mit dem Präfix 192.168.2.0 /24 zur 192.168.3.200 gesendet werden soll, also ab mit dem 192.168.2.10 Paket dahin (VPN Server).
Paket kommt am VPN Server an, der sieht die 192.168.2.10 Ziel IP, sieht in seiner Routing Tabelle nach und erkennt das das Zielnetz auf der anderen Seite des Tunnels liegt also ab in den VPN Tunnel damit.
OVPN Server dort empfängt es und sendet es an den Client .2.10 dort...und die Geschichte fängt oben wieder an mit dem 3er Netz....

Hoffe du verstehst es nun irgendwie und erkennst wie wichtig diese Routen sind wenn du ein sog. "one armed" Design hast mit OVPN Servern und die nicht gleich auf dem Internet Router selber implementiert hast was netzwerktechnisch die allerbeste Lösung wäre wie z.B. hier auch beschrieben ist !?!

Daher dachte ich, dass das mit der bestehenden OVPN-Verbindung reicht,

Du denkst schon wieder zuviel statt einmal nachzudenken... !!!

Wie soll das denn "reichen" wenn du die Server hinter dem NAT Router betreibst ?? Also bitte logisch überlegen an die IP Pakete denken und NICHT denken.

Eine Zeile mit "push route" gibt es definitiv in der Konfig-Datei des OVPN-Servers, das weiß ich

Das ist gut...Kontrolle ist besser ! denn das Kommando MUSS auf beiden Seiten in der Konfig stehen damit die gegenseitigen lokalen Netze in der Routing Tabelle stehen !!
Alternativ ohne push route geht es mit route oder iroute.

Aber warum müssen denn die OVPN-Konfigs angepasst werden? Die Verbindung klappt doch zwischen den Routern. Das ist ja das, was ich nicht verstehe

Du musst diese natürlich NICHT anpassen wenn beide remoten Netzwerke jeweils sauber in den Routing Tabellen der OVPN Server stehen !
Ist das der Fall hast du Recht und musst natürlich nix mehr anpassen, klar.
Wichtig und essentiell sind dann nur die statischen Routen in den beiden Internet NAT Routern auf beiden Seiten !!
Die darfst du nicht vergessen ! Siehe oben.

Aber die Route ist doch da:

Super, dann ist wirklich alles OK wenn es beidseitig ist !!
Auf dem Server im .2.0er Netz muss die .3.0er Route sein. Und vice versa...
Auf dem Server im .3.0er Netz muss die .2.0er Route sein.
Dann ist alles gut und nur einzig die Routen in den Internet Routern fehlen noch.

Allerdings weiß ich jetzt nicht, wo die 3.2 herkommt - der Server hat ja die 3.1

Die Route ist natürlich Blödsinn und da ist in der Konfig dort was schiefgelaufen !

Auf den Winblows Gurken musst du zwangsweise auch ein Auge auf die Firewall Profile und Einstellungen auf den virtuellen TAP Adaptern haben.
Windows nimmt (fast) immer ein öffentliches Profil was das VPN dann zum Erliegen bringt da alles geblockt wird. Das musst du umstellen auf Privat. Ist oben ja schon alles dazu gesagt !!

Hallo aqui und vielen Dank für deine geduldige ausführliche Erläuterung. Wie gesagt bin ich erst wieder nächste Woche vor Ort und werde das dann prüfen und testen.
Bis dahin nochmals besten Dank und einen schönen Abend ;)

Na dann sind wir mal gespannt auf das Ergebnis....

Hallo zusammen, hallo aqui.

Nach zwei Tagen Routing und Probiering bin ich schon ein Stück weiter, aber noch nicht am Ziel...

Auf den Routern habe ich die statischen Routen für die Clients eingetragen und diese werden nun auch zum entspr. Routing & RAS Server weitergeleitet.
Auf den Servern habe ich ebenfalls Routen hinzugefügt und bekomme auch viele Verbindungen, aber nicht alles...

Bevor ich mich vertippe, poste ich unten mal alle ipconfigs und routing-Tabellen der beiden Server. Die Clients und NAT-Router lasse ich bewusst außen vor, denn wie gesagt klappt das ja, dass die Clients von den NAT-Routern an den jeweiligen Server ihres Netzes weitergeleitet werden.

Also ich kann jetzt mit dem 2er-Server alle 1er-Geräte pingen, also z.B. den 1er-Server mit der 1.10 oder Clients und Drucker im 1er Netz.
Auch kann ich mit dem 2er-Server die VPN-IP des 1er-Servers (3.1) pingen.

In die andere Richtung klappt leider nur der ping auf die VPN-IP: Also der 1er-Server kann die VPN-IP des 2er-Servers (3.22) pingen, nicht aber die "normale" IP (2.10). Da kommt dann "Zeitüberschreitung", was ja darauf hindeutet, dass das Paket zwar ankommt, aber nicht zurückfindet, richtig?
Das wiederum verstehe ich aber nicht, da ein Ping in die andere Richtung ja klappt, es also nicht am Routing liegen kann.
Die Windows-Firewalls auf den Servern sind ebenfalls deaktiviert.
Ich habe auf dem 2er-Server auch schon Wireshark laufen gelassen - da wird nichts gepatured, wenn ich vom 1er Server die 2.10 anpinge...

Ich bin ziemlich ratlos, zumal ich mittlerweile alles durchprobiert habe bzw. zu haben glaube und mir ehrlich gesagt langsam die Übersicht verloren geht... Zumal ich auch kein Netzwerk Experte bin und bei solchen Themen immer eher durch Probieren als durch Nachdenken bzw. "Abläufe-verstehen" zum Ziel komme.

Ob es doch noch an den OpenVPN-Konfigs liegt? Die unterscheiden sich ja auch, denn der 1er-Server, von dem die Verbindung ins 2er-Netz nicht klappt, ist auch OVPN-Server und hat eine andere Konfig als der 2er-Server, der ja nur OVPN-Client ist.

Was mich auch stutzig macht, sind die DHCP-Adressen der VPN-Adapter (siehe unten). Denn diese müssen als Gateway für die Routen angegeben werden, dass überhaupt was funktioniert. Also nicht die IP des VPN Adapters, sonder eine IP "drunter"...

Das ist irgendwie schwer in Worte zu fassen bzw. zu umschreiben und daher poste ich jetzt einfach mal alle meiner Meinung nach relevanten (um uninteressante Werte gekürzte) Konfigs in der Hoffnung, dass da draußen jemand a) Ahnung und b) Lust hat, das ganze mal zu analysieren. Vielleicht sieht man von außen ja auch besser

ipconfig Server1

Ethernet-Adapter LAN-Verbindung 5:
   Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.3.1(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . : 0.0.0.0
   DHCP-Server . . . . . . . . . . . : 192.168.3.2
   
Ethernet-Adapter LAN-Verbindung 4:
   Beschreibung. . . . . . . . . . . : LAN-Verbindung - Virtuelles Netzwerk
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.1.1
   DNS-Server  . . . . . . . . . . . : 192.168.1.10

routing Tabelle Server1 (Ich habe nur die beiden Ständigen Routen 2.0 und 3.0 manuell eingefügt)

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0   Auf Verbindung       192.168.3.1    286
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.10    261
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.1.0    255.255.255.0   Auf Verbindung      192.168.1.10    261
     192.168.1.10  255.255.255.255   Auf Verbindung      192.168.1.10    261
    192.168.1.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
      192.168.2.0    255.255.255.0      192.168.3.2      192.168.3.1     31
      192.168.3.0    255.255.255.0      192.168.3.2      192.168.3.1     31
      192.168.3.1  255.255.255.255   Auf Verbindung       192.168.3.1    286
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung       192.168.3.1    286
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.1.10    261
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung       192.168.3.1    286
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.1.10    261
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      192.168.1.1     256
          0.0.0.0          0.0.0.0      192.168.3.1  Standard
          0.0.0.0          0.0.0.0      192.168.1.1  Standard
      192.168.3.0    255.255.255.0      192.168.3.2       1
      192.168.2.0    255.255.255.0      192.168.3.2       1
===========================================================================

ipconfig Server2

Ethernet-Adapter LAN-Verbindung 5:
   Beschreibung. . . . . . . . . . . : Intel(R) I350 Gigabit Network Connection #4
   DHCP aktiviert. . . . . . . . . . : Nein
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.2.10(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : 192.168.2.1
   DNS-Server  . . . . . . . . . . . : 192.168.2.10

Ethernet-Adapter LAN-Verbindung 8:
   Beschreibung. . . . . . . . . . . : TAP-Windows Adapter V9
   DHCP aktiviert. . . . . . . . . . : Ja
   Autokonfiguration aktiviert . . . : Ja
   IPv4-Adresse  . . . . . . . . . . : 192.168.3.22(Bevorzugt)
   Subnetzmaske  . . . . . . . . . . : 255.255.255.252
   Standardgateway . . . . . . . . . :
   DHCP-Server . . . . . . . . . . . : 192.168.3.21

routiung Tabelle Server2 (Ich habe nur die beiden Ständigen Routen 1.0 und 3.0 manuell eingefügt)

Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.2.1     192.168.2.10    266
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    306
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    306
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
      192.168.1.0    255.255.255.0     192.168.3.21     192.168.3.22     31
      192.168.2.0    255.255.255.0   Auf Verbindung      192.168.2.10    266
     192.168.2.10  255.255.255.255   Auf Verbindung      192.168.2.10    266
    192.168.2.255  255.255.255.255   Auf Verbindung      192.168.2.10    266
      192.168.3.0    255.255.255.0     192.168.3.21     192.168.3.22     31
      192.168.3.1  255.255.255.255     192.168.3.21     192.168.3.22     30
     192.168.3.20  255.255.255.252   Auf Verbindung      192.168.3.22    286
     192.168.3.22  255.255.255.255   Auf Verbindung      192.168.3.22    286
     192.168.3.23  255.255.255.255   Auf Verbindung      192.168.3.22    286
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    306
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.2.10    266
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.3.22    286
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    306
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.2.10    266
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.3.22    286
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0      192.168.2.1  Standard
          0.0.0.0          0.0.0.0      192.168.2.1  Standard
      192.168.1.0    255.255.255.0     192.168.3.21       1
      192.168.3.0    255.255.255.0     192.168.3.21       1
===========================================================================

ping Server1 --> Server2 VPN-Schnittstelle

Ping wird ausgeführt für 192.168.3.22 mit 32 Bytes Daten:
Antwort von 192.168.3.22: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.3.22: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.3.22: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.3.22: Bytes=32 Zeit=6ms TTL=128

Ping-Statistik für 192.168.3.22:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 6ms, Mittelwert = 6ms

ping Server1 --> Server2 LAN-Schnittstelle

Ping wird ausgeführt für 192.168.2.10 mit 32 Bytes Daten:
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.
Zeitüberschreitung der Anforderung.

Ping-Statistik für 192.168.2.10:
    Pakete: Gesendet = 4, Empfangen = 0, Verloren = 4
    (100% Verlust),

ping Server2 --> Server1 VPN-Schnittstelle

Ping wird ausgeführt für 192.168.3.1 mit 32 Bytes Daten:
Antwort von 192.168.3.1: Bytes=32 Zeit=7ms TTL=128
Antwort von 192.168.3.1: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.3.1: Bytes=32 Zeit=6ms TTL=128
Antwort von 192.168.3.1: Bytes=32 Zeit=6ms TTL=128

Ping-Statistik für 192.168.3.1:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 7ms, Mittelwert = 6ms

ping Server2 --> Server1 LAN-Schnittstelle (Auch alle pings zu anderen Geräten im Netz 1.0 kommen an)

Ping wird ausgeführt für 192.168.1.10 mit 32 Bytes Daten:
Antwort von 192.168.1.10: Bytes=32 Zeit=7ms TTL=127
Antwort von 192.168.1.10: Bytes=32 Zeit=6ms TTL=127
Antwort von 192.168.1.10: Bytes=32 Zeit=6ms TTL=127
Antwort von 192.168.1.10: Bytes=32 Zeit=8ms TTL=127

Ping-Statistik für 192.168.1.10:
    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0
    (0% Verlust),
Ca. Zeitangaben in Millisek.:
    Minimum = 6ms, Maximum = 8ms, Mittelwert = 6ms

In die andere Richtung klappt leider nur der ping auf die VPN-IP: Also der 1er-Server kann die VPN-IP des 2er-Servers (3.22) pingen, nicht aber die "normale" IP (2.10). Da kommt dann "Zeitüberschreitung", was ja darauf hindeutet, dass das Paket zwar ankommt, aber nicht zurückfindet, richtig?

Das liegt mit an Sicherheit grenzender Wahrscheinlichkeit an einer fehlenden Router im davorliegenden Router wenn die VPN Server hinter einer NAT Router Firewall betrieben werden.
Bei den Edgeräten zeigt das Default Gateway dann auf den Router. Kommen dort also Pakete an aus dem VPN und will das Gerät antworten sendet es alle Pakete an den Router.
Dprt müssen statische Routen für alle remoten VPN Netze UND auch das interne VPN Netz konfiguriert sein die als Next Hop Gateway immer die lokale VPN Server IP haben.
Hast du das eingetragen ?
Sind diese Router Firewalls fehlt sehr oft eine Access regel in der FW. Das zeigen asymetrische Pings sehr oft. bzw. zu 90% ist dann dort eine einseitige Regel aktiv die Traffic bockt wie z.B. ICMP (Ping) oder bestimmte IP Netze !
Eine kurze Skizze deines aktuellen Designs wäre noch sehr hilfreich hier ! (Bitte keine externen Bilderlinks !)

Hallo aqui,

Dprt müssen statische Routen für alle remoten VPN Netze UND auch das interne VPN Netz konfiguriert sein die als Next Hop
Gateway immer die lokale VPN Server IP haben.
Hast du das eingetragen ?

Ja, auf beiden Internet-Routern sind die Routen für das jeweils andere Netz sowie das VPN-Netz eingetragen. Jeweils mit der lokalen IP des Routing&RAS-Servers, auch siehe Skizze.

Sind diese Router Firewalls fehlt sehr oft eine Access regel in der FW. Das zeigen asymetrische Pings sehr oft. bzw. zu 90% ist
dann dort eine einseitige Regel aktiv die Traffic bockt wie z.B. ICMP (Ping) oder bestimmte IP Netze !

Das schaue ich mir gleich nochmal in Ruhe an, danke für den Hinweis.

Eine kurze Skizze deines aktuellen Designs wäre noch sehr hilfreich hier ! (Bitte keine externen Bilderlinks !)

Hier eine Skizze, ich hoffe, sie ist aufschlussreicher aus die ewig langen geposteten ipconfigs und routing Tabellen

Die statische Route in beiden Servern auf sein eigenes internes .3.0er Netz ist natürlich Quatsch !
Die solltest du dringenst entfernen, denn das Netzwerk ist ja direkt am Server dran, folglich "kennt" er also immer diese Netz.
Die Route ist damit dann vollkommen überflüssig und eher kontraproduktiv, also weg damit.
Ansonsten ist das IP technisch so alles sauber und korrekt !

Die Route ist damit dann vollkommen überflüssig und eher kontraproduktiv, also weg damit.

Die Route ins 3er Netz wird automatisch beim Start des OpenVPN Services angelegt. Ich hatte sie nur nochmal (analog zu den Routen auf dem Internet-Router) als ständige Route mit der Metrik 1 eingetragen... Diese hab ich jetzt wieder auf beiden Servern gelöscht. Aber wie gesagt werden beim OVPN-Dienststart automatisch Routen ins 3er Netz angelegt. Hierbei ist mir Folgendes aufgefallen:

Der OVPN-Server (Server1) legt nur eine Route beim Dienststart an, und zwar eine Route ins komplette 3er Netz:

     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
      192.168.3.0    255.255.255.0      192.168.3.2      192.168.3.1     30

Der OVPN-Client (Server2) hingegen legt folgende Routen beim Dienststart an:

     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
168.3.1  255.255.255.255     192.168.3.21     192.168.3.22     30
168.3.20  255.255.255.252   Auf Verbindung      192.168.3.22    286
168.3.22  255.255.255.255   Auf Verbindung      192.168.3.22    286
168.3.23  255.255.255.255   Auf Verbindung      192.168.3.22    286

Das wird dann ja wohl seine Richtigkeit haben, weil der eine ja Server ist und ins ganze 3er Netz kommen muss (also auch zu anderen Clients) und der andere ja nur zum Server muss, richtig? Oder kann der Fehler, dass der 1er Server die LAN-IP des 2er Servers nicht erreichen kann, vielleicht doch an der OVPN-Konfig des OVPN-Servers und/oder -Clients liegen bzw. dass da noch was eingestellt werden muss?

Ansonsten ist das IP technisch so alles sauber und korrekt !

OK, aber wie kann ich denn noch prüfen/nachverfolgen, wo die Pakete vom 1er Server zur 2er LAN-IP hängen bleiben?
Auf beiden Servern läuft Wireshark. Auf Server 2 kommen gar keine Pakete an und auf Server 1 sieht ein fehlgeschlagender ping wie folgt aus:

Hier kann man ja sehen, dass der Ping zur 2.10 als Quell-IP die 3.1 hat, also scheint das Routing auf dem Server selbst ja zu klappen...
Also blockt doch einer der Internete-Router mit Firewall die Pakete - wie du ja schon vermutet hattest aqui?!? Aber warum kommt dann der ping zur 3.22 durch??
Kann man denn irgendie rausfinden, wo die Pakete hängen bleiben, also ob z.B. beim 1er o. 2er Router?

Da ich es einfach nicht hinbekommen habe, von Server 1 die LAN-Schnittstelle des Server 2 (und somit die Clients in Standort 2 etc.) zu erreichen, habe ich versucht, ohne die Open VPN Konfig nur mit Routing & RAS ein VPN zwischen den Standorten aufzubauen. Da weiß ich allerdings gar nicht so recht, wie ich anfangen soll und je mehr Anleitungen und Foreneinträge ich zum Thema "Site to Site mit Windows Server 2008" lese, um so verwirrter bin ich. Deshalb habe ich dazu mal einen neuen Thread eröffnet, um nicht für Verwirrung zu sorgen:
Site to Site VPN Server 2008 - Zwei Standorte per Routing und RAS verknüpfen

So, nun habe ich es doch mit den NAT-Routern hinbekommen, ein Gateway-to-Gateway-VPN zu erstellen, und zwar per IPSec mit IKE mit presharde Key. Die Einstellungsmöglichkeiten beider Hersteller sind zwar unterschiedlich, aber nach längerem Probieren und Recherchieren hat mich die Aussage der Cisco-Hilfe auf den richtigen Weg gebracht:
Phase 1 establishes the preshared keys to create a secure authenticated communication channel. In Phase 2, the IKE peers use the secure channel to negotiate Security Associations on behalf of other services such as IPsec. Be sure to enter the same settings when configuring other router for this tunnel.
Bei Cisco gibt man die Werte für Verschlüsselungsart etc. alle in einer Oberfläche ein, während bei Netgear die Phasen unterschieden werden, also das VPN als solches anlegen (mit Einstellungen für Phase 1) und dann noch eine Policy mit Einstellungen für Phase 2, die dann für die zuvor angelegte VPN-Konfig gilt.
Also nochmals besten Dank für die hilfreichen und ermutigenden ( face-smile ) Tipps und Ratschläge!!!

Eine entsprechende Cisco Konfig findet man auch in dem o.a. Tutorial.
Nebenbei: Hier wird sowohl im GUI als auch im CLI auch zw. Phase 1 und 2 unterschieden. Muss ja auch so sein, denn das ist elementarer Grundbestandteil von IPsec !!
Aber gut wenns nun klappt wie es soll bei dir.

Aber gut wenns nun klappt wie es soll bei dir.

Ja, und wie

Danke nochmal!!

German solved Question Windows Server Microsoft

Hotly discussed

Check of ZFW Firewallgleixnerd - 5 Comments

Wireguard VPN on UDM Pro behind Fritzbox - Handshake did not completejstricker - 3 Comments