QVPN - Datei- und Druckerfreigaberessource (10.10.10.1) ist online, antwortet jedoch nicht auf Verbindungsversuche.

Folge den Paketen, sprich untersuche mit einem tracerout oder tracert, wo die her laufen und ob diese ggf. eine Route nicht haben die benötigt wird, dass sie dort ankommen wo sie hin gehören.

Wenn du einen Punkt gefunden hast, wo was nicht stimmen könnten, musst du dir die Routing Tabelle auf dieser Kiste ansehen.

Bsp. deine Fritz, wird keine statische Route hinterlegt sein für dein VPN Netz, das muss ggf. noch eingetragen werden.

Wenn das alles stimmt, kommen die Daten auch da an wo sie hin sollen.

Dann müssen die aber noch durch die Firewall durch gelassen werden, also auch da noch mal prüfen, ob ggf. bestimmte Netze nicht erlaubt sind.

Hat es denn einen bestimmten Grund dass du das Gerät unter der VPN IP erreichen willst? Wenn QVPN die routen nicht pushen kann, kannst du die routen in der Client config eintragen und solltest dann keine Probleme haben das Gerät unter der LAN IP zu erreichen...

Wo ist die Route des Zielnetzwerks, die fehlt.

Dann kannst du mit der real Netzwerk IP die NAS ansprechen.

So mache ich das ja, da meine pfSense für Client VPN einen virtuellen IP Bereich verteilt.

Da benötige ich dann noch Regelwerk und schon läuft das über meine kleine Firewall.

Diese gibt in meinem Fall dem Client aber auch das Zielnetz 0.0.0.0/0 mit, so das ich dann auch über meinen Tunnel Surfe.

Kurios ist, dass es ja scheinbar auf dem anderen System vorher lief, wenn ich das richtig verstanden habe und nur der qnap ausgetauscht wurde...

Was mich dennoch etwas skeptisch macht: du hast den qnap in dem Netz 192.168.178.0/24, also ein Standard Netz der gängigen Router, die anderen Netze/ Standorte dürfen nicht das gleiche Netz verwenden, ist das entsprechend so umgesetzt?

Ja aber die anderen Standorte haben ja unabhängig vom Provider auch ein LAN, diese Adressen dürfen nicht 192.168.178.x sein, sprich nicht im gleichen IP Adressbereich liegen!

Bein Betrieb eines VPN Servers sollte dieser immer in einem Netz sein, welches nicht Standard bei den gängigen Routern ist, da es sonst zu Störungen kommt.

Am besten wählst du für das LAN des qnap ein Netz wie 192.168.174.x.

Dann wäre das Problem schonmal gelöst. Dann schreiben wir entsprechende routen in die Client configs und dann sollte alles laufen. Eventuell wie schonmal erwähnt noch ein bissl was an der Firewall, falls die dann noch was blockt, aber das wird ja in den logs stehen...

Zitat von tonamerlin

Die Adressen der anderen LAN sind total unwichtig.

Die IPs der andere Netze sind dann wichtig, wenn sich Geräte gegenseitig erreichen sollen, die auf der einen Seite im LAN auf der anderen im VPN sitzen oder sogar nur über einen oder mehrere VPN Tunnel miteinander verbunden sind.

So unterstützt IKEv2 dann auch Mobike, also dynamisches Routing für den Tunnel an sich.

Aber das ist eher was für komplexere Netzstrukturen und Standortvernetzung usw. Da wird ja dann auch gern dynamisches Routing eingesetzt und es gibt eine Backup Leitung.

Dienstbindung, Zugriffschutz ist auf dem Zeilnas auch ein Punkt den man mal kontrollieren sollte.

Zitat von tonamerlin

Die Adressen der anderen LAN sind total unwichtig.

Der Adressraum 192.xxx.xxx.xxx gehört zu den (ehemals) C-Netzen, die keine Verbindung ins internet bekommen. Daher der Router.

Was hat das denn mit Router zu tun? Du sagst doch selbst, dass diese privaten IPv4-Adressen nicht ins Internet geroutet werden dürfen. Warum sollten dann IP-Pakete aus Deinem LAN den Weg über VPN wählen, wenn sie nur beschränkt routbare Adressen verwenden?

Zitat von tonamerlin

Ich spreche ein über QVPN verbundenes Gerät in einem anderen LAN nicht mit der IP im dortigen LAN sondern mit der vom VPN übergebenen IP an. Aber das ist alles unwichtig, weil mich das bei der Lösung nicht weiterbringt.

Und was heißt dies nun, wenn Du behauptest, dass ein über QVPN verbundenes Gerät in einem anderen LAN nicht mit der IP im dortigen LAN sondern mit der vom VPN übergebenen IP angesprochen wird? Wie stellst Du sicher, dass diese vom VPN übergebenen IP nicht im lokalen Netzwerk vorkommt und auch nicht aus dessen Netzbereich stammt, also geroutet werden muss? Es reicht nicht, dass diesevom VPN übergebene IP-Adresse nicht im lokalen Netzwerk vorkommt. Und wenn dieses VPN-Gateway nicht einmal den Überblick hat, welche IP-Adressen im lokalen Netzwerk alle vorkommen, dann ist nicht einmal sichergestellt, dass im lokalen Netzwerk eine IP-Adresse in Verwendung ist, die identisch ist mit der vom VPN übergebenen IP-Adresse. So wie Dennis bereits geschrieben hat.

Hallo,

ergänzend zum Beitrag von Chef1:

Zitat von tonamerlin

Der Adressraum 192.xxx.xxx.xxx gehört zu den (ehemals) C-Netzen, die keine Verbindung ins internet bekommen.

Korrekt daran ist lediglich, dass 192er-Adressen zu den Class-C-Netzen gehören. Der Rest des Satzes ist falsch.

Du meinst die sog. privaten Netze, also Adressen, die von der öffentlichen Vergabe ausgespart wurden und niemandem "gehören", weil sie für interne Netze vorgesehen sind.

Mehr Infos dazu findest du z.B. auf https://de.wikipedia.org/wiki/Private_IP-Adresse und speziell zu den entsprechenden Adressbereichen im Abschnitt https://de.wikipedia.org/wiki/…se#Private_Adressbereiche

Kurzform für diejenigen, die jetzt keine Zeit oder Lust für die Links haben: Der für private Netze reservierte Class-C-Adressbereich ist deutlich kleiner als oben irrtümlich behauptet: 192.168.x.x, umfasst also die Adressen 192.168.0.0 bis 192.168.255.255.

MfG

Digedag64

Und wenn Du nun auch noch sagst, wo denn das Problem war und wie Du es gelöst hast, dann haben auch andere was davon .

Gruss

Portfreigaben und -weiterleitungen für das VPN auf nem QNAP ist eine Sache, aber Dein QNAP steht ja mal so richtig nackig dar...

Alle Ports außer 1194 haben nichts mit dem VPN zu tun, Du solltest ganz dringend nochmal versuchen die anderen Ports zu schließen!