mrparker
Mar 23, 2020, updated at Apr 21, 2022 (UTC)
view2070
view11
0
Goto Top

OpenVPN Windows 2016 Server - Routing Kopfzerbrechen mitten in der Coronakrise. RRAS Fehler?

GermansolvedQuestionRouters, RoutingNetworks
Liebe Community!

Ich bin neu hier und habe bisher auf eurere Seite seit vielen Jahren immer technische Lösungen gefunden, ohne, dass es einen gesonderten Beitrag von mir bedurft hätte. Dafür möchte ich mich einmal zunächst bedanken.

Diesmal komme ich selbst nach über fünf Tagen Recherche und "Ausprobiererei" in allen Richtungen nicht einmal im Ansatz zu einem funktionierenden Ergebnis und bin wirklich verzweifelt. Kurz zur Vorgeschichte: ich betreue eine mini-EDV Anlage im Familienkreis, in der ein Win2016 Server als File Server arbeitet, und vier lokale Clients vorhanden sind. Das lokale Routing übernimmt das DSL Modem (statische IP), das Firewall und DNS Server in einem ist. Es ist recht simpel aufgebaut, weshalb ich mir nie träumen hätte lassen, an so einer Aufgabe zu scheitern.

Der Netzwerkaufbau sieht in etwa so aus:

vpn graphik2

Aufgrund der Coronakrise versuche ich seit Tagen verzweifelt, ein sicheres OpenVPN Netzwerk aufzubauen ("VPN-Client" auf der Skizze). Ich habe mich an DIESE Anleitung gehalten. Es klappt soweit, dass ich mit dem VPN Client extern über das WWW auf den VPN Server erfolgreich connecten kann. Ebenso kann ich (mittlerweile) auch den Server sowohl über seine VPN-IP (10.10.0.1), als auch über seine lokale IP (192.168.1.254), anpingen (komischerweise ist ein direkter Zugriff via SMB über die lokale IP aber sehr "lahm" und bricht immer wieder ab).

Soweit, so gut bzw so schlecht. Denn ich kann nur den Server anpingen, ich kann nicht - mit welcher Routing Einstellung auch immer - die anderen lokalen Clients oder Peripheriegeräte erreichen oder anpingen oder darauf zugreifen, beispielsweise den lokalen Router unter 192.168.1.253.

Am Windows 2016 Server habe ich Routing- und RAS installiert (wie in der Anleitung gefordert). Zusätzlich wurde bzw war auch die der Dienst "Netzwerkrichtlinienserver" NPS installiert (keine Ahnung ob das eine Rolle spielt). Ich habe auch, wie unten in den Configs ersichtlich, die entsprechenden Routen eingetragen, so wie es stimmen müsste. Dennoch kann ich nicht die anderen Peripheriegeräte oder Clients anpingen, egal, welche statische Routen ich (versuchshalber) im RRAS noch zusätzlich gesetzt habe. Die Firewall habe ich schon komplett deaktiviert gehabt testweise, auch die NPS Richtlinien habe ich testweise alle deaktiviert, ohne Erfolg. Ich bin mit meinem Debugging und Latein wirklich am Ende.

Aus lauter Verzweiflung, ob es vielleicht am DSL Router liegt, habe ich über ein (als Backuplösung vorhandenes) Synology NAS einen OpenVPN Server am NAS installiert, und damit klappt der Zugriff und die Verbindung auf das lokale LAN problemlos. Offenbar schafft es die Synology - besser als ich - die entsprechenden Routen intern zu setzen. Leider bietet Synology nicht Client Certificate als Authentifizierung an, sondern nur User+Pass, weshalb mir diese Verbindung viel zu unsicher ist. Es muss eine direkte Verbindung zum lokalen Server irgendwie doch klappen.

Die Server config lautet wie folgt:

#################################################
# OpenVPN (MvA-Networks Conf)
# VPN Server Configuration
#
# Copyright 2006-2019 (04.09.2019) www.mva.ch
# MvA Internet Services GmbH
#################################################

