Shrewsoft Problem

Moin,

du musst bedenken, dass die Windows Firewall standardmäßig ICMP-Pakete (Ping) aus anderen Subnetzen blockiert.
Das kannst Du aber konfigurieren.

Trommel

Moin,

evtl. wird das virtuelle Interface vom NLA auf public definiert und blockiert alles was rein will und auch einiges das raus will.
Mal geschaut, welches Netzwerkprofil verwendet wird? Wenn public mal auf private setzen.

Durch die Windows interne Netz Autodetection kann es passieren, dass die Firewall den virtuellen Adapter als External deklariert, weil das Gateway Discovery fehlschlägt.

sonst mal in der cmd als admin ausführen:
netsh int ip reset


Auch mal "route print" überprüft, ob die Routen von der Software hinterlegt sind?

VG

Liegt vielleicht einfach daran, dass der Kram seit 10 Jahren (ZEHN!) nicht mehr supported wird?! Mir ein Rätsel wer sich sowas als "Sicherheitssoftware" installiert und warum AVM den Plunder nicht einfach aufgekauft hat, wenn sie es schon nicht schaffen das 80% BS weltweit "originär" zu unterstützen.

Die 7490 hat eigentlich das aktuelle Update erhalten und kann damit auch Wireguard.

Mahlzeit
Was wird seit 10 Jahren nicht mehr supported?
Meinst du etwa, dass es seit langer Zeit keine Updates für den Shrew-Clienten gab?
Der ist auskonfiguriert, beherrscht zwar nur IKEv1, das aber gut.
Wo ist dein Problem?

Ich habe ca. 20-30 verschiedene Client-VPNs mit dem Shrew Client auf dem Notebook installiert.
Wichtig ist vor allem, dass man weiß, was man tut.

IPSEC VPN mit IKEv1 kann sie aber auch und Wireguard ist bspw. in Windows auch nicht dabei, sondern es muss ein Client installiert werden.

Was? Seit Windows 8 austherapiert?!

Das geht dann wohl an den TE

Jupp, da ist aber der (aktuellste) WIN-Client erst 5 Monate jung, Opensource von ner Community und nicht von ner Postfach-Adresse irgendwo in Texas, die seit 2013 zwar ihren Shop laufen lässt ... aber nicht mal die Homepage updated

Aber natürlich! Jeder wie er glücklich wird. Und mit Windows 11 ist das Thema augenscheinlich eh durch.

Nein, Kollege @goscho meint das der IKEv1 Standard seit Jahren ausentwickelt ist und damit der Shrew Client auch. Warum sollte es also dafür noch Updates geben wenn er seit Jahren mit dem Standard nachweislich fehlerfrei und ohne Bugs rennt.
Der TO ist vermutlich Opfer die Winblows Firewall die, wie oben schon gesagt, ICMP (Ping) per Default blockt.
https://www.windowspro.de/wolfgang-sommergut/ping-windows-10-erlauben-gu ...

Die 7490 supportet ja auch Firmware 7.5 so das der TO zur Not eine Alternative mit Wireguard hat.

Also ich bin ganz @Visucius, dass der ShrewSoft Client, der nur IKEv1 kann, eigentlich längst nicht mehr dem aktuellen Stand der Technik entspricht. Ich betrachte es gleichfalls skeptisch, dass es in den letzten zehn oder wohl sogar noch mehr Jahren keinen Anpassungsbedarf gegeben haben soll. Das wäre wohl ein absolutes Novum - eher ist aber anzunehmen, dass der Anbieter das Interesse an einer Fortentwicklung verloren hat, weil beispielsweise - worauf @aqui ja immer wieder hinweist - mittlerweile die relevanten Endpoint-Betriebssysteme entweder taugliche VPN-Clients mitbringen oder auch freie Angebote verfügbar sind, die eben IKEv2 beherrschen. Um 2010 bis 2013 sah das alles noch ganz anders aus.

Jedoch hat auch @aqui völlig Recht: Dieser Client rennt (hier) nach ordnungsgemäßer Konfiguration (mit einer FortiGate als VPN-Gateway) völlig unauffällig und das auf Basis von Windows 8.1 seit etwa zehn Jahren (lange wird diese Windows-Kiste jetzt aber nicht mehr leben ... ). Auf einer neueren Windows-Version würde ich diesen Client dann doch nicht mehr einsetzen, sondern mich nach einem zeitgemäßen VPN-Client umsehen. Eine alternative Option neben dem bordeigenen Client wäre beispielsweise für IPSec der Client von StrongSwan ...

