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
Die Fritz!Box kann in der aktuelle Labor Wireguard. Kann ich nur empfehlen.
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.
:
Bearbeitet durch User
(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.
(prx) A. K. schrieb: > von grundlegender Unsicherheit von IKEv1 gegenüber IKEv2 ist mir > nichts bekannt. Je nach Umgebung sind nicht unerhebliche Unterschiede vorhanden. Gute Zusammenfassung: https://www.sonicwall.com/support/knowledge-base/advantages-of-ikev2-over-ikev1/200522013819240/
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.
:
Bearbeitet durch User
Beitrag #7128272 wurde von einem Moderator gelöscht.
c-hater schrieb im Beitrag #7128272:
> Das ist schlecht. Ganz sicher für dich...
Dann wäre es recht hilfreich, wenn du mich drauf stupsen würdest.
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.
:
Bearbeitet durch User
(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).
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.