local 192.168.1.254
port 1194
proto udp
dev tun
topology subnet

# ----------------------------------------------
# Zertifikate
# ----------------------------------------------

dh "C:\\Program Files\\OpenVPN\\server-keys\\dh2048.pem"  
ca "C:\\Program Files\\OpenVPN\\server-keys\\ca.crt"  
cert "C:\\Program Files\\OpenVPN\\server-keys\\SERVER.crt"  
key "C:\\Program Files\\OpenVPN\\server-keys\\SERVER.key"  

# ----------------------------------------------
# Server-Setup
# ----------------------------------------------

server 10.10.0.0 255.255.255.0
ifconfig-pool-persist "C:\\Program Files\\OpenVPN\\ipp.txt"  
client-to-client

# ----------------------------------------------
# Client-Settings (inkl Special Dir)Files
# ----------------------------------------------

client-config-dir "C:\\Program Files\\OpenVPN\\ccd"  
push "route 192.168.1.0 255.255.255.0"  
push "dhcp-option DNS 192.168.1.254"  
push "dhcp-option DNS 192.168.1.253"  
push "dhcp-option DOMAIN XXXXX.local"  

# ----------------------------------------------
# Defaults
# ----------------------------------------------

keepalive 10 120
compress lz4
persist-key
persist-tun

# ----------------------------------------------
# Logging
# ----------------------------------------------

status "C:\\Programme\\OpenVPN\\log\\openvpn-status.log"  
log "C:\\Programme\\OpenVPN\\log\\openvpn.log"  
log-append "C:\\Programme\\OpenVPN\\log\\openvpn.log"  
verb 4


Die Client-Config lautet wie folgt:
##############################################
# MvA-Networks Connect. OpenVPN ClientScript #
##############################################

client
dev tun

proto udp
remote XXX.XXX.XXX.XXX 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server

ca "C:\\Program Files\\OpenVPN\\config\\ca.crt"  
cert "C:\\Program Files\\OpenVPN\\config\\client.crt"  
key "C:\\Program Files\\OpenVPN\\config\\client.key"  

compress lz4
verb 4

Server route print lautet wie folgt:
IPv4-Routentabelle
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0    192.168.1.253    192.168.1.254    281
        10.10.0.0    255.255.255.0   Auf Verbindung         10.10.0.1    281
        10.10.0.1  255.255.255.255   Auf Verbindung         10.10.0.1    281
      10.10.0.255  255.255.255.255   Auf Verbindung         10.10.0.1    281
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      192.168.1.0    255.255.255.0   Auf Verbindung     192.168.1.254    281
    192.168.1.254  255.255.255.255   Auf Verbindung     192.168.1.254    281
    192.168.1.255  255.255.255.255   Auf Verbindung     192.168.1.254    281
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung     192.168.1.254    281
        224.0.0.0        240.0.0.0   Auf Verbindung         10.10.0.1    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung     192.168.1.254    281
  255.255.255.255  255.255.255.255   Auf Verbindung         10.10.0.1    281
===========================================================================
Ständige Routen:
  Netzwerkadresse          Netzmaske  Gatewayadresse  Metrik
          0.0.0.0          0.0.0.0    192.168.1.253  Standard
===========================================================================