Viele Grüße
HansDampf06

Gerne doch 😉

Dann kannst du das sicherlich auch belegen.

Ein mit dem Shrew-Client und einer aktuellen Gegenstelle (bei mir sehr häufig Lancom Router) konfiguriertes Einwahl-VPN entspricht sehr wohl den aktuellen Anforderungen an die Sicherheit für VPNs.
Wichtig für die Sicherheit ist bei IKEv1 vor allem ein langes, sicheres Passwort (Pre-Shared Key).

Ich habe just heute 2 Windows 11 Pro Notebooks eines Kunden eingerichtet.
Auf beide wurde der Shrew 2.2.2 installiert und jeweils eine eigene Einwahlkonfiguration zur Firma (neuer Lancom 1790) erstellt. Diese Konfigurationen konnte ich weitersgehend von einer anderen kopieren und habe den PSK und den Identifier individualisiert. Fertig.

Welcher IKEv1 Client entspricht denn deiner Meinung nach dem Stand der Technik?? Diese Frage hast du leider nicht beantwortet. Wohlgemerkt IKEv1!
Stand der Technik ist ja IKEv2 und so einen Client haben ALLE Betriebssysteme, Smartphones, Tablets usw. von sich aus ja an Bord so das es gar keinen extra Client erfordert.
Das Problem ist nicht Shrew sondern das die FritzBox nur IKEv1 kann. Denn was bitte sollte man bei IKEv1 denn noch "fortentwickeln" wenn der Standard ausentwickelt ist?! Bliebe höchstens die Farbwahl der Fenster...
Insofern ist die Formulierung in Bezug auf den Shrew etwas sinnfrei bzw. eine Verdrehung der Ursachen.
Der Shrew Client funktioniert fehlerlos mit Win10 und 11 wie Kollege @goscho schon sagt!
Gibt es aber leider nicht für Winblows.

Also mal ganz ehrlich: Bei IKE gibt es für die Version 1 seit mindestens 2010 als Nachfolger die Version 2, vgl. Datum der RFC 5996 (später ersetzt durch RFC 7296). Wann / warum wird für ein technisches Verfahren eine neue Version in Standardregeln spezifiziert? Richtig, weil es einen Bedarf dafür gab/gib, die ursprüngliche Version anzupassen / zu verbessern / zu ersetzen / zu ... Wer sich beispielhaft den Punkt "Unterschied zwischen IKEv1 und IKEv2" im deutschen Wikipedia-Artikel zu IPSec auf der Zunge zergehen lässt, braucht keine wirkliche weitere Erläuterung, warum IKEv1 in diesem Sinne nicht mehr dem Stand der Technik entspricht: Es hatte unter anderem Problemlagen, die mit der IKEv2 behoben werden sollen. IKEv2 ist laut RFC 5996 nicht abwärtskompatibel.

Im Übrigen darf der Begriff "Stand der Technik" nicht damit verwechselt werden, ob etwas weiterhin technisch (be)nutzbar ist. Oder will vielleicht jemand ernsthaft behaupten wollen, dass ein weiterhin benutzbarer (originalgetreuer) Oldtimer-Pkw aus den 50er Jahren heute noch dem Stand der Technik bei der Herstellung eines neuen Pkw entspricht? Wohl kaum! Der ADAC formuliert das am 27. November 2019 ganz pragmatisch: "Zwischen dem heutigen Stand der Technik und dem in den 30er-, 50er-, 80er-Jahren liegen Welten." Dem ist nichts hinzuzufügen! Man denke dabei nur an die später erst vorgeschriebenen Sicherheitsanforderungen wie dem Dreipunktgurt. Dass ein solch alter Pkw technisch noch (be)nutzbar ist, liegt schlicht daran, dass er einmalig bei seiner Erstzulassung den damaligen Zulassungsanforderungen entsprach und seither einen gewissen Bestandsschutz genießt. Immerhin: Obschon ein solch alter Pkw eigentlich nicht die Voraussetzungen für das Befahren einer gekennzeichneten Umweltzone erfüllt, ist das dennoch (nur) zulässig, weil es eine explizite Ausnahmeregelung gibt.

