[Gelöst] Fritz VPN über Shrew funktioniert nicht

[Timer7734]

Hey,
ich habe vor ein paar Tagen bei meiner FritzBox ein VPN eingerichtet. Da ich eigentlich Shrew nutzen wollte/will, habe ich diese Anleitung verwendet. Beim ersten connecten hat es auch ohne Probleme funktioniert.

Beim zweiten Mal hat die Verbindung leider nicht mehr funktioniert.
Bei Shrew wurde als letztes "tunnel enabled" angezeigt, jedoch konnte ich keine Geräte im VPN anpingen/erreichen und nur wenige Webseiten im Internet anpingen/aufrufen.
Es wurde dann bei Shrew unter Network --> Failed die Zahl immer höher (alle paar Sekunden kam ein neuer fail dazu). Nach etwas suchen, habe ich auch eine Lösung gefunden, die funktioniert hat.
Ich habe dafür unter "Phase 1" und "Phase 2" einige Einstellungen geändert.
Daraufhin war ich mehrere Stunden ohne Probleme im VPN.

Am nächsten Tag hat die Lösung schon wieder nicht mehr funktioniert.
Auch diesmal wird als letzte Meldung bei Shrew "tunnel enabled" angezeigt. Ich kann jedoch (wieder) keine Geräte im VPN anpingen/erreichen und nur wenige Webseiten im Internet anpingen/aufrufen. Das lokale Netzwerk ist noch ohne Probleme erreichbar.
Ich habe inzwischen so gut wie alle Einstellungen ausprobiert, die ich im Internet finden konnte. Leider hat nichts mehr etwas gebracht.
Auf dem Handy funktioniert der VPN immer ohne Probleme.
Ich kann gerade fast nichts an der FritzBox ändern, da ich (leider) die Option zum Bestätigen aktiviert habe und gerade (und auch für die nächsten 7 Tage) ca. 200 km entfernt bin.

Ich wäre sehr dankbar, wenn mir jemand helfen kann, da ich wegen dem Problem nicht auf meine Dateien in meinem Heimnetzwerk zugreifen kann, die ich benötige.

Was eventuell etwas damit zu tun haben könnte: ich benutze einen Firmenlaptop, den ich privat benutzen darf. Auf diesem sind verschiedene Programme installiert (Citrix Gateway, Cisco AnyConnect, Sophos SafeGuard), die eventuell Fehler verursachen könnten.


Grüße
Timo

 

[PeterPawn]

Im Moment kann ich da auch nicht helfen ... ich wollte vor ca. 1 Woche auch "mal schnell" ein W10 mit dem ShrewSoft-Client mit einer 6660 verbinden (07.21, die 07.22 kam erst danach raus) und das klappte auch nicht auf Anhieb. Daher habe ich das auf morgen geschoben ... das heißt dann auch, daß ich morgen nachmittag genau dieses Thema (W10, ShrewSoft-Client, 07.2x mit der neuen VPN-Implementierung von AVM) vor der Brust haben werde und das bis zum Abend (da bin ich erst mal optimistisch) dann auch gelöst haben sollte.

Ich hatte beim letzten Mal keine Zeit mehr und ohnehin eine komische Konstellation, wo noch alle möglichen anderen Probleme auftreten könnten. Ich war per Teamviewer auf einen W10-Laptop, der über ein iPhone als Hotspot ins Internet kam (auf der Box im GUI sogar mit einer IPv6-Adresse aus dem WAN ankam) und jetzt mit der neu eingerichteten FRITZ!Box 6660 per VPN verbunden werden sollte (deshalb auch der iPhone-Hotspot, weil es aus dem WLAN der Box natürlich nicht funktionieren kann).

Aber bei dem, was ich da dann bei den ersten Kontrollen sah (in der Support-Datei, weil die Box auch wirklich ein originales FRITZ!OS ohne Modifikationen hat), würde ich morgen als Erstes mal nachsehen, ob die NAT-Erkennung tatsächlich funktioniert (der ShrewSoft-Client stand iirc auf "automatisch") oder ob ich die besser auf "forced" stelle (wie die Option jetzt genau heißt, weiß ich aus dem Kopf nicht - und vor morgen nachmittag befasse ich mich damit auch nicht näher).

