Shrew VPN mit Fritzbox 6660 negotiation timeout occurred => resend 1 phase1 packet(s)

Hi @KluthR ,
ja, die 3 Zeilen gab es in meiner Support-Datei in Post #13 auch:
https://www.ip-phone-forum.de/threa...-resend-1-phase1-packet-s.311695/post-2451563
Heißt das, dass es gar nicht am Shrew-Client liegt, oder wie verbindest Du das iPhone genau?
Wie hast Du es mit Wireshark gemacht, ein PC vor die Fritzbox mit 2 Netzwerkkarten verbunden?
Klappt es bei Dir mit anderen Clients, z.B. ein Rechner mit dem Shrew?

Wäre nett, wenn Du mir, falls es neue Erkenntnisse gibt, diese hier teilen würdest :)
 
Naja, eig wollte ich "nur" mit dem iPhone ins VPN. Das ging vor langer Zeit auch mal, wollte ich wieder machen - geht nicht. AVM geschrieben "Nutzen Sie doch bitte unseren Guide für iPhone" => geht nicht.

Dann halt die Info mit den Inkosistenten - die wohl keine waren (gestern aktuellen Stand hingeschrieben). Mal sehen.

Was andres hab ich nicht versucht. Für mich liegt hier ein FB-Problem vor.

Die Pakete habe ich mittels Paketmitschnitt der Box -> "1. Internetschnittstelle" ergattert.
 
Für mich liegt hier ein FB-Problem vor.
Da kommt ein Verbindungsversuch mit "main mode" anstelle des üblichen "aggressive mode" herein - DAS sollte an falschen Einstellungen im iPhone liegen … insofern ist das eher kein Problem der FRITZ!Box.

Icvh würde mir hier also eher Gedanken machen, warum mein iPhone trotz korrekter Konfiguration (die unterstelle ich jetzt mal, auch beim Punkt "Zertifikat verwenden" im iPhone) den "main mode" verwendet anstelle des "aggressive mode", wie das andere iPhones üblicherweise machen - und deren Besitzer haben dann auch keine Probleme damit, mit ihrem iPhone das VPN der FRITZ!Box zu nutzen. Denn mit etwas Nachdenken hätte man sich ja auch die Frage stellen können, warum es bei anderen offenbar deutlich weniger Probleme in dieser Hinsicht gibt - oder findest Du entsprechende Quellen (und zwar solche, wo es um "Massen" geht und nicht darum, ob ein oder zwei Hanseln Probleme haben, die VPN-Verbindungen einzurichten) irgendwo im Internet?