Client route print lautet wie folgt:
IPv4-Routentabelle
IPv4-Routentabelle
===========================================================================
Aktive Routen:
     Netzwerkziel    Netzwerkmaske          Gateway    Schnittstelle Metrik
          0.0.0.0          0.0.0.0      192.168.0.1     192.168.0.24     25
        10.10.0.0    255.255.255.0   Auf Verbindung         10.10.0.4    281
        10.10.0.4  255.255.255.255   Auf Verbindung         10.10.0.4    281
      10.10.0.255  255.255.255.255   Auf Verbindung         10.10.0.4    281
        127.0.0.0        255.0.0.0   Auf Verbindung         127.0.0.1    331
        127.0.0.1  255.255.255.255   Auf Verbindung         127.0.0.1    331
  127.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
      192.168.0.0    255.255.255.0   Auf Verbindung      192.168.0.24    281
     192.168.0.24  255.255.255.255   Auf Verbindung      192.168.0.24    281
    192.168.0.255  255.255.255.255   Auf Verbindung      192.168.0.24    281
      192.168.1.0    255.255.255.0        10.10.0.1        10.10.0.4     25
        224.0.0.0        240.0.0.0   Auf Verbindung         127.0.0.1    331
        224.0.0.0        240.0.0.0   Auf Verbindung         10.10.0.4    281
        224.0.0.0        240.0.0.0   Auf Verbindung      192.168.0.24    281
  255.255.255.255  255.255.255.255   Auf Verbindung         127.0.0.1    331
  255.255.255.255  255.255.255.255   Auf Verbindung         10.10.0.4    281
  255.255.255.255  255.255.255.255   Auf Verbindung      192.168.0.24    281
===========================================================================
Ständige Routen:
  Keine


Meine Vermutung liegt darin, dass die Routing Funktionen des Servers nicht klappen, da der Server nicht der "Hauptrouter" des lokalen Netzes ist, sondern eben das DSL Modem. Irgendwie schafft der VPN Server kein richtiges Routing, die Pakete gehen verloren bzw kommen nicht ins lokale LAN durch und wieder retour. Was kann dort falsch konfiguriert sein? Meiner Meinung nach müssten die Routing anfragen, die vom VPN Client an den Server gestellt werden, per RRAS ans DSL Modem "weitergegeben" werden, und wieder retour. Aber wie? Oder ist der RRAS eventuell falsch konfiguriert für meine "Anforderungen"?

Liebe Community, ich weiß, dass manche Leute schlicht zu faul sind, um sich durch HowTo's zu arbeiten und die Basics zu verstehen. Ich habe wirklich alles Sinnvolle, was zu dem Thema aufzufinden war, durchforstet (insb im Hinblick auf Win2016 Server und OpenVPN), aber ich komme leider zu keiner Lösung. Hat jemand von euch einen Tipp oder Hilfe für mich?


Ich wäre euch unenendlich dankbar. Aufgrund der Coronakrise wäre ein sicherer VPN Zugang dringendst erforderlich und ich krieg' es einfach nicht auf die Reihe...

Viele Grüße aus Österreich!
comment-contentCommentShareShare
Share on Facebook Share on Twitter Share on Reddit Share on Linkedin

Content-Key: 560413

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

Printed on: April 26, 2024 at 09:04 o'clock

11 Comments
Latest comment
Goto Top
Member: BirdyB
BirdyB Mar 23, 2020 at 14:40:19 (UTC)
Goto Top
Moin,
hast du denn auch auf deinem Router die Rückroute zum OpenVPN-Server gesetzt? Die wird gerne mal vergessen.

Viele Grüße
Member: MrParker
MrParker Mar 23, 2020 at 14:44:07 (UTC)
Goto Top
Vielen Dank für die schnelle Antwort.