Freilich ist diese Pkw-Betrachtung nicht Eins-zu-Eins auf das Verhältnis von IKEv1 und IKEv2 übertragbar, obschon IKEv1 zweifelsohne der Oldtimer ist. Aber diese Betrachtung macht es anhand von für jedermann zugänglichen allgemeinen Erfahrungen aus der Alltagswelt bildhaft verständlich, worin der feine Unterschied zwischen "Stand der Technik" und fortbestehender "technischer Benutzbarkeit" liegt.

Gleichsam kann auch nicht aus dem Umstand, dass es AVM auf seinen Routern seit nunmehr sehr vielen Jahren nicht zu schaffen scheint, IKEv2 zu implementieren, abgeleitet werden, das wäre noch der Stand der Technik.

Conclusio: Wer mir also nahelegen möchte, dass IKEv1 über seine technische Benutzbarkeit hinaus sogar noch dem heutigen Stand der Technik entsprechen würde, mag unter anderem nachvollziehbar darlegen, dass es die im genannten Wikipedia-Artikel genannten Probleme bei IKEv1 schlicht nicht geben würde. Denn nur dann würde sich IKEv2, das ja angetreten sein soll, um diese Probleme zu beheben, nicht als Nachfolger, sondern als eine Technik darstellen, die "bloß" neben IKEv1 getreten wäre und die Aktualität von IKEv1 nicht berühren würde. Viel Erfolg!

Auch das vermag über die bloße technische Benutzbarkeit hinaus nicht zu belegen, dass IKEv1 trotz seines Nachfolgers IKEv2 dem heutigen Stand der Technik entspricht. Gestützt auf die RFC-Dokumente dürfte RFC 7296 den Stand der Technik bei dem IKE-Verfahren definieren. IKEv1 findet darin aber keine praktische Berücksichtigung. Was das in Bezug auf den Stand der Technik bedeutet, muss ich wohl nicht wirklich erläutern müssen.

Wunderbar für Dich und Deine Kundschaft! Aber dennoch ist ein weiteres loses Beispiel der technischen Benutzbarkeit. Mit einem Beleg für den aktuellen Stand der Technik hat das weiterhin nichts zu tun.
Oder anders formuliert: Es könnte sein, wenn ich etwas krame, dass ich noch eine 1,44''-Diskette finden und damit DR-DOS aus dem Anfang der 1990er installieren könnte. Hat eine solche Installation dann etwas mit dem heutigen Stand der Technik oder wiederum nur etwas mit der fortbestehenden technischen Benutzbarkeit zu tun? Gerne kann das auch für die EOL-Versionen von Windows durchgespielt werden.

Das steht gar nicht zur Diskussion und mag auch so sein - auch hier funktioniert der Client anstandslos. Dennoch erhebt es das betagte IKEv1 nicht zum heutigen Stand der Technik.

Für die Zweifler verweise ich nochmals auf Wikipedia: "Stand der Technik ist eine Technikklausel, die in verschiedenen Rechtsgebieten Verwendung findet. Man versteht darunter den bekannten technischen Entwicklungsstand und die darauf basierenden technischen Möglichkeiten zur Erreichung eines bestimmten praktischen Ziels." Auch insoweit ist IKEv2 nach den genannten RFC-Dokumenten zweifelsfrei der bekannte technische Entwicklungsstand, in welchem IKEv1 eben nicht vorkommt.

Dann habe ich das wohl irrtümlich mit der Version für Android verwechselt. Unter Debian läuft der Client jedenfalls klaglos und beanstandungsfrei.

Viele Grüße
HansDampf06

@HansDampf06

Du hättest dir deinen superlangen nichtssagenden Text schenken können und einfach einen Nachweis bringen sollen, dass IKEv1 nicht mehr als sicher angesehen wird und daher nicht mehr verwendet werden sollte.

Es steht überall nur was davon, dass IKEv2 die Weiterentwicklung von IKEv1 ist, was niemand abgestritten hat.

Das ändert aber nichts daran, wass VPNs mit IKEv1 weiterhin als sicher angesehen werden und wenn das irgendwann mal nicht mehr der Fall sein sollte, wird es halt aussortiert, auch von mir.