Wenn es bei Dir eine ähnliche Konstellation sein sollte (der PC hängt im WLAN eines Routers, der an ihn eine private IP-Adresse ausgegeben hat), würde ich also auch an Deiner Stelle als Allererstes dort noch einmal nachsehen ... zumindest wäre es noch plausibel, daß die in #1 beschriebenen Symptome auftreten, wenn sich beide Seiten (beim "Start" so einer VPN-Verbindung) nicht darauf einigen können, ob da nun NAT-Traversal notwendig ist und damit natürlich auch, welcher UDP-Port für Phase1 genutzt wird (500 bei "direkter Sicht" oder 4500, wenn da ein NAT im Pfad zwischen den beiden Peers ist). Da kann ein "kleiner Schubser" dann schon helfen ... ist aber - wie geschrieben - auch nur die erste Stelle, an der ich bei der Fehlersuche ansetzen würde.

Wer sich ein wenig mit IPSec (mit IKEv1) auskennt, kann auch den Debug-Modus im ShrewSoft-Client benutzen (der ist einfacher zu verwenden, als immer über die Fernwartung in die Support-Datei der FRITZ!Box zu schauen, auch wenn das sicherlich früher oder später unumgänglich wird) - dafür gibt es (wieder nur aus dem Kopf) da einen speziellen "Log-Viewer", mit dem man auch die Geschwätzigkeit der Komponenten (sogar einzeln, iirc) einstellen kann.