Nein, denn eine solche Funktion bietet der DSL-Router nicht. Und nachdem es beim Synology OpenVPN Versuch auch reibungslos geklappt hat, ohne, dass ich beim DSL-Router etwas verändert habe, also eine Rückroute zum Synology gesetzt hätte, kann es daran ja eigentlich nicht liegen, zumindest dachte ich das. Liege ich da falsch?
Mitglied: 143127
Solution 143127 Mar 23, 2020 updated at 15:43:50 (UTC)
Goto Top
Zitat von @MrParker:
Nein, denn eine solche Funktion bietet der DSL-Router nicht. Und nachdem es beim Synology OpenVPN Versuch auch reibungslos geklappt hat, ohne, dass ich beim DSL-Router etwas verändert habe, also eine Rückroute zum Synology gesetzt hätte, kann es daran ja eigentlich nicht liegen, zumindest dachte ich das. Liege ich da falsch?
Ja da liegst du falsch, denn die Synology NATed (Masquerade) das OpenVPN Netz automatisch auf die Synology IP im Heimnetz und somit ist dort keine Route erforderlich weil alle Pakete aus dem VPN Subnetz mit der Synology-IP ins Heimnetz wandern face-wink. Wenn dein Router keine statischen Routen unterstützt musst du also entweder auf dem Windows-Server das VPN Subnetz natten oder auf den Clients eine statische Route auf den Server anlegen damit diese die korrekte Rückroute für das OpenVPN Netz finden.
Außerdem muss zusätzlich auf dem Windows Server das Forwarding aktiviert werden damit dieser überhaupt Pakete weiterleitet.
Diese und weitere Grundlagen zu OpenVPN und Grundlagen Routing und Forwarding findest du hier in zig Tutorials.
Routing von 2 und mehr IP Netzen mit Windows, Linux und Router
Einfach erst mal die Grundlagen Routing verinnerlichen dann verstehst du auch warum das jetzt bei dir so ist.

Ich würde mir gleich erst mal einen vernünftigen Router zulegen! Ein Router ohne statische Routen dürfte man eigentlich erst gar nicht "Router" nennen dürfen, alles andere ist Spielzeuch für die Krabbelguppe face-smile.

Und wie immer gilt das Sprichwort "Route where you can, NAT where you must". NAT also nur einsetzen wenn es wirklich nicht anders geht, denn es ist erstens eine Performance-Bremse und zweitens erschwert viele Kommunikationsmöglichkeiten unnötig.
heart1
Member: MrParker
MrParker Mar 23, 2020 updated at 16:33:20 (UTC)
Goto Top
Vielen, vielen, vielen Dank! Das war es!

Das rettet mir wirklich den Tag...

Jetzt verstehe ich auch, warum es beim Synology geklappt hatte. Ich hatte NAT im RRAS zwar hinzugefügt, aber die Schaltfläche "privates Netzwerk" beim entsprechenden Adapter ausgewählt gehabt, dabei ist der ja "öffentlich" (wenn auch hinter dem Router). Nun "NATed" der Server alles intern und der Zugriff klappt problemlos.

Darf ich noch eine Frage dazu stellen: Ich weiß, NAT am VPN-Server ist nun offenbar keine "elegante" Lösung in netzwerktechnischer Hinsicht, aber wirkt es sich auch sicherheitstechnsich aus? Oder ist es halt netzwerktechnisch "pfusch", aber hinsichtlich der Sicherheit (Zugriff von Außen, Attacken, etc) nicht relevant, weil es ohnehin über die VPN Leitung läuft? Insbesondere, da es nur ein "baby-netzwerk" ist (und auch vorerst so bleibt). DANKE noch einmal!
Mitglied: 143127
143127 Mar 23, 2020 updated at 16:47:11 (UTC)
Goto Top
Zitat von @MrParker:
Ich weiß, NAT am VPN-Server ist nun offenbar keine "elegante" Lösung in netzwerktechnischer Hinsicht, aber wirkt es sich auch sicherheitstechnsich aus? Oder ist es halt netzwerktechnisch "pfusch", aber hinsichtlich der Sicherheit (Zugriff von Außen, Attacken, etc) nicht relevant, weil es ohnehin über die VPN Leitung läuft? Insbesondere, da es nur ein "baby-netzwerk" ist (und auch vorerst so bleibt). DANKE noch einmal!
Nun alles was vom Client in dein Netz kommt wird genatted, heißt also im Endeffekt das ausgehend von deinem Netzwerk in Richtung -> Client ohne DST-NAT erst einmal kein Zugriff auf diesen möglich ist da die NAT Barriere wie eine Firewall wirkt. Wenn es ein Client ist und kein Server der Dienste anbietet ist das nicht weiter schlimm, wird erst interessant wenn du Site-2-Site Netze damit verbindest denn diese sind mit der NAT-Barriere nicht vernünftig zu nutzen da du ja für jede Verbindung extra eine Weiterleitung anlegen müsstest. Performance-Technisch ist NAT immer zu meiden. Sicherheitstechnisch ist es in deinem Fall bei einem Client nicht weiter relevant da es eh im Tunnel stattfindet, außer das dein Client von deinem LAN durch die NAT Barriere zuätzlich abgeschirmt ist.