Der im Log zu sehende "identity protection mode" ist jedenfalls das, was im IKE(v1) dann "main mode" genannt wurde (https://datatracker.ietf.org/doc/html/rfc2409#section-5), was letztlich eine konkrete Implementierung des "identity protection exchange" aus dem ISAKMP-RFC ist (https://datatracker.ietf.org/doc/html/rfc2408#section-4.5) - der "aggressive mode" (https://datatracker.ietf.org/doc/html/rfc2409#section-5.4 - "aggressive mode with pre-shared key") ist die konkrete Umsetzung des "aggressive exchange" im ISAKMP (https://datatracker.ietf.org/doc/html/rfc2408#section-4.7). Daher verwenden machen die Begriffe "identity protection (exchange) mode" und "main mode" auch synonym - die IPSec-Implementierung bei AVM dürfte auch uralt sein.

Solange der Switch bei "Zertifikat verwenden" (was nur im "main mode" machbar ist) im iPhone nicht eingeschaltet ist (was AVM auch definitiv festhält im Bild: https://avm.de/service/vpn/tipps-tr...ritzbox-unter-apple-ios-zb-iphone-einrichten/), könnte so ein Verhalten (meines Wissens und mein letztes iPhone war ein iPhone 4 - danach habe ich mich nicht länger verschaukeln lassen von Apple) nur noch durch eine entsprechende Policy eingerichtet/vorgegeben werden, wenn das Gerät irgendwo zentral verwaltet wird (https://support.apple.com/de-de/guide/deployment/welcome/web) ... und auch dafür könnte die FRITZ!Box dann nichts und das sollte man als Besitzer so eines iPhones (und bitte nicht wieder Eigentum und Besitz verwechseln) dann aber auch wissen, weil das vermutlich nicht die einzige Einstellung wäre, die über eine zentrale Policy verändert würde.
 
hmm, okay. Dann ein iOS Problem. Was iOS da macht: ‍keine Ahnung

So wie auf den AVM Seiten ist es eingerichtet. Zertifikat ist aus.

Da AVM eine Inkosistenz meiner Einstellung vermutet hatte (und jetzt nach Reset immernoch das selbe Verhalten auftritt) ging ich mal blauäugig davon aus, dass es ein FB Problem wäre, ja.

Ja, ich wundere mich, wieso immer ich solche Probleme anziehe .

Aber wenn die StiNo Einstellungen so nicht funktionieren (ich sehe keine Konfigurationsfehler) müsste es doch mehr Leute betreffen? (iPhone FB Kombination)
 
AVM konnte einen Authentifizierungsversuch mit falschen Daten feststellen.

Ich habe tatsächlich die ganze Zeit den Gruppennamen vergessen anzugeben…

Jetzt geht das VPN.

Peinlich..


P.S.: AVM will ja künftig auf WireGuard setzen, hab ich gelesen.
 
  • Like
Reaktionen: PeterPawn
Ist ja witzig - da habe ich dann auch wieder etwas gelernt ... tatsächlich sieht es so aus, als würden diese "einfach zu konfigurierenden Clients" (für Android habe ich das geprüft - s.u. - und für iOS muß/kann man das dann offenbar auch annehmen) ihre "Entscheidung" für den zu verwendenden Modus beim Verbindungsaufbau auch davon abhängig machen, ob da eine "IPSec-ID" (deutsch, Android) oder ein "Gruppenname" (deutsch, iOS) angegeben wurde. Mit dieser Angabe wird (wie gesagt, nur bei Android selbst getestet) dann tatsächlich (und auch richtigerweise, denn das FRITZ!OS konfiguriert seine eingehenden Verbindungen immer so - im Parameter mode = phase1_mode_...) der "aggressive mode" verwendet und ohne landet man beim "identity protection mode" des ISAKMP:
with_ipsec_id.png
without_ipsec_id.png
Die (VPN-)Verbindungen (im Android), die diese Pakete erzeugt haben, unterscheiden sich tatsächlich nur in der Angabe der "IPSec-ID" - im Gegensatz zu "vollumfänglich konfigurierbaren Clients" versuchen diese Clients offenbar, den Typ so einer IPSec-Verbindung (bzw. genauer: die Parameter für die ISAKMP-/IKE-Phase) aus den angegebenen Daten zu "erraten", anstatt explizite Angaben zu verlangen.

Stellt man jedenfalls (als Beispiel) in der Konfiguration für charon (strongSwan 5.7.3) die explizite Angabe der eigenen ID ab, startet da dennoch ein IKE-Versuch im "aggressive mode" - da wird dann halt die aktuelle eigene IP-Adresse vom Peer verwendet:
charon_without_explicit_ipsec_id.PNG
Das ist also eher ein client-spezifisches Verhalten ... interessant, daß es offenbar bei iOS und bei Android quasi identisch implementiert wurde.

Wobei ich mir auch vorstellen könnte, daß am Ende irgendeine IPSec-Implementierung von Cisco (die sich dann wahrscheinlich auch so verhält) Pate stehen mußte ... das wäre auch eine Erklärung für dieses (fast identische) Verhalten und offenbar fehlen ja auch bei allen diesen Clients entsprechende Einstellmöglichkeiten - was für "einfachere Konfiguration" bei den meisten Smartphone-Benutzern vermutlich auch besser ist. Aber "richtige" Clients (inkl. des Shrewsoft-Clients, um den sich dieser Thread ja vorwiegend dreht) erlauben/erfordern dann schon die explizite Angabe - beim SC z.B. hier: https://www.shrew.net/static/help-2.2.x/html/Phase1Settings.html

Aber wieder was gelernt - iOS und Android schalten auf "main mode", wenn man keine IPSec-ID angegeben hat (die dient ja dem Peer zur Auswahl/Prüfung des passenden PSK für diesen "Account") - vermutlich auch, weil andere Peers (aka VPN-Server) dann anhand der Absender-IP nach einem passenden Zertifikat oder Konfigurationseintrag suchen (daher ja auch die "Fixierung" des "main mode" auf Konstellationen mit fester IP, wenn keine Zertifikate verwendet werden) und eher selten mit "pre-shared keys" (PSK) arbeiten werden. Wobei es beim iOS dafür ja auch wieder einen "switch" im UI gäbe (die AVM-Anleitung enthält ja einen Screenshot, in dem man einen solchen sieht) ... deshalb hatte ich den gedanklich auch mit der Umschaltung zwischen "main mode" und "aggressive mode" gleichgesetzt.

Aber es zeigt eben auch, DASS es immer wieder notwendig ist, bei solchen Problemen noch einige Male "nachzufassen", ob derjenige, der da ein Problem hat, der vorliegenden Anleitung auch WIRKLICH GENAU gefolgt ist oder ob er das nur so empfunden hat. Dennoch meinerseits Hochachtung für die Rückmeldung in #45 - an solchen Stellen dann eigene Fehler "eingestehen", können leider nur wenige und für mich gehört das zu den Punkten, welche die Männer von den Jungs unterscheiden. Also ein großes "Danke" dafür von meiner Seite ...
 
  • Like
Reaktionen: KluthR
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.