Du lenkst vom Thema bzw. der relevanten Frage ab: Entspricht IKEv1 dem aktuellen Stand der Technik?
Dein Herumreiten auf dem (Teil)Aspekt der Sicherheit belegt Deinen verkürzten Blick auf diese Fragestellung. Nur, weil etwas noch als sicher angesehen werden kann, heißt das noch lange nicht, dass es dem heutigen Stand der Technik entspricht. Hier verwechselst Du weiterhin den Begriff "Stand der Technik" mit der fortbestehenden technischen Benutzbarkeit. Die Frage der Sicherheit mag bei der Betrachtung der Benutzbarkeit gewiss eine Rolle spielen. Aber auch ein geknacktes oder unsicheres Verfahren kann dem "bekannten technischen Entwicklungsstand" und somit dem heutigen Stand der Technik entsprechen.

Überdies lenkst Du davon ab, dass Du es warst, der meine Aussage, wonach IKEv1 nicht mehr dem Stand der Technik entspricht, bezweifelt hat. Im Lichte der von mir explizit benannten RFC-Dokumente, wonach IKEv2 dem bekannten technischen Entwicklungsstand entspricht, bin also nicht ich in der Pflicht, irgendetwas zu belegen, sondern Du. Du bist nach wie vor jeglichen greifbaren Ansatz schuldig, wonach IKEv1 entgegen den RFC-Dokumenten dem bekannten technischen Entwicklungsstand entsprechen würde. Stattdessen hantierst Du immer nur mit dem belanglosen Argument, es sei doch sicher, was Dir in Bezug auf den bekannten technischen Entwicklungsstand keineswegs weiterhilft.

Conclusio: Vielleicht liegt es nicht daran, dass es sich um einen nichtssagenden Text handeln könnte, sondern vielmehr daran, dass Du Dir seinen Inhalt mit seinen wesentlichen Aussagen noch gar nicht erschlossen hast. Es könnte aber auch sein, dass Du davon ablenken möchtest, dass Du IKEv1 suggestiv als zum Stand der Technik gehörend hinstellen wolltest und dass Du Dich damit im Lichte der RFC-Dokumente ziemlich verrannt hast. Dann muss natürlich ein fundierter Text, der Dich auf die Zusammenhänge hinweist, mit unsachlichen Titulierungen diskreditiert werden ... Nur da bist Du bei mir eben an der falschen Adresse.

Der Rest Deines Kommentars bedarf demgemäß keiner Replik.

Viele Grüße
HansDampf06

Leute, es ist Wetter! Springt (auch mal) in den See und dann stellt Ihr ebenso fest, dass dieses Rumgereite auf dem Kram doch völliger Irrsinn ist.

@goscho: Du bist glücklich, Deine Kunden sind happy. Alles fein! Dann fühle Dich auch nicht in Deiner Ehre gekränkt wenn andere das anders sehen!

@HansDampf06: Sehe das wie Du, muss aber nicht in voller Tiefe diskutiert werden. Wer es sehen will, der versteht es umd der Rest soll das machen wie es bei ihm funktioniert.

@jensgebken: Hat seine Lösung und war deutlich einfacher, schneller, zeitgemäßer und am Ende verm. auch performanter als der „alte, kalte Schei##“ 😉

Fakt ist auch das IKEv1 noch auf einer Menge an Hardware zum Einsatz kommt und man so mehr oder minder gezungen ist es zu verwenden weil es an der v2 Option mangelt. Siehe Fritzbox, obwohl die als billiges Consumer Produkt sicher hier nicht beispielhaft ist.
Dennoch gilt auch IKEv1 mit den entsprechenden Schlüsselverfahren derzeit als sicher. Das es nicht Stand der Technik ist, ist schlicht falsch formuliert oder geschlussfolgert.
Du würdest ja auch nicht hingehen und postulieren das TCP nicht mehr Stand der Technik ist nur weil es QUIC gibt. Gut, QUIC hat deutliche Vorteile aber TCP wickelt derzeit einen Großteil des aktuellen Netzwerk Traffics ab.
Analog verhält es sich mit IKEv1 und IKEv2. Schon allein deshalb hinkt auch dein Auto Vergleich weil du gleich in die Extreme gegangen bist, was sachlich einfach falsch ist. Realistischer wäre ein Vergleich eines 2022er Models mit einem 2000er. Aber, egal...ist ja mit dem Schlussworten des Kollegen @Visucius nun auch alles gesagt zu der Thematik.