DANKE noch einmal!
You're welcome.
heart1
Member: aqui
Solution aqui Mar 23, 2020 at 18:09:23 (UTC)
Goto Top
Ausserdem erklärt das hiesige OpenVPN Tutorial genau wie solche OpenVPN Designs hinter NAT Router auszusehen haben !
Guckst du hier:

ovpn

Dort sind alle relevanten Schritte für das Setup erklärt und eine Standard Konfig findet man hier:
OpenVPN - Erreiche Netzwerk hinter Client nicht

Generell ist das kein gutes VPN Design denn der gravierende Nachteil ist in solchen internen VPN Designs immer das man...
  • Erstens ein Loch in die Firewall bohren muss mit Port Forwarding und so völlig ungeschützten Internet Verkehr in ein sonst gesichertes lokales LAN schleust.
  • Zweitens den ungeschützten VPN Traffic auf so eine zentrale und Sicherheits anfällige Komponenten wie den Server terminiert. bricht dort ein Angreifer aus liegen ihm gleich die Kronjuwelen zu Füßen.
Sowas bleibt also immer dilletantisch und ist ein Schnellschuß

Es gibt also immer sehr gute Gründe das VPN immer auf die Peripherie wie Router oder Firewall zu legen !
Diverse Foren Tutorial beschreiben hier schnelle und unkomplzierte Lösungen für sowas:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Oder gleich mit den bordeigenen VPN Clients aller Betriebssysteme und Smartphones ganz ohne zusätzliche Software:
IPsec IKEv2 VPN für mobile Benutzer auf der pfSense oder OPNsense Firewall einrichten

Sollte man immer mal drüber nachdenken, auch in schweren Zeiten sollte Sicherheit etwas wert sein. Oder gerade dann !
Member: MrParker
MrParker Mar 24, 2020 updated at 12:16:17 (UTC)
Goto Top
Vielen Dank! Ganz genau so, wie in dem Schema, sollte es sein. Der derzeitige Router vom DSL Betreiber schafft definitiv keine statischen Routen... Absurd.

Nachdem Windows NAT mir zwar die VPN-Verbindung ermöglicht, aber, sobald NAT auf der Netzwerkschnittstelle aktiviert ist, meine lokalen Clients nicht mehr auf den Server zugreifen können, werde ich wohl oder übel nicht da herum kommen, das "ordentlich" zu machen. Darf ich fragen, welcher Router da empfehlenswert wäre? Am liebsten hätte ich natürlich einen Router, der sowohl VPN-Server als auch Router ist, alternativ würde natürlich auch ein "bloßer" Router und separater VPN-Server gehen, aber welches Peripheriegerät wäre in diesem zweiten Fall sinnvoll? Wichtig wäre mir natürlich Client-Certificate...
Member: BirdyB
BirdyB Mar 24, 2020 at 12:43:32 (UTC)
Goto Top
Moin,
bei den Routern / Firewalls hast du jede Menge Möglichkeiten. Das hängt etwas von den Anforderungen und vom Budget ab.
Für den privaten Bereich werkelt bei mir ein TP-Link mit OpenWRT. Für meine privaten Zwecke reicht mir hier die Performance erstmal aus.
Du kannst natürlich auch eine opnSense/pfSense nehmen. Je nach Hardware-Unterbau ist das ganze dann nochmal deutlich performanter.
Ansonsten habe ich ganz gute Erfahrungen mit Sophos gemacht.
Mikrotik liefert auch gute Geräte zum günstigen Preis, hat aber eine steile Lernkurve, wenn man sich damit nicht auskennt (ich komme damit irgendwie nicht so richtig zurecht)

