Hallo,
haben auf unserer FritzBox Benutzer erstellt und VPN aktiviert.
Mit den Handys können wir uns auch damit verbinden und kommen ins Netz.
Hier haben wir als Typ:
IPSec Xauth PSK
Beim PC mit Windows 10 (und einer Windows 8) funktioniert das ganze
aber nicht.
Dazu haben wir den windows integriereten VPN-Anbietber benutzt.
Als VPN-Typ haben wir
L2TP/IPSec mit vorinstalliertem Schlüssel
Als Fehler bekommen wir
Der L2TP-Verbindungsversuch ist fehlgeschlagen, weil die
Sicherheitsschicht einen Verarbeitungsfehler festgestellt hat
woran liegt das? Bzw. was ist falsch?
hans schrieb:> Hier haben wir als Typ:> IPSec Xauth PSK
Ist eigentlich nicht mehr empfehlenswert, aber die FritzBox kann wohl
bis heute kein IKEv2.
hans schrieb:> Als VPN-Typ haben wir>> L2TP/IPSec mit vorinstalliertem Schlüssel
L2TP over IPSec ist halt kein IPSec mit XAuth, das kann nicht
funktionieren.
Gibt es nicht von AVM einen VPN-Client? Ansonsten nimm den hier, der
kann in puncto IPSec so ziemlich alles:
https://www.thegreenbow.de/vpn-client.html
Ich verwende (gerade aus dem Urlaub :)) noch: https://www.shrew.net/
funktioniert wunderbar mit ipsec.
Wenn AVM das offizielle Release 7.50 mit wireguard Unterstützung
herausbringt werde ich darauf umsteigen.
hans schrieb:> IPSec Xauth PSK> L2TP/IPSec mit vorinstalliertem Schlüssel
Naja, dass das nicht funktioniert, ist keine Überraschung. Das sind
schlicht völlig verschiedene Sachen.
Tatsache ist, dass AVM wohl unbedingt den eigenen VPN-Client auf
möglichst viele Windows-Rechner bringen will. Warum auch immer...
Die einzige funktionierende Alternative für Windows ist der (seit ewigen
Zeiten nicht mehr gepflegte) VPN-Client von Shrewsoft. Der funktioniert
allerdings immer noch sehr gut und zerstört (im Gegensatz zu dem
AVM-Client) nicht fast jede andere VPN-Verbindung durch andere Clients
allein durch sein bloße Installation.
Das VPN-Thema ist ein absolutes Armutszeugnis für AVM. War es schon
immer.
Denn Tatsache ist: die Software-Basis, auf die die aufsetzen, ist
Racoon. Und zwar in einer uralten, quasi "eingefrorenen" Version. Und
diese uralte Version kann halt vieles noch nicht. Z.B. IKEV2.
Das war schon 2010 nicht mehr sehr lustig, 2015 mutete es schon wie ein
Witz an und heute ist schlicht vollkommen inakzeptabel.
Ich habe keine Ahnung, was AVM hier spielt und mit welchem Ziel.
Techniker haben jedenfalls diese Entscheidung nicht getroffen, das waren
BWLer oder Marketingler. So viel ist mal sicher.
c-hater schrieb:> Tatsache ist, dass AVM wohl unbedingt den eigenen VPN-Client auf> möglichst viele Windows-Rechner bringen will. Warum auch immer...
IPsec ist bisheriger Branchenstandard für VPNs. Es ist Windows, das
davon abweicht. Eine Fritzbox kannst du als Gegenstelle von
Enterprise-Firewalls verwenden. Ist nur begrenzt sinnvoll, funktioniert
aber erwiesenermassen.
Version 2 davon ist nett, aber nicht zwingend.
Wirklich störend im DS lite Zeitalter ist die Beschränkung auf IPv4.
Haben beide Seiten keine IPv4-Adresse, dann geht nix.
(prx) A. K. schrieb:> IPsec ist bisheriger Branchenstandard für VPNs. Es ist Windows, das> davon abweicht.
So kann man das auch sehen. Wenn man es so sehen will...
> Eine Fritzbox kannst du als Gegenstelle von> Enterprise-Firewalls verwenden. Ist nur begrenzt sinnvoll, funktioniert> aber erwiesenermassen.
Sicher. Geht mit jedem Linux und jedem BSD. Aber ein Consumer-Produkt
sollte doch schon Rücksicht auf die Fähigkeiten und Eigenheiten der im
Consumer-Bereich mit weitaus überragender Verbreitung vorliegenden OS zu
nehmen.
> Version 2 davon ist nett, aber nicht zwingend.
Sollte es aber längst sein. Schon aus Gründen der Sicherheit. Ähnlich,
wie man heute nicht mehr auf TLS1.0 vertraut. War ja auch mal
"Standard"...
> Wirklich störend im DS lite Zeitalter ist die Beschränkung auf IPv4.> Haben beide Seiten keine IPv4-Adresse, dann geht nix.
Diese Problematik kommt dann noch dazu.
c-hater schrieb:>> Version 2 davon ist nett, aber nicht zwingend.>> Sollte es aber längst sein. Schon aus Gründen der Sicherheit. Ähnlich,> wie man heute nicht mehr auf TLS1.0 vertraut. War ja auch mal> "Standard"...
Die SSL/TLS-Levels tangieren direkt die Sicherheit, alte Versionen sind
nicht per Implementierung unsicher, sondern vom Verfahren her. Bei IPsec
gibt es Modi, die man vermeiden sollte, und unsichere Implementierungen,
aber von grundlegender Unsicherheit von IKEv1 gegenüber IKEv2 ist mir
nichts bekannt.
c-hater schrieb:> Das VPN-Thema ist ein absolutes Armutszeugnis für AVM. War es schon> immer.
Allerdings. Aber Hauptsache jeder Hansel fummelt mit sowas rum, ohne
auch nur ansatzweise zu verstehen, was er da macht. Ist mal wieder ein
schönes Beispiel hier.
Onkel Hotte schrieb:> Je nach Umgebung sind nicht unerhebliche Unterschiede vorhanden.
Natürlich hat IKEv2 Vorteile. Man hat IKEv2 ja nicht aus Jux definiert.
Es ging aber um die Behauptung, IKEv1 wäre in jenem Sinn unsicher, in
dem TLS < 1.2 unsicher ist. Es wäre also das IKEv1 Verfahren gebrochen,
bei IKEv2 aber nicht.
Hallo,
da es ja dann doch nicht so funktioniert wie gedacht, müssen wir uns
wohl was anderes Überlegen.
(Grundsätzlich geht es um den Zugriff auf einer NAS die bei mir steht)
und andere darauf zugreiffen sollen können.
Jetzt könnte man auch einen RaspberryPi anschlißen und dort OpenVPN
installieren.
Dieser muss dann ja über einer PortWeiterleitung erreichbar sein.
Dieses wollte ich eigentlich vermeiden. Daher waren wir froh, direkt das
VPN in der Fritzbox erstellen zu können.
Mit der Lösung des Raspberry Pi's habe ich noch zwei Fragen.
- Wird der Upload deswegen langsamer? Also geht alles über den Raspberry
Pi?
- Was ist der Vorteil das VPN auf dem RaspberryPi zu machen, wenn dieser
doch nur über Portweiterleitung erreicht werden kann? Dann können wir
das mit dem VPN auch ganz sein lassen?
Hans
Hans schrieb:> Jetzt könnte man auch einen RaspberryPi anschlißen und dort OpenVPN> installieren.> Dieser muss dann ja über einer PortWeiterleitung erreichbar sein.>> Dieses wollte ich eigentlich vermeiden. Daher waren wir froh, direkt das> VPN in der Fritzbox erstellen zu können.
Hmm? Grundsätzlich ist es doch egal, du exponierst damit einen
Serverdienst (VPN). Wo der läuft ist wurscht, er steht so oder so
offen im Netz.
> - Was ist der Vorteil das VPN auf dem RaspberryPi zu machen, wenn dieser> doch nur über Portweiterleitung erreicht werden kann? Dann können wir> das mit dem VPN auch ganz sein lassen?
Du wirfst hier ordentlich was durcheinander. Das VPN auf der Fritte ist
auch nur ein Stück Software, was von außen erreichbar ist.
Bitte Grundlagen aneignen und bis dahin nicht mehr an Netzwerken
fummeln. Auf diesem Level ist das Risiko groß, durch Felkonfiguration
zur Gefahr für andere zu werden.
Hans schrieb:> Mit der Lösung des Raspberry Pi's habe ich noch zwei Fragen.> - Wird der Upload deswegen langsamer? Also geht alles über den Raspberry> Pi?
Alles, was über das VPN geht, geht dann natürlich über den Raspi. Aber
aktuelle Raspi's sind locker schnell genug, alles zu verarbeiten, was
Consumer normalerweise als Internet-Bandbreite zur Verfügung haben.
Sprich: nein, da wird nix langsamer (jedenfalls nicht im Vergleich zu
einem VPN-Endpunkt auf der FB).
> - Was ist der Vorteil das VPN auf dem RaspberryPi zu machen, wenn dieser> doch nur über Portweiterleitung erreicht werden kann?
Mit dem Raspi kann man halt ein VPN aufsetzen, mit dem dann
Windows-Gegenstellen ohne jegliche zusätzlich zu installierende
VPN-Clients reden könnten...
Onkel Hotte schrieb:> Bitte Grundlagen aneignen und bis dahin nicht mehr an Netzwerken> fummeln. Auf diesem Level ist das Risiko groß, durch Felkonfiguration> zur Gefahr für andere zu werden.
ja, besser ist das
c-hater schrieb:>> - Was ist der Vorteil das VPN auf dem RaspberryPi zu machen, wenn dieser>> doch nur über Portweiterleitung erreicht werden kann?>> Mit dem Raspi kann man halt ein VPN aufsetzen, mit dem dann> Windows-Gegenstellen ohne jegliche zusätzlich zu installierende> VPN-Clients reden könnten...
Jetzt haben wir uns mal OpenVPN angesehen und testshalber auch mal
installiert.
Das funktioniert auch ganz gut (zumindest soweit wir es beurteilen
können)
Wir wollen ja nur das NAS zugänglich machen.
Mit OpenVPN kommen wir zwar von außen dran, aber auch an alles andere.
Bin letztendlich ja in meinem Netzwerk drinn.
Mit PortForwarding (was ich ja jetzt schon für den RaspberryPi gemacht
habe) würde ich nur den Port für das NAS freigeben und somit hätte man
auch nur Zugriff darauf.
VPN wäre aber sicherer, da alles verschlüsselt ist?
Oder würde ein Portforwarding ausreichen (und sicher sein?) ?
Hallo,
Hans schrieb:> Wir wollen ja nur das NAS zugänglich machen.> Mit OpenVPN kommen wir zwar von außen dran, aber auch an alles andere.> Bin letztendlich ja in meinem Netzwerk drinn.>> Mit PortForwarding (was ich ja jetzt schon für den RaspberryPi gemacht> habe) würde ich nur den Port für das NAS freigeben und somit hätte man> auch nur Zugriff darauf.
Du forwardest doch nur den OpenVPN-Port zu RasPi, weiter nichts.
Den raspi kannst Du ja so konfigurieren, das der im internen Netz nur an
das NAS rankommt.
Ein Bekannter hat das auf einem RasPi in einer kleinen Firma
eingerichtet, zur Fernwartung. Mir ist im Moment nicht bekannt, daß
OpenVPN kritische Sicherheitslücken hat. Ursprümglich lief es auf einem
RasPi 1B, irgendwann auf einem RasPi 3. Die 30MBit Upstream der
VDSL-Leitung kann der jedenfalls recht gut ausnutzen, wenn nötig. Läuft
24/7, SD-Karte ist 1x ausgefallen in den Jahren.
Gruß aus Berlin
Michael
Michael U. schrieb:> Mir ist im Moment nicht bekannt, daß> OpenVPN kritische Sicherheitslücken hat.
Ja das stimmt, im Moment sind wohl gerade keine bekannt. In der
Vergangenheit gab es aber immer wieder welche. Deutlich zu viele für
meinen Geschmack...
Michael U. schrieb:> Die 30MBit Upstream der> VDSL-Leitung kann der jedenfalls recht gut ausnutzen
Beim erwähnten RasPi 1B wäre ich da allerdings skeptisch.
Beim OpenVPN sollte man sich auf die UDP Variante konzentrieren. Das
kann nämlich auch TCP, aber VPN über TCP, damit also TCP über TCP, ist
mitunter problematisch.
Eine Weisheit, die sich Mikrotik leider nicht erschloss. Deren OpenVPN
kann nur TCP.
(prx) A. K. schrieb:> Beim OpenVPN sollte man sich auf die UDP Variante konzentrieren. Das> kann nämlich auch TCP, aber VPN über TCP, damit also TCP über TCP, ist> mitunter problematisch
In den meisten Hotel WLANs hab ich mit UDP und dann auch noch dem
Standard OpenVPN Port massiv Probleme gehabt, das war fast immer
irgendwie geblockt. Seitdem benutze ich nur noch TCP und Port 500 und
damit klappt das bisher wunderbar (Android, Tasker, OpenVPN).
Christian R. schrieb:> das war fast immer irgendwie geblockt.
Das ist dann natürlich ein anderer Aspekt. Ich bezog mich auf das
problematische TCP-over-TCP generell. Das kann bei bei manchen
Randbedingungen zu Retry-Eskalation und Verstopfung führen.
Christian R. schrieb:> In den meisten Hotel WLANs hab ich mit UDP und dann auch noch dem> Standard OpenVPN Port massiv Probleme gehabt
Es kommt wohl tatsächlich immer noch vor, dass in den Netzen von
Hotels/Resorts "VPN" geblockt wird, das hat aber nach meiner Beobachtung
im Laufe der letzten zwei Jahrzehnte doch erheblich nachgelassen.
Für diese Spezialfälle hält man halt ein (per Port-Knocking
aufzuweckendes) Notfall-VPN-Gateway auf 443 TCP in Reserve. Das können
sie nicht so wirklich gut blocken ;o)
Wirklich gebraucht habe ich es das letzte Mal 2013, wenn ich mich
richtig erinnere.
