11
Ich kriege Shrew Soft VPN Manager nicht zum Laufen
Hallo
Ich bin im Besitz einer FritzBox 7490 und habe in dieser mehrere Benutzer für einen VPN Zugang hinterlegt. Da Windows 10 mit AVM wohl nicht harmoniert, wollte ich daher den VPN Manager von Shrew Soft nutzen. Den übrigen 5 Benutzern der VPN habe ich per Teamviewer die SW installiert und eingerichtet. In drei Fällen funktionierte alles sofort, bei den zwei übrigen ging es nur nachdem ich über services.msc die Dienste angepasst habe (diese waren deaktiviert und mussten neu eingestellt und gestartet werden).
Beim 6. Client will die VPN nicht funktionieren. Ich habe mehrmals versucht, die SW neu zu installieren, habe auch ältere Versionen genutzt. Shrew Soft hinterlegt hierbei keinen virtuellen Adapter im System. Wenn ich versuche, mich mit der VPN zu verbinden (alle eingegebenen Daten stimmen zu 100%), hängt er ewig bei der Verbindung herum und gibt mir dann Rückmeldung, dass er ein negotiation problem hat und dass der key daemon beendet wurde.
Ich weiß langsam nicht mehr weiter. Jegliche Treiber auf dem System sind up-to-date, Windows Updates sind ebenfalls alle auf der Maschine.
Weitere Informationen:
Windows 10 Pro 64 bit
CPU AMD 3600
GPU AMD 5700 XT
MB MSI B450 Gaming Pro Carbon AC
Netzwerk läuft über einen Chip von Intel
Vielen Dank
Ich bin im Besitz einer FritzBox 7490 und habe in dieser mehrere Benutzer für einen VPN Zugang hinterlegt. Da Windows 10 mit AVM wohl nicht harmoniert, wollte ich daher den VPN Manager von Shrew Soft nutzen. Den übrigen 5 Benutzern der VPN habe ich per Teamviewer die SW installiert und eingerichtet. In drei Fällen funktionierte alles sofort, bei den zwei übrigen ging es nur nachdem ich über services.msc die Dienste angepasst habe (diese waren deaktiviert und mussten neu eingestellt und gestartet werden).
Beim 6. Client will die VPN nicht funktionieren. Ich habe mehrmals versucht, die SW neu zu installieren, habe auch ältere Versionen genutzt. Shrew Soft hinterlegt hierbei keinen virtuellen Adapter im System. Wenn ich versuche, mich mit der VPN zu verbinden (alle eingegebenen Daten stimmen zu 100%), hängt er ewig bei der Verbindung herum und gibt mir dann Rückmeldung, dass er ein negotiation problem hat und dass der key daemon beendet wurde.
Ich weiß langsam nicht mehr weiter. Jegliche Treiber auf dem System sind up-to-date, Windows Updates sind ebenfalls alle auf der Maschine.
Weitere Informationen:
Windows 10 Pro 64 bit
CPU AMD 3600
GPU AMD 5700 XT
MB MSI B450 Gaming Pro Carbon AC
Netzwerk läuft über einen Chip von Intel
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: 565870
Url: https://administrator.de/contentid/565870
Printed on: April 26, 2024 at 15:04 o'clock
11 Comments
Latest comment
Moin,
Hat der 6. Client/Benutzer vielleicht einen Internetzugang über TV-Kabel (Kabel Deutschland, Vodafone (inkl. Unitymedia)? Dann wird das schwierig bis unmöglich. Oder auch mit einem anderen DS-Lite-Anschluss enstprechend (bspw. sind auch viele 1&1 Anschlüsse inzwischen DS-Lite).
Gruß
cykes
Hat der 6. Client/Benutzer vielleicht einen Internetzugang über TV-Kabel (Kabel Deutschland, Vodafone (inkl. Unitymedia)? Dann wird das schwierig bis unmöglich. Oder auch mit einem anderen DS-Lite-Anschluss enstprechend (bspw. sind auch viele 1&1 Anschlüsse inzwischen DS-Lite).
Gruß
cykes
Tastsächtlich ist das der Fall!
Wieso kann es hier aber zu Problemen kommen?
Wieso kann es hier aber zu Problemen kommen?
Weil der Anschluss keine öffntliche IPv4 Adresse bzw. eine shared IPv4 hat. über IPv6 kann sich der Shrewsoft nicht verbinden und insbesondere der Rückweg ist nicht möglich, also Pakete von Deinem Anschluss zurück zum VPN-Client kommen nicht durch. Die jeweiligen Kundenforen sind voll von derartigen Anfragen. Meist hilft es nur, auf ein alternatives VPN umzusteigen, bspw. OpenVPN.
Außerdem wird es Deine FritzBox sowieso überlasten, wenn sich 5 oder 6 VPN-Nutzer gleichzeig einwählen. Das packt die FritzBox nicht.
Außerdem wird es Deine FritzBox sowieso überlasten, wenn sich 5 oder 6 VPN-Nutzer gleichzeig einwählen. Das packt die FritzBox nicht.
Schau mal nach welches Verschlüsselungsprotokoll verwendet wird. IPSec IKEv1 hat bei mir am DS-Lite Anschluss nicht funktioniert, IKEv2 dagegen problemlos. FritzBox unterstützt soweit ich weiß beides.
Zitat von @jktz84:
Schau mal nach welches Verschlüsselungsprotokoll verwendet wird. IPSec IKEv1 hat bei mir am DS-Lite Anschluss nicht funktioniert, IKEv2 dagegen problemlos. FritzBox unterstützt soweit ich weiß beides.
Schau mal nach welches Verschlüsselungsprotokoll verwendet wird. IPSec IKEv1 hat bei mir am DS-Lite Anschluss nicht funktioniert, IKEv2 dagegen problemlos. FritzBox unterstützt soweit ich weiß beides.
Hallo.
Leider unterstützt die Fritzbox das nicht:
https://avm.de/service/fritzbox/fritzbox-7490/wissensdatenbank/publicati ...
Hier wäre es am sinnvollsten und simpelsten einen Raspberry Pi als OpenVPN Server ins Netz zu hängen, fertig ist die Laube. Besser natürlich eine "richtige" Firewall hinter die Fritzbox. Dort können dann wahlweise OpenVPN oder L2TP verwendet werden.
Gruß
Radiogugu
Und mit den alternativen VPN-Servern kann man dann auch IPv6 verwenden 
Zitat von @jktz84:
Schau mal nach welches Verschlüsselungsprotokoll verwendet wird. IPSec IKEv1 hat bei mir am DS-Lite Anschluss nicht funktioniert, IKEv2 dagegen problemlos. FritzBox unterstützt soweit ich weiß beides.
Schau mal nach welches Verschlüsselungsprotokoll verwendet wird. IPSec IKEv1 hat bei mir am DS-Lite Anschluss nicht funktioniert, IKEv2 dagegen problemlos. FritzBox unterstützt soweit ich weiß beides.
IKEv1 funktioniert auch an DS-Lite. Es muss nur richtig konfiguriert werden auf beiden Seiten. DS-Lite ist einfach nur eine Umschreibung für IPv4-NAT beim Provider. Bei IKEv1 muss auf beiden Seiten NAT-Traversal aktiviert werden.
Wenn IKEv1 nicht NAT-fähig wäre, würde es hinter keinem Router und auch über keine Mobilfunkverbindung laufen.
Einziger Unterschied zwischen IKEv1 und IKEv2 in Bezug auf NAT ist, dass NAT-Traversal bei IKEv1 erst später kam und nicht verpflichtend ist, während NAT-Traversal bei IKEv2 zwingender Bestandteil wurde.
Zitat von @tikayevent:
IKEv1 funktioniert auch an DS-Lite. Es muss nur richtig konfiguriert werden auf beiden Seiten. DS-Lite ist einfach nur eine Umschreibung für IPv4-NAT beim Provider. Bei IKEv1 muss auf beiden Seiten NAT-Traversal aktiviert werden.
IKEv1 funktioniert auch an DS-Lite. Es muss nur richtig konfiguriert werden auf beiden Seiten. DS-Lite ist einfach nur eine Umschreibung für IPv4-NAT beim Provider. Bei IKEv1 muss auf beiden Seiten NAT-Traversal aktiviert werden.
Kann natürlich an meiner Konfiguration gelegen haben, aber IKEv1 auch mit NAT Traversal auf beiden Seiten hat bei mir nicht funktioniert.
Unitymedia als Provider.
Da Windows 10 mit AVM wohl nicht harmoniert
Ist natürlich Quatsch. Ein Blick auf die VPN Support Seite von AVM genügt:https://avm.de/service/vpn/uebersicht/
Ganz unten: "FRITZ!Box-Fernzugang einrichten, Version 01.03.00 vom 05.12.2011, Windows 10/8/7/Vista/XP/2000" was man aber mit 🍅 auf den 👁 schon mal übersehen kann !
Aber auch mit dem Shrew klappt es sofort auf Anhieb:
https://avm.de/service/vpn/tipps-tricks/vpn-verbindung-zur-fritzbox-mit- ...
Ein DS-Lite Anschluss mit CGN bedeutet in der Regel das sofortige Aus für ein IPsec basiertes VPN. Siehe auch:
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Hier ist es taktisch klüger ein SSL basiertes VPN wie z.B. OpenVPN zu nutzen was damit besser umgehen kann !
Läuft bei mir seit 12 Jahren problemlos. Initiator congstar Mobilfunk (DS-Lite), Responder Unitymedia (DualStack, bis vor zwei Wochen IPv4).
Ich hab aber noch 60 andere VPN-Strecken, zum Teil per DS-Lite oder NAT, die problemlos laufen und auf Anhieb liefen.
Am Ende haben wir das Problem doch bei dir in der Regelerzeugung und nicht im NAT-T gefunden.
@aqui:
Und wenn du dir mal die Tags des Heise-Artikels anschaust, siehst du, dass es wohl um eingehende Verbindungen geht, da kannst du deine OpenVPN-Lösung genauso vergessen wie ein IPSec-VPN, weil CGN/NAT/DS-Lite einfach keine Möglichkeiten bietet, Verbindungen zum eigenen Anschluss aufzubauen.
Ich hab aber noch 60 andere VPN-Strecken, zum Teil per DS-Lite oder NAT, die problemlos laufen und auf Anhieb liefen.
Am Ende haben wir das Problem doch bei dir in der Regelerzeugung und nicht im NAT-T gefunden.
@aqui:
Ein DS-Lite Anschluss mit CGN bedeutet in der Regel das sofortige Aus für ein IPsec basiertes VPN. Siehe auch:
https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Hier ist es taktisch klüger ein SSL basiertes VPN wie z.B. OpenVPN zu nutzen was damit besser umgehen kann !
Ich finde es gut, dass du hier Anleitungen bereitstellst, aber diesen ständigen Bullshit, dass CGN mit IPSec nicht oder fast nicht funktioniert kannst du dir sparen und du selbst weißt es auch besser. Ob OpenVPN oder IPSec mit NAT-T ist egal. Was bringt es einem, wenn man von dir ständig hört, dass OpenVPN sooo viel besser ist, wenn die vorhandene Technik nicht da ist. Du stellst dir doch auch keinen Sprinter in die Garage, weil der mehr transportiert, während du schon einen Kombi hast, der für deine Zwecke ausreicht.https://www.heise.de/ct/ausgabe/2013-6-Internet-Dienste-trotz-DS-Lite-nu ...
Hier ist es taktisch klüger ein SSL basiertes VPN wie z.B. OpenVPN zu nutzen was damit besser umgehen kann !
Und wenn du dir mal die Tags des Heise-Artikels anschaust, siehst du, dass es wohl um eingehende Verbindungen geht, da kannst du deine OpenVPN-Lösung genauso vergessen wie ein IPSec-VPN, weil CGN/NAT/DS-Lite einfach keine Möglichkeiten bietet, Verbindungen zum eigenen Anschluss aufzubauen.
Letztlich hast du natürlich Recht, keine Frage. Es sollte auch niemals der Eindruck erweckt werden das das ein VPN Protokoll besser ist als das andere. Wäre in der Tat Bullshit.
Der Einwand oben bezieht sich IMMER lediglich auf die Tatsache das einzig der Responder !! hinter einem DS-Lite oder Provider CGN liegt und ausdrücklich NICHT der Initiator.
Beim Initiator ist es völlig Wumpe, richtig. Nicht aber beim Responder um den es auch beim ct' Artikel geht. Nur das sollte der Einwand klarstellen. Nicht mehr und nicht weniger. Sorry, wenn das falsch rübergekommen ist.
Der Einwand oben bezieht sich IMMER lediglich auf die Tatsache das einzig der Responder !! hinter einem DS-Lite oder Provider CGN liegt und ausdrücklich NICHT der Initiator.
Beim Initiator ist es völlig Wumpe, richtig. Nicht aber beim Responder um den es auch beim ct' Artikel geht. Nur das sollte der Einwand klarstellen. Nicht mehr und nicht weniger. Sorry, wenn das falsch rübergekommen ist.