VG
Member: aqui
aqui Mar 24, 2020 at 16:28:43 (UTC)
Goto Top
hat aber eine steile Lernkurve, wenn man sich damit nicht auskennt
Oder weiss wo sich Lösungen dafür verbergen ! face-wink
Clientverbindung OpenVPN Mikrotik

Der kleinste Mikrotik fängt bei 21 Euronen an:
https://www.varia-store.com/de/produkt/33635-mikrotik-routerboard-rb941- ...
Member: MrParker
MrParker Mar 31, 2020, updated at Apr 21, 2022 at 13:32:45 (UTC)
Goto Top
Hi Leute,

sorry dass ich mich noch einmal an euch wenden muss, aber ihr habt mir jetzt schon so geholfen, und ich bin dem Ziel sehr, sehr nahe, aber es fehlen die letzten Meter. Trotz mehrtägiger Recherche komme ich einfach nicht auf den Fehler drauf...

Was wurde gemacht: Ich habe den ISP-Router als Modem/Bridge umfunktioniert, und einen eigenen Router (der statische Routen beherrscht, wie cool ist das denn...) eingerichtet. Auf diesem habe ich, wie eh' in allen Tutorials beschrieben, eine statische Route zum VPN-Server (bis jetzt immer noch der Win2016Server, alternative Hardware kommt erst in 2-3 Wochen) eingetragen. Soweit, so gut.

Die Topologie sieht also so aus:

publishable_topo

Ergebnis:

  • Die Clients können erfolgreich auf den VPN-Server (Windows 2016) über die öff. IP connecten.
  • Ping vom VPN-Client auf die "virtuelle" VPN-Server-IP (10.10.0.1) und auf die lokale Server-IP (192.168.1.254) klappt beides.
  • Ebenso umgekehrt Ping vom VPN-Server auf die "virtuelle" IP des VPN-Clients (10.0.0.4)
  • Nachdem nunmehr die statische Route endlich eingetragen ist, klappt auch Ping vom VPN-Client ---> auf andere lokale Clients (bspw NAS) im lokalen Netz.
  • VPN-Clients können also grundsätzlich das loakale interne Netzwerk anpingen. (ca 20-22ms Latenz) und erreichen.
Für mich als Laie heißt das, dass Port-Forwarding und Routen eigentlich richtig eingerichtet worden sind (habe mich bezgl Konfiguration von Routing und RAS an DIESE Anleitung gehalten).

Die Betonung liegt aber leider nur auf Anpingen , denn mehr geht nicht wirklich. Weder auf SMB Dienste, noch auf HTTP Dienste kann stabil zugegriffen werden.

Die Verbindung (bspw über HTTP) timed-out die halbe Zeit, ich kann nicht einmal eine exe Datei sinnvoll über SMB ausführen. Manchmal erreicht man den Server bzw den Dienst, manchmal nicht. Es wirkt so, als ob die Verbindung extrem buggy oder langsam wäre (was nicht der Fall ist, sehr niedrige Latenz, passable Bandbreite und vor allem mit einem dd-wrt Router als VPN-Server als Test geht die Verbindung soweit "normal").

Was hierzu interessant ist, ist, dass die lokalen Clients (bspw 192.168.1.103) wiederum den Server (192.168.1.254) auf seiner VPN-IP (10.10.0.1) erfolgreich anpingen können, nicht jedoch den dahinter liegenden Client (bspw 10.10.0.4). Umgekehrt kann aber der VPN-Client sehr wohl den lokalen Client anpingen.