Wenn Du auch mit einem Smartphone als Hotspot ins Internet gehst (oder mit wechselnden WLANs in Hotels, wg. Dienstreisen oder Urlaub), kann es eben auch sein, daß da erst mal nur IPv6 gesprochen wird und IPv4 nur über ein "Carrier Grade NAT" (das würde auch bei DS-Lite für den AFTR-Server zutreffen) erreichbar ist. Da können dann wieder ganz andere Probleme auftreten ... daher sollte man hier die MTU (wenn's die Einstellung gibt, was ich aus dem Kopf auch nicht mehr weiß) auch besser runterschrauben (so ca. auf 1200 Byte), damit noch genug Raum für die diversen "Verpackungen" bleibt, ohne daß die Pakete zusätzlich fragmentiert werden müssen. So eine Konstellation (wo dann die Infrastruktur zwischen PC und FRITZ!Box wechselt, weil man sich irgendwoanders einwählt) wäre natürlich auch eine Erklärung, warum es mal klappt und mal nicht. Zum Ermitteln der eigenen Anbindung gibt es ja genug Internet-Seiten, die einem da Auskunft geben können.

Das sind nur ein paar Tipps, was Du zunächst mal erkunden/ausschließen könntest ... weiß man, woher die Probleme kommen, kann man meist sogar dann gegensteuern, wenn es wirklich ein IPv6-/IPv4-Problem ist. AVM hat zwar das VPN neu implementiert, aber m.W. noch keinen IPv6-Support (als Transportprotokoll) eingebaut (oder man hat vergessen, das an die ganz große Glocke zu hängen, wo das dann tatsächlich hingehören würde).

Ich will mal ganz stark hoffen, daß Du für den PC auch einen eigenen Benutzer verwendest ... wenn ich etwas von:

Auf dem Handy funktioniert der VPN immer ohne Probleme.

lese, fällt mir das auch sofort wieder ein - und da es die AVM-Anleitung leider nicht ausdrücklich erwähnt, ist eben auch das eine gerne genommene Fehlerquelle, wo sich dann das Smartphone und der PC immer schön darum streiten, wer denn jetzt gerade die VPN-Verbindung als Letzter neu aufgebaut hat.

Andererseits solltest Du ja auch mit dem Smartphone auf Deine Daten zugreifen können (und über das Smartphone auch mit dem PC), wenn das eine VPN-Verbindung aufbauen kann (das dann vermutlich auch wieder über seine Mobilfunk-Verbindung arbeitet und nicht über dasselbe WLAN wie der PC?).

 

[Timer7734]

@PeterPawn
Leider muss ich momentan ab und zu die VPN Verbindung auch auf dem Handy verwenden. Da ich das vorher nicht eingeplant hatte, habe ich nur eine VPN Verbindung in der Fritzbox konfiguriert.
Du hast mich jedoch auf eine Idee gebracht: ich habe mich mit meinem Handy verbunden und dann in der FritzBox nachgeschuat, welche Einstellungen das Handy zum Verbinden benutzt (im Log). Diese habe ich dann genauso auch bei Shrew eingetragen. Eigentlich (dachte ich zumindest) hatte ich schon mal die gleichen Werte zuvor ausprobiert. Jetzt klappt es jedoch bisher ohne Probleme. Hoffentlich ändert sich daran in den nächsten Tagen nichts daran
Danke für die vielen Tipps

 

[PeterPawn]

Ich konnte auch nur feststellen, daß es mit der von mir beschriebenen Konfiguration (W10, 6660 mit 07.22 und ShrewSoft-Client) dann doch - wie sonst auch - funktioniert.

MTU auf 1200 heruntergesetzt (im Client, falls da auch mal ein DS-Lite-Anschluß dabei ist, wenn der Laptop unterwegs irgendwo eingesetzt werden soll), NAT-T auf "forced-rfc" (weil der PC gar keinen eigenen "Internet-Zugang" hat und damit höchstwahrscheinlich ohnehin immer hinter einem NAT-Router zu finden ist) und bei der "DH group" für Phase1 dann doch nur die 1024-Bit-Variante (Group 2) - und dann klappt(e) es auch mit dem Nachbarn.

Bei der DH-Group war ich etwas zu optimistisch, weil AVM irgendwo mal etwas geschrieben hatte, daß 5, 14 und 15 jetzt auch unterstützt würden - das stimmt zwar vermutlich auch, aber eben nicht in den vorgegebenen Proposal-Sets, die bei der Einrichtung einer VPN-Verbindung (conntype_user) über das GUI ausgewählt werden, sondern nur mit "handgemachten Konfigurationen", die andere Sets auswählen.

Damit bleibt's bei 128 Byte für die (EDH-)Schlüssellänge beim IKE - alles darüber wird von der FRITZ!Box (wie gesagt, die aktuelle AVM-Implementierung in der 07.22) mit NO_PROPOSAL_CHOSEN abgelehnt, solange in der VPN-Konfiguration für den Benutzer "LT8h/all/all/all" für P1 hinterlegt ist.

PFS (für P2) funktioniert nach früheren Tests ohnehin nicht, wenn es sich um eine "conntype_user"-Verbindung handelt - ob das mit der neuen Implementierung anders wäre (wenn man die Konfiguration in der Box von Hand ändert, denn der Standard für P2 ist da "LT8h/esp-all-all/ah-none/comp-all/no-pfs"), habe ich gar nicht erst getestet, weil es mir hier weniger um die generellen Möglichkeiten und Probleme des AVM-VPN ging, sondern nur um eine funktionierende Verbindung.

Da die zu schützenden Daten nun auch nicht sooo wichtig waren/sind (es geht in erster Linie um Phoner als SIP-Client über VPN), habe ich noch die Verschlüsselung auf halbwegs passable Werte festgetackert (AES-128/SHA1 für P1 und auch für P2), was dann auch den Ressourcenverbrauch für die "Nutzdaten" begrenzt, wenn in P2 nur AES-128 ausgehandelt werden kann.

Dann noch schnell ein Batch-File für den Start der VPN-Verbindung angelegt (in einem EFS-Verzeichnis für den Benutzer, damit man das VPN-Kennwort mit halbwegs gutem Gewissen auch direkt beim Aufruf übergeben kann) und eine Verknüpfung zu dieser Datei auf den Desktop gelegt ... fertig war die Laube.

Der Benutzer in der FRITZ!Box ist natürlich auch einer, der ausschließlich für diese VPN-Verbindung eingerichtet wurde, der hat keine weiteren Rechte und 32 Zeichen Zufall als Kennwort, so daß auch ein Passwort-Leak höchstens den Weg bis ins LAN, aber nicht auf andere Geräte eröffnet. Aber genau diese 32 Zeichen Zufall machen es erforderlich (wenn man will, daß das auch genutzt wird), daß man den Start der VPN-Verbindung so automatisiert, daß diese 32 Zeichen nicht von Hand eingegeben werden müssen.

Eine Batch-Datei in einem Verzeichnis, für das die EFS-Verschlüsselung aktiviert wurde, ist da schon eine gangbare Lösung, denn der Zugriff auf die Batch-Datei ist damit unmittelbar an den Zugang zum Windows-Konto gekoppelt - die Sicherheit der Windows-Anmeldung ist also ausschlaggebend für die Sicherheit (bzw. die Vertraulichkeit) des VPN-Kennworts.

Fazit zum VPN: AVM hat also sicherlich viel intern umgestellt, was das VPN anbelangt ... dabei aber die Kompatibilität mit der alten Version vermutlich in den Vordergrund gestellt und so klappt das, was ich bisher getestet habe, auch mit der 07.2x noch so, wie zuvor. Die ganzen neuen Features (u.a. VPN nur für bestimmte Clients), habe ich noch nicht ausreichend getestet, um da eine (fundierte) Meinung zu haben.

======================================================================================

Und noch einmal von mir der Hinweis, daß man die 2FA in der Box gar nicht deaktivieren muß/sollte (ab 07.2x) - viel sinnvoller ist es hier, die 2FA über TOTP für den Benutzer zu aktivieren (was bei AVM dann unter "Google Authenticator" firmiert) ... auch wenn der dazu das Recht zur Anmeldung aus dem Internet braucht (die aktivierte 2FA ist hier ja offenbar ein Problem nach #1, daher greife ich das noch einmal auf). Außerdem reicht es wohl aus, wenn man dem Benutzer das Recht zur Anmeldung aus dem Internet einräumt - man muß nicht parallel noch den HTTPS-Zugriff aus dem WAN aktivieren und ohne diesen, ist dieses Recht nur schwer wahrzunehmen - auch durch einen potentiellen Angreifer. Der Benutzer für den Zugriff auf die FRITZ!Box sollte dann trotzdem ein anderer sein, als der für die VPN-Verbindung-

Vielleicht schafft es AVM ja doch noch, TOTP auch für Benutzer aktivieren zu lassen, die sich nur intern anmelden dürfen (kostet ja nichts zusätzlich, wenn man zur TOTP-App greift, anstatt zum DECT-Telefon (IP geht ja nicht) zu greifen oder zur FRITZ!Box zu latschen, um eine Taste zu drücken) - und wenn man bei der Gelegenheit dann auch noch den 2FA-Dialog anhand der Einstellungen des angemeldeten Benutzers etwas "optimiert" in der Aufteilung, steht irgendwann vielleicht das Feld für die Code-Eingabe sogar direkt in der angezeigten Maske neben irgendwelchen "Codes" für die telefonische Aktivierung und man muß nicht immer erst nach den "anderen Möglichkeiten" suchen, um an das Eingabefeld zu gelangen.

 

[Tippfehler]

Ich hatte mit Shrewsoft Probleme, wenn der Windows-Rechner mehrere IPs aus verschiedenen Bereichen hat. z.B. bei Virtualisierung
Wenn mal wieder kein Gerät im fremden Netz erreichbar ist, stelle ich die Windows-Netzwerkkarte auf DHCP um, dann geht es wieder.

 

[PeterPawn]

Dieser Client bietet ja verschiedene Wege der Integration ins (lokale) Netz des Rechners an: https://www.shrew.net/static/help-2...dministrators Guide.html?GeneralSettings.html und die FRITZ!Box offeriert eine Konfiguration über die Cisco-Erweiterungen beim IKEv1.

Dabei scheint zwar die Netzwerk-Maske nicht zu passen (eine entsprechende Fehlermeldung habe ich jedenfalls im Trace-Log des Clients bei Stufe "debug" für die IKE-Komponente gesehen, wo dann auch etwas von "255.255.255.0" als letztlich genutzter Wert stand und der paßt ja, solange es ein /24-Netz ist), aber die Konfiguration eines eigenen virtuellen Adapters durch den Client hat bei mir (gegen eine "conntype_user"-Verbindung) eigentlich immer auch dann funktioniert, wenn es ein Rechner mit mehreren Interfaces (und damit auch verschiedenen Adressen) war.

Nur sollte man dann natürlich "tunnel all" abschalten (https://www.shrew.net/static/help-2...Administrators Guide.html?PolicySettings.html) - denn hier wird keine "default route" konfiguriert, die erst dann greift, wenn ein Paket kein "besseres" Ziel findet, sondern Security-Associations (SA) für die Transformation von Paketen. Wenn diese Transformationen vor dem Routing greifen (auch wenn ich nicht definitiv weiß, wo sich dieser Client in das Netzwerk bei Windows einklinkt), kriegen die anderen Netzwerk-Interfaces gar keine Pakete mehr ab. Wenn erst das Routing kommt, kriegt der Code zur Transformation das Paket ggf. gar nicht mehr zu sehen, weil es an einen anderen Adapter ging, wo die ShrewSoft-Komponente nicht als Filter in der Kette hängt.