135624
Oct 06, 2018, updated at 12:25:53 (UTC)
6478
8
0
SMB-Authentifizierung SMB.hidrive.strato.com über OPENVPN nicht möglich
Hallo zusammen,
ich habe 2 pfsense Firewalls. Eine ist auf einem dedizierten Server bei einem großen Hoster installiert und eine hängt bei mir zu hause hinter einem Modem und macht PPPOE.
Ich habe jetzt die Konfiguration verglichen. Die Konfig ist für die OPENVPN-Verbindung und die dafür vorhandenen Regeln komplett identisch.
Ergebnis:
Zuhause bekomme ich das Anmeldefenster, jedoch sagt er, dass die Zugangsdaten falsch sind. Zitat: "Das angegebene Netzwerkkennwort ist falsch". Auf dem Server funktioniert es.
Ich habe es aus dem Netz zuhause mehrfach von anderen Geräte ausprobiert. Es funktioniert nicht. Diese Anleitung habe ich eingerichtet: https://forum.netgate.com/topic/132663/solved-erläuterung-openvpn/9
Was kann ich noch prüfen? Wo ist der Unterschied? Das letzte mal hat das Outbound NAT das Problem gelöst. Aber das ist konfiguriert.
Ich habe leider keine Ansätze mehr
Falls ihr weitere Informationen braucht, gebt mir gerne Bescheid.
Vielen Dank!
ich habe 2 pfsense Firewalls. Eine ist auf einem dedizierten Server bei einem großen Hoster installiert und eine hängt bei mir zu hause hinter einem Modem und macht PPPOE.
Ich habe jetzt die Konfiguration verglichen. Die Konfig ist für die OPENVPN-Verbindung und die dafür vorhandenen Regeln komplett identisch.
Ergebnis:
Zuhause bekomme ich das Anmeldefenster, jedoch sagt er, dass die Zugangsdaten falsch sind. Zitat: "Das angegebene Netzwerkkennwort ist falsch". Auf dem Server funktioniert es.
Ich habe es aus dem Netz zuhause mehrfach von anderen Geräte ausprobiert. Es funktioniert nicht. Diese Anleitung habe ich eingerichtet: https://forum.netgate.com/topic/132663/solved-erläuterung-openvpn/9
Was kann ich noch prüfen? Wo ist der Unterschied? Das letzte mal hat das Outbound NAT das Problem gelöst. Aber das ist konfiguriert.
Ich habe leider keine Ansätze mehr
Falls ihr weitere Informationen braucht, gebt mir gerne Bescheid.Vielen Dank!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 388660
Url: https://administrator.de/contentid/388660
Printed on: April 19, 2024 at 09:04 o'clock
8 Comments
Latest comment
Das hat ja nix mit OVPN zu tun, denn das ist eine reine Winblows Fehlermeldung !!!
Zwei völlig unterschiedliche Baustellen....
Wenn OVPN fehlerfrei den Tunnel aufbaut (siehe OVPN Log) und du deinen Server via VPN Tunnel pingen und tracerouten kannst ist der Vorgang für das reine VPN abgeschlossen.
Das o.a. Fehlerbild ist ja ein Windows SMB only ! Hier stimmt also was mit deinem Winblows Usernamen und Passwort nicht !
Outbound NAT in einem VPN ist natürlich Blödsinn ! Dort routet man immer natürlich ohne NAT. NAT macht das ganze noch schlimmer.
Die pfSense macht auch kein NAT bei OVPN und das zu Recht !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Zwei völlig unterschiedliche Baustellen....
Wenn OVPN fehlerfrei den Tunnel aufbaut (siehe OVPN Log) und du deinen Server via VPN Tunnel pingen und tracerouten kannst ist der Vorgang für das reine VPN abgeschlossen.
Das o.a. Fehlerbild ist ja ein Windows SMB only ! Hier stimmt also was mit deinem Winblows Usernamen und Passwort nicht !
Outbound NAT in einem VPN ist natürlich Blödsinn ! Dort routet man immer natürlich ohne NAT. NAT macht das ganze noch schlimmer.
Die pfSense macht auch kein NAT bei OVPN und das zu Recht !
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
Okay wenn ich das nat aus mache, geht es nicht mehr. Wenn ich es an mache geht es nicht. Und die Zugangsdaten sind richtig. Also Netzwerk. Und da es Geräte und OS übergreifend die gleichen Ergebnisse gibt ist Windows ausgeschlossen.
wenn ich das nat aus mache, geht es nicht mehr. Wenn ich es an mache geht es nicht.
Bahnhof ? Ägypten ? ist Windows ausgeschlossen.
Das ist Unsinn, denn die Fehlermeldung ist eine reine Windows Fehlermeldung und hat mit OpenVPN nicht das geringste zu tun !!OVPN Fehler würden auch nur im OVPN Log stehen und nie so in Windows auftauchen !
NAT im VPN zu machen ist so oder so ziemlicher Blödsinn und kontraprotuktiv, weil durch die NAT Firewall damit nur einseitiger Zugang möglich ist im VPN.
Lies dir besser das o.a. Tutorial nochmal in aller Ruhe durch. Dann sehen wir weiter.
Hi,
okay ich meld mich wenn ich gelesen habe
VG
okay ich meld mich wenn ich gelesen habe
VG
Hi,
so läuft jetzt. War kein Windows-Problem. Lag an den Regeln. Ohne das NAT von Any zum OPENVPN Interface geht es immer noch nicht. Hab eigentlich nur die Regel für das von viragomann genannte Policy-Routing von übergreifend (Dort hatte ich eh nur LAN angehakt) auf das LAN-Interface gelegt.
So ganz verstehe ich das noch nicht ganz. Werde ich bei Zeiten mal Googlen.
VG
Green14
so läuft jetzt. War kein Windows-Problem. Lag an den Regeln. Ohne das NAT von Any zum OPENVPN Interface geht es immer noch nicht. Hab eigentlich nur die Regel für das von viragomann genannte Policy-Routing von übergreifend (Dort hatte ich eh nur LAN angehakt) auf das LAN-Interface gelegt.
So ganz verstehe ich das noch nicht ganz. Werde ich bei Zeiten mal Googlen.
VG
Green14
Ohne das NAT von Any zum OPENVPN Interface geht es immer noch nicht.
Das liegt daran weil du dann vermutlich vergessen hast das remote Netzwerk an den Client zu pushen, sprich also das deine OpenVPN Konfig falsch ist.Guckst du hier:
OpenVPN Server installieren auf pfSense Firewall, Mikrotik. DD-WRT oder GL.inet Router
NAT ist immer kontraproduktiv. Damit ist das Routing dann eine Einbahnstrasse, da es nur in eine Richtung geht. Desweiteren kostet es überflüssigerweise Performance durch das sinnlose Translaten der IP Adressen im Tunnel.
Besser also nochmal alles in Ruhe lesen...und verstehen !
Hi,
ich denke zu zielst auf push "route x.x.x.x x.x.x.x" ab? Das habe ich ausprobiert. Der Aufruf der url smb.hidrive.strato.com (ist aktuell die IP 85.214.3.69) wird laut Regel über das OPENVPN Gateway geroutet. bei der OpenVPN-Verbindung habe ich dann folgendes ergänzt:
(die Server-URL "openvpn.hidrive.strato.com" ist die .71)
Bei der Verbindung bekomme ich eine Adresse zugewiesen, die sich scheinbar immer in dem Netz 10.144.0.0/24 befindet. Eine Doku dazu habe ich nicht wirklich gefunden. Subnetzmaske ist dann bei Zuweisung von der Adresse 10.144.0.45 laut Log /32.
Ich habe auch folgendes ausprobiert (auch wenn es keinen Sinn macht, so wie es verstanden habe):
Ich hab auch mal den Teil gelesen: https://openvpn.net/community-resources/how-to/#scope zu 100% hab ich das nicht durchdrungen. Aber ich habe keinerlei Einfluss auf die Konfig des OPENVPN-Servers. Auch die Doku von Strato ist recht dünn und der Support verweist gerne auf die vorhandene Doku.
Letztendlich hat es damit auch nicht funktioniert.
So wie ich das verstanden habe, mache ich mit push "route x.x.x.x x.x.x.x" ja nur das zu routende Subnetz bekannt. Das heißt mein erster Versuch sollte ja eigentlich der richtige Weg sein. Wobei ich sträube mich ein wenig dagegen, eine IP fest einzutragen. Wenn die sich mal ändern sollte, muss ich die wieder anpassen.
In dem genannten Link steht dazu:
First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive
VG
Green14
ich denke zu zielst auf push "route x.x.x.x x.x.x.x" ab? Das habe ich ausprobiert. Der Aufruf der url smb.hidrive.strato.com (ist aktuell die IP 85.214.3.69) wird laut Regel über das OPENVPN Gateway geroutet. bei der OpenVPN-Verbindung habe ich dann folgendes ergänzt:
push "route 85.214.3.69 255.255.255.248" Bei der Verbindung bekomme ich eine Adresse zugewiesen, die sich scheinbar immer in dem Netz 10.144.0.0/24 befindet. Eine Doku dazu habe ich nicht wirklich gefunden. Subnetzmaske ist dann bei Zuweisung von der Adresse 10.144.0.45 laut Log /32.
Ich habe auch folgendes ausprobiert (auch wenn es keinen Sinn macht, so wie es verstanden habe):
push "route 10.144.0.0 255.255.255.0" Ich hab auch mal den Teil gelesen: https://openvpn.net/community-resources/how-to/#scope zu 100% hab ich das nicht durchdrungen. Aber ich habe keinerlei Einfluss auf die Konfig des OPENVPN-Servers. Auch die Doku von Strato ist recht dünn und der Support verweist gerne auf die vorhandene Doku.
Letztendlich hat es damit auch nicht funktioniert.
So wie ich das verstanden habe, mache ich mit push "route x.x.x.x x.x.x.x" ja nur das zu routende Subnetz bekannt. Das heißt mein erster Versuch sollte ja eigentlich der richtige Weg sein. Wobei ich sträube mich ein wenig dagegen, eine IP fest einzutragen. Wenn die sich mal ändern sollte, muss ich die wieder anpassen.
In dem genannten Link steht dazu:
First, you must advertise the 10.66.0.0/24 subnet to VPN clients as being accessible through the VPN. This can easily be done with the following server-side config file directive
push "route 10.66.0.0 255.255.255.0" VG
Green14
ch habe auch folgendes ausprobiert (auch wenn es keinen Sinn macht, so wie es verstanden habe):
Das ist in der Tat ziemlicher Blödsinn was da steht:- 1.Fehler: Die 85.214.3.69 ist eine öffentliche IP. Das kann eigentlich niemals stimmen, denn in der Regel verwendet man für den OVPN Betrieb im internen VPN Netz IMMER private RFC 1918 IP Adressen ! https://de.wikipedia.org/wiki/Private_IP-Adresse#Adressbereiche
- 2. Fehler: Die 85.214.3.69 ist eine dedizierte Hostadresse !!! Das "push route" Kommando distribuiert aber IMMER IP Netze an den Client. Bei einem /29er Prefix (Maske 255.255.255.148) wäre aber die Netzwerk Adresse die 85.214.3.64 sofern das öffentlche Netzwerk denn überhaupt stimmt was ja zu bezweifeln ist. Diese IP ist eine öffentliche vom Strato RZ in Berlin ! http://www.utrace.de/?query=85.214.3.69
bekomme ich eine Adresse zugewiesen, die sich scheinbar immer in dem Netz 10.144.0.0/24
Ist ja auch sonnenklar !Dein Konfig Statement für das interne VPN Netz in deiner OpenVPN Server Konfig lautet vermutlich:
server 10.144.0.0 255.255.255.0
Damit bekommst du logischerweise IMMER am VPN Tunneladapter eine 10.144.0.x IP Adresse. Was ja dann auch richtig ist außerdem ist das eine richtige RFC 19180 Privat IP.
Aber ich habe keinerlei Einfluss auf die Konfig des OPENVPN-Servers
Dann hast du doch auch logischerweise keinerlei Chance etwas zu verändern !!! Vergiss es, dann kannst du nichts von deinen Änderungen dort anpassen.Ist das etwa ein öffentlicher OVPN Server ?!
Vor sowas sollte man so oder so ganz vorsichtiog sein, denn bei denen bekommst du ja den Schlüssel vom betreiber. Der kennt den also und kann alle deine Daten abschnorcheln, was die auch machen.
Ferner werden diese Schlüssel an alle relevanten Sicherheitsbehörden weitergegeben. Also bei sowas sollte man immer ganz vorsichtig sein. Aber du weisst ja was du tust...?!
Letztendlich hat es damit auch nicht funktioniert.
Kein Wunder ! Wenn du konfigtechnisch keinerlei Zugang zum Server und dessen Konfig hast ist doch logisc herweise aussichtslos.Oder wie willst du ein Auto betanken wenn du den Tankdeckelschlüssel nicht hast....?!
Wobei ich sträube mich ein wenig dagegen, eine IP fest einzutragen. Wenn die sich mal ändern sollte, muss ich die wieder anpassen.
Deshalb benutzt im Server und Routing Umfeld ja logischerweise IMMER feste statische IPs !Fazit:
Ohne das "push route" Kommando auf dem Server kannst du rein nur über die interne OVPN IP Adresse auf deinen Server zugreifen. Das bedeutet das der VPN Server dann immer auch gleich Fileserver sein muss !
Auf eine ggf. vorhandene Netzwerk Infrastruktur HINTER dem VPN Server/Server kann man dann technisch unmöglich zugreifen !
Ist ja auch klar wenn man das Routing auf dem Server nicht in der Konfig anpassen kann.