Dem nicht genug, ist die Verbindung eben so furchtbar instabil und bricht die halbe Zeit ab (nicht der VPN-Tunnel an sich, nur der Dienstzugriff auf das interne Netz, also halt so, als ob die Verbindung 800ms aufwärts hätte, was jedoch nicht der Fall ist). Nachdem die lokalen Clients zwar den Server auf seiner VPN-IP (10.10.0.1) anpingen können, nicht jedoch die dahinter liegende VPN-Clients (bspw 10.10.0.4), gehe ich stark davon aus, dass es (wieder einmal) ein Routing-Problem ist bzw am Win2016Server liegen muss, der die Anfragen nicht an den VPN-Client "weitergibt"... aber ich komme nicht drauf, was es sein könnte. Es muss, so meine Vermutung, jedenfalls mit dem Win2016Server zutun haben.

Hat jemand eine Idee? An den configs oben hat sich nichts geändert....

Edit: Im Server OpenVPN Logfile steht folgendes:
Tue Mar 31 23:33:19 2020 us=860147 DELL/XXXXXXXXXXXXXXXX MULTI: bad source address from client [::], packet dropped
Das scheint aber keinerlei Bedeutung zu haben, da es IPv6 127.0.0.1 Loopback ist, offenbar... soweit das Google hergibt face-sad

2. Edit betreffend Debuggin:
Bei einer "frisch verbundenen" Verbindung kann ich die HTTP Dienste von lokalen Clients (bspw NAS Webinterface) vom VPN-Client zum Großteil aufrufen. Sobald ich aber auf das Netzlaufwerk via SMB zugreifen möchte, fängt die Verbindung an zu buggen. Sie bricht ab, ich kann auch auf HTTP zugreifen, usw... Ich bin wirklich verzweifelt.. Irgendwie crasht diese Anfrage das ganze.
Member: aqui
aqui Apr 01, 2020 updated at 07:54:42 (UTC)
Goto Top
Die Topologie sieht also so aus:
Es wäre hilfreichen wenn du hier das "+" Zeichen klickst wie es in den FAQs steht zum Einfügen von Bildern, dann erscheint die Grafik auch im richtigen Kontext des Textes ! FAQ lesen hilft wirklich !
VPN-Clients können also grundsätzlich das loakale interne Netzwerk anpingen. (ca 20-22ms Latenz) und erreichen.
Sehr gut ! Zeigt das VPN technisch alles sauber funktioniert !
habe mich bezgl Konfiguration von Routing und RAS an DIESE Anleitung gehalten).
Kannst dich auch an DIESE Anleitung halten, da steht es auch noch einmal explizit beschrieben !
Weder auf SMB Dienste, noch auf HTTP Dienste kann stabil zugegriffen werden.
WER bzw. welches Betriebssystem stellt diese Dienste zur Verfügung ?
Wenn das Windows basierte Maschinen sind muss einen das nicht groß wundern ! Die lokale Windows Firewall blockt generell ALLES was andere Absneder IP Adressen als 192.168.1.x hat. Greifen also deine OVPN Clients auf irgendwelche Windows basierte Maschinen zu haben sie ja logischerweise einen 10.10.0.x Adresse, sind also fremd und die lokale Windows Firewall blockt hier alles ab.
Letztlich also erwartbares Verhalten !
In deinem Netz sind ja 2 Drucker. Wenn die ein Web GUI zum konfigurieren haben sollte das aber von den Clients erreichbar sein. Drucker haben in der Regel keine lokale Firewall !
Das geht aber nur wenn die Drucker ein Default Gateway auf die .253 gelegt haben !
Sprich also wenn du einen Winblows Webserver hast MUSST du dessen lokale Firewall mit erweiterten Eigenschaften aufrufen und im Karteireiter Bereich den Adressbereich entweder auf "Beliebig" stellen (dann akzeptiert er alle fremden IPs) oder spezifisch auf 10.10.0.0 /24 (dann akzeptiert er nur fremde IPs aus dem 10.10.0.0er Netz ).
Gleiches gilt für den Datei- und Druckerdienst usw. !
Hast du das entsprechend angepasst ?
Oder sind deine Dienste Linux basierend wie NGINX, Apache oder Samba ??
nicht jedoch den dahinter liegenden Client (bspw 10.10.0.4).
Auch hier ist wieder die lokale Winblows Firewall der Buhmann !! Ist ja auch logisch. Auf den Clients greifst du mit einer Absender IP 192.168.1.x zu die fremd für die Firewall ist. Folglich blockt sie den ICMP Zugang (ICMP ist Ping) da eine fremde IP Adresse.
Doppelt kommt nch hinzu das das ICMP Protokoll als solches per Default in der Windows Firewall geblockt ist.
Auch heir musst du das erst vom Protokoll her explizit erlauben und zusätzlich hier auch wieder die Range auf "Beliebig" usw. anpassen.
icmp-firewall
Es liegt bei dir also vermutlich alles nur am falschen oder fehlerhaften Customizing der Windows Firewall !

Generell ist dein Design mit einem sog "one armed" VPN Server nicht besonders glücklich. Das liegt daran das Traffic über ein und dasselbe Interface in den Server rein- und wieder raus muss. Es wird also mit jedem einzelnen Paket immer doppelt belastet. Vom Security Problem mal nicht zu reden das du ungeschützen Traffic ins lokale Netz lassen musst.
Für kleine OVPN Installationen wie sie auch im o.a. Tutorial beschrieben sind ist das kein Problem. Das rennt sogar mit einem Raspberry Pi 4 sehr stabil und auch performant.
Wenn du allerdings gigabyteweise Daten kopieren musst oder remote Programme ausführst kann das zu Laufzeit Verzögerungen kommen. Das sollte dir bewusst sein.
Laut deiner Zeichnung betreibst du ja auch eine Router Kaskade. Warum man dann hinter einer Firewall noch einen Router kaskadiert ist vollkommen unverständlich ?! Ode rist das jetzt nur symbolisch in der Zeichnung gemeint ? Das ist sehr verwirrend.
Sinnvoll wäre es aber den VPN Server dann performant in die Peripherie zu bringen auf Router oder Firewall. So oder so sollte aber auch bei entsprechender one armed Server Anbindung und Performance ein flüssiges Arbeiten mit dem VPN in so einer Konstellation immer möglich sein.
Die Frage ist auch ob der Server eine dedizierte Maschine ist oder noch andere Sachen nebenbei macht.
Auch solltest du einmal die Netzwerk Infrastruktur checken ob du ggf. Autonegotiation Probleme oder ggf. andere HW Probleme hast die diesen gestörten Betrieb bedingen.
Eine sehr starke Vermutung ist das du MTU/MSS Problem hast die durch die SSL Encapsulation bedingt sind. Genau das resultiert in solch einem Verhalten, weil die beteiligten Router dann Fragmentieren müssen wenn die Paket Sizes durch falsches MTU Setting zu groß werden. Das resultiert dann in einem massiven Performance Verlust.
Siehe dazu auch hier:
https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-ope ...
Mache also diesen Ping Test mit einem aktiven Client auf eine IP im lokalen Netz und setze die Packet Size in 10er Schritten herab von 1500 anfangend.
Passe dann die Tunnel MTU und MSS Size im OVPN Setup beidseitig an ! 1420 ist also schonmal ein guter Richtwert.
tun-mtu 1492
mssfix 1400
in der Client und Server conf Datei wäre mal ein grober Daumenwert.
Besser aber genau messen.
Sehr hilfreich ist auch der temporäre Parameter mtu-test mit der der OVPN Server die besten Werte selber ermittelt:
https://forums.openvpn.net/viewtopic.php?t=25039
Dr. Google hat bei der Suche nach "OpenVPN mtu size" hunderte solcher Dokumente.
Wie gesagt...im Normalfall arbeiten solche Designs auch mit einem RasPi als OVPN Server fehlerlos wenn man es denn richtig customized !
GermansolvedQuestionRouters, RoutingNetworks