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

[jackyryan]

Hallo,

ich bekomme von einem Shrew VPN - Client immer ein "negotiation timeout occurred" obwohl genau die gleiche Konfigurationsdatei auf einem anderen Client läuft. Das heißt die Fritzbox und auch die Konfig sollte stimmen.
Der Problem - Client läuft unter Windows 11, was jedoch funktionieren sollte, weil es auf einem anderen mit Win11 auch geht. Es hat sich nun herausgestellt, dass es über WLAN klappt aber über LAN nicht.

Im Trace log sieht man, dass bei WLAN (links) nach "phase1 ref decrement" ein "recv IKE packet 134.3.166.55:500" kommt, aber bei LAN (rechts) dagegen nur ein "resend 1 phase1 packet(s)" und dann geht's nicht mehr richtig weiter:


[Edit Novize: Riesenbild gemäß der Forumsregeln auf Vorschau verkleinert]

Was kann das sein, etwas mit dem Switch/Router oder dem Treiber? LAN ist ein Intel I225-V und WLAN ein Intel Wi-Fi 6 AX201 - Chipsatz.
Nachfolgend der Log mit LAN (und beide auch angehängt). Wäre sehr nett, wenn Jemand einen Tipp oder eine Idee hat, was man prüfen oder testen könnte.

21/11/25 19:40:02 ## : IKE Daemon, ver 2.2.2
21/11/25 19:40:02 ## : Copyright 2013 Shrew Soft Inc.
21/11/25 19:40:02 ## : This product linked OpenSSL 1.0.1c 10 May 2012
21/11/25 19:40:02 ii : opened 'C:\Program Files\ShrewSoft\VPN Client\debug\iked.log'
21/11/25 19:40:02 ii : rebuilding vnet device list ...
21/11/25 19:40:02 ii : device ROOT\VNET\0000 disabled
21/11/25 19:40:02 ii : ipc server process thread begin ...
21/11/25 19:40:02 ii : pfkey process thread begin ...
21/11/25 19:40:02 ii : network process thread begin ...
21/11/25 19:42:33 ii : ipc client process thread begin ...
21/11/25 19:42:33 <A : peer config add message
21/11/25 19:42:33 <A : proposal config message
21/11/25 19:42:33 <A : proposal config message
21/11/25 19:42:33 <A : client config message
21/11/25 19:42:33 <A : xauth username message
21/11/25 19:42:33 <A : xauth password message
21/11/25 19:42:33 <A : local id 'philipp' message
21/11/25 19:42:33 <A : preshared key message
21/11/25 19:42:33 <A : remote resource message
21/11/25 19:42:33 <A : peer tunnel enable message
21/11/25 19:42:33 DB : peer ref increment ( ref count = 1, obj count = 0 )
21/11/25 19:42:33 DB : peer added ( obj count = 1 )
21/11/25 19:42:33 ii : local address 192.168.0.101 selected for peer
21/11/25 19:42:33 DB : peer ref increment ( ref count = 2, obj count = 1 )
21/11/25 19:42:33 DB : tunnel ref increment ( ref count = 1, obj count = 0 )
21/11/25 19:42:33 DB : tunnel added ( obj count = 1 )
21/11/25 19:42:33 DB : tunnel ref increment ( ref count = 2, obj count = 1 )
21/11/25 19:42:33 DB : new phase1 ( ISAKMP initiator )
21/11/25 19:42:33 DB : exchange type is aggressive
21/11/25 19:42:33 DB : 192.168.0.101:500 <-> 134.3.166.55:500
21/11/25 19:42:33 DB : a010492abbce1081:0000000000000000
21/11/25 19:42:33 DB : phase1 ref increment ( ref count = 1, obj count = 0 )
21/11/25 19:42:33 DB : phase1 added ( obj count = 1 )
21/11/25 19:42:33 >> : security association payload
21/11/25 19:42:33 >> : - proposal #1 payload
21/11/25 19:42:33 >> : -- transform #1 payload
21/11/25 19:42:33 >> : -- transform #2 payload
21/11/25 19:42:33 >> : -- transform #3 payload
21/11/25 19:42:33 >> : -- transform #4 payload
21/11/25 19:42:33 >> : -- transform #5 payload
21/11/25 19:42:33 >> : -- transform #6 payload
21/11/25 19:42:33 >> : -- transform #7 payload
21/11/25 19:42:33 >> : -- transform #8 payload
21/11/25 19:42:33 >> : -- transform #9 payload
21/11/25 19:42:33 >> : -- transform #10 payload
21/11/25 19:42:33 >> : -- transform #11 payload
21/11/25 19:42:33 >> : -- transform #12 payload
21/11/25 19:42:33 >> : -- transform #13 payload
21/11/25 19:42:33 >> : -- transform #14 payload
21/11/25 19:42:33 >> : -- transform #15 payload
21/11/25 19:42:33 >> : -- transform #16 payload
21/11/25 19:42:33 >> : -- transform #17 payload
21/11/25 19:42:33 >> : -- transform #18 payload
21/11/25 19:42:33 >> : key exchange payload
21/11/25 19:42:33 >> : nonce payload
21/11/25 19:42:33 >> : identification payload
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports XAUTH
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports nat-t ( draft v00 )
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports nat-t ( draft v01 )
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports nat-t ( draft v02 )
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports nat-t ( draft v03 )
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports nat-t ( rfc )
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports FRAGMENTATION
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local supports DPDv1
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local is SHREW SOFT compatible
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local is NETSCREEN compatible
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local is SIDEWINDER compatible
21/11/25 19:42:33 >> : vendor id payload
21/11/25 19:42:33 ii : local is CISCO UNITY compatible
21/11/25 19:42:33 >= : cookies a010492abbce1081:0000000000000000
21/11/25 19:42:33 >= : message 00000000
21/11/25 19:42:33 -> : send IKE packet 192.168.0.101:500 -> 134.3.166.55:500 ( 1203 bytes )
21/11/25 19:42:33 DB : phase1 resend event scheduled ( ref count = 2 )
21/11/25 19:42:33 DB : phase1 ref decrement ( ref count = 1, obj count = 1 )
21/11/25 19:42:38 -> : resend 1 phase1 packet(s) [0/2] 192.168.0.101:500 -> 134.3.166.55:500
21/11/25 19:42:43 -> : resend 1 phase1 packet(s) [1/2] 192.168.0.101:500 -> 134.3.166.55:500
21/11/25 19:42:48 -> : resend 1 phase1 packet(s) [2/2] 192.168.0.101:500 -> 134.3.166.55:500
21/11/25 19:42:53 ii : resend limit exceeded for phase1 exchange
21/11/25 19:42:53 ii : phase1 removal before expire time
21/11/25 19:42:53 DB : phase1 deleted ( obj count = 0 )
21/11/25 19:42:53 DB : tunnel ref decrement ( ref count = 1, obj count = 1 )
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : policy not found
21/11/25 19:42:53 DB : removing tunnel config references
21/11/25 19:42:53 DB : removing tunnel phase2 references
21/11/25 19:42:53 DB : removing tunnel phase1 references
21/11/25 19:42:53 DB : tunnel deleted ( obj count = 0 )
21/11/25 19:42:53 DB : peer ref decrement ( ref count = 1, obj count = 1 )
21/11/25 19:42:53 DB : removing all peer tunnel references
21/11/25 19:42:53 DB : peer deleted ( obj count = 0 )
21/11/25 19:42:53 ii : ipc client process thread exit ...

 

[wari1957]

Hallo @jackyryan ,
in dem Fall hilft nur ein Netzwerktrace mit Wireshark weiter.

 

[kleinkariert]

Da ich schon Fälle von nonAVM-Repeatern erlebt habe, wo der Shrewsoft nicht funktionierte, was verbirgt sich genau hinter WLAN- und LAN-Anbindung?
Und hast du schon mal die simple Methode "Neuinstallation" probiert?

 

[jackyryan]

@kleinkariert
Auf dem Client ein "NUC" (Terra PC-Micro) läuft seit etwa einer Woche Windows 11, daher noch wie eine Neuinstallation.
LAN bedeutet, dass die Ethernet-Schnittstelle mit Kabel zum Vodafone-Router verwendet wird, um ins Internet (und damit auch ins entfernte Firmennetz per VPN) zu gehen.
WLAN bedeutet, dass statt dem Ethernet-Kabel per WLAN zum Vodafone-Router verbunden wird.
Komisch, weil LAN müsste doch eigentlich stabiler und unkritischer sein?

@wari1957 Kommt man mit Wireshark wirklich weiter? Dann die Traces vom WLAN und LAN miteinander vergleichen? Ist halt oft schwierig, weil das ja tausende Frames sind und man als Laie oft nicht weiß, nach was man suchen soll.

 

[wari1957]

Kommt man mit Wireshark wirklich weiter?

Hat mir bisher immer geholfen.
Entweder kommen die Pakete über LAN nicht an der FB WAN-Seite an oder die FB antwortet nicht.
Wireshark kennt Filter (ISAKMP, IPv4-Adresse, ...).

 

[PeterPawn]

Dem Protokoll nach, war das ja parallel von zwei Clients aus und damit sollte das schon mal NICHT dieselbe Konfiguration sein. Ich hoffe mal, die Formulierung:

obwohl genau die gleiche Konfigurationsdatei auf einem anderen Client läuft.

ist nur ein Mißverständnis? Ansonsten solltest Du einen Rekey-Versuch auch mal beobachten, während der zweite Client nicht aktiv ist. LAN vs. WLAN wird eher nicht das Problem sein - hier, denke ich, gehst Du in die Irre.

 

[jackyryan]

@PeterPawn Selbstverständlich sind nicht beide zur gleichen Zeit aktiv. Es gibt für jeden Client eine eigene Shrew-Config. Da es bei dem problematischen Client nicht ging, hab ich die Konfigs in beide Richtungen getauscht. Beide gehen auf einem anderen und keine geht auf dem Problematischen.
Warum sollte die gleiche Config-Datei zur nicht-selben Zeit auf einem anderen Client nicht auch funktionieren? Mein Test sagt es geht.
Inwiefern gehe ich mit WLAN-LAN in die Irre? Der Test ist reproduzierbar und wenn WLAN immer geht, muss doch auf dem LAN-Übertragungsweg etwas nicht stimmen?

 

[PeterPawn]

Es gibt für jeden Client eine eigene Shrew-Config.

Auch das ist noch mißverständlich ... für jeden ShrewSoft-Client ist zwar auch eine "eigene Konfiguration" erforderlich (wenn man da den Account einbezieht, mit dem sich der Client einwählt), aber viel entscheidender ist es, daß es dann auch zwei Accounts auf der FRITZ!Box gibt und sich jeder Client in seinen eigenen Account einwählt, wenn man die nicht mit größerem zeitlichen Abstand benutzen will.

Weil es kein "Beenden" bei einer IPSec-SA gibt (mal abgesehen von einer Anzeige "vergiß alle alten SAs - this is a new 'first contact'"), können sonst noch alte SAs aktiv sein (die Gegenstelle ist ja dieselbe IP-Adresse aus Sicht der 6660) und dann wird schon mal der falsche Key benutzt, womit die Gegenstelle eine Antwort dann nicht decodieren kann und die üblicherweise als "nicht gegeben" einstuft (ansonsten könnten gespoofte Pakete VPN-Verbindungen ja leicht durcheinander bringen).

Warum das ansonsten nicht funktioniert, wenn zwei IPSec-Clients parallel mit ESP arbeiten wollen an einer öffentlichen IP-Adresse (und von NAT-T ist nichts zu sehen in den IKE-Logs bei der LAN-Variante), findet man - gut erklärt - im Internet oder auch in der AVM-Knowledge-Base (da aber ohne Erklärung, sondern nur als Statement und auch nur für ausgehende Verbindungen, aber irgendein Router muß da ja auch die Rolle mit 192.168.0.0/24 geben, die man in den Logs sieht): https://avm.de/service/wissensdaten...es-anderen-Herstellers-im-Heimnetz-einsetzen/

Falls die VPN-Software das IPSec-Protokoll ohne NAT-Traversal oder das PPTP-Protokoll verwendet, ergeben sich durch den Einsatz hinter einem Router wie der FRITZ!Box folgende Einschränkungen:

• Es können nicht mehrere VPN-Verbindungen gleichzeitig zum selben VPN-Server hergestellt werden.

Und die beiden Protokolle in #1 beginnen dann auch noch auf die Sekunde zur gleichen Zeit, um die Verwirrung komplett zu machen - schon das ist (selbst bei einem gleichzeitigen und parallel laufenden Start zweier Geräte) ja eher ungewöhnlich. Am Ende werde ich jedoch nicht mal richtig schlau aus dem Satz:

Der Problem - Client läuft unter Windows 11, was jedoch funktionieren sollte, weil es auf einem anderen mit Win11 auch geht. Es hat sich nun herausgestellt, dass es über WLAN klappt aber über LAN nicht.

- heißt das nun, daß die Protokolle von zwei verschiedenen Clients stammen oder ist das derselbe Client, der über LAN bzw. WLAN unterschiedliche IP-Adressen verwendet? Wie sieht das in der Realität aus und wie soll(te) man das aus dem bisher Geschriebenen erkennen können? Klappt es mit WLAN jeweils auf beiden Geräten, aber mit LAN auf keinem? Ich finde nicht, daß das irgendwie klar zu erkennen wäre.

Der Test ist reproduzierbar und wenn WLAN immer geht, muss doch auf dem LAN-Übertragungsweg etwas nicht stimmen?

Was genau heißt denn nun "reproduzierbar"? Ich kann - s.o. - aus dem bisher Geschriebenen nicht KLAR(!) erkennen, was "wenn WLAN immer geht" meint.

Eine "Reproduzierbarkeit" hängt halt auch immer davon ab, in welcher Reihenfolge man welche Schritte geht und wann/wie die beiden Clients eine Verbindung zur FRITZ!Box aufbauen wollen. Wenn man das (nach dem Swappen der Konfigurationsdateien für die ShrewSoft-Clients zwischen zwei Geräten) auch in derselben Reihenfolge macht, wie zuvor, dann wäre durchaus erklärlich, wenn der Fehler auch "mitwandert" und dann auch die andere Konfiguration auf dem LAN-basierten Client nicht funktioniert.

Vielleicht wäre es obendrein auch noch schlau, wenn Du nicht nur die Protokolle der Clients zeigst, sondern noch ein paar Worte dazu verlierst, wie genau eigentlich die FRITZ!Box 6660 konfiguriert wurde (angefangen mit der Aussage, ob das nun beides auf einen einzelnen Account zu verbinden versucht oder ob das doch zwei getrennte sind in der 6660) - und auch dort gibt es in den Support-Daten genug Infos zum VPN, die man zusätzlich auswerten sollte (mehrfach hier beschrieben, wo das ist und was davon interessant wäre - denn es interessiert gar nicht die gesamte Support-Datei und das spart dann viel Arbeit beim "Maskieren"). Aber da sieht man dann (mal halbwegs synchronisierte Zeitangaben vorausgesetzt) auch, von welchen Ports die Pakete jeweils bei der 6660 ankommen - bei Passthrough wäre da 500 beim Absender zu erwarten.

Nach den IKE-Logs in #1 kriegt der LAN-Client schlicht GAR KEINE Antwort von der FRITZ!Box. Der WLAN-Client kriegt es wenigstens noch hin, auf NAT-T umzuschalten (was er aber auch nur deshalb kann, WEIL er eine Antwort von der FRITZ!Box erhält und dabei dann feststellen kann, daß da irgendwo ein NAT-Router im Weg steht), so daß dieser Client mit Port 4500 "redet".

Beschreibe einfach den Testablauf und -aufbau noch einmal genauer und auch so, daß man ihn nachvollziehen kann, ohne daß weiterhin Fragen offenbleiben (welche das bei mir wären - auch nach dem Nachtrag in #7 - habe ich versucht zu zeigen). Es kann/wird nämlich durchaus auch noch einen Unterschied machen, welcher Router da noch zwischen Deinen beiden Clients und dem Ziel hängt (deren Adressen aus 192.168.0.0/24 sind ja offensichtlich nicht öffentlich) - denn der funkt dann bei Versuchen mit IPSec und ESP auch noch dazwischen, wenn er IPSec-Passthrough unterstützen sollte (was eine FRITZ!Box machen würde).

---

Als "Bonus-Tipp" noch von mir der Vorschlag, da beide Konfigurationen auf "Force NAT-T" zu stellen (wie genau die Option heißt, weiß ich auch nicht mehr - die findest Du sicherlich auch alleine, wobei ich vermutlich verdammt nahe dran bin mit meiner Vermutung hinsichtlich des Namens) ... das sorgt dann dafür, daß schon das erste Paket direkt an UDP 4500 der FRITZ!Box geht (und nicht an UDP 500 wie in Deinem LAN-Log) und nicht erst noch "discovered" werden muß, daß da ein NAT-Gateway im Wege steht.

Das macht dann aus jedem Kontaktversuch eine "eindeutige" UDP-Verbindung (weil ein NAT-T-Client auch vom NAT-Gateway einen wahlfreien Port für die ausgehende Verbindung erhält und nicht 500 behält) und dann kommen Pakete innerhalb einer solchen "Session" auch tatsächlich beim richtigen Empfänger an und sind obendrein auch noch mit einem - dem Empfänger auch bekannten - Key verschlüsselt.

Gleichzeitig hilft NAT-T von Beginn an auch dann, wenn der Router für die beiden getesteten Clients tatsächlich eine FRITZ!Box sein sollte und diese ihrerseits noch zusätzlich auf UDP 500 auf eingehende Verbindungen wartet. Dann sollte sie zwar die ausgehenden Pakete von den Clients auch keinesfalls mit Source-Port 500 weiterleiten, sondern NAT machen, aber das würde ich zumindest erst mal sehen wollen, bevor ich mich darauf verlasse. Und wenn da (ob richtigerweise oder fälschlich, spielt gar keine Rolle) ausgehend UDP 500 durchgelassen wird und die Antwort der 6660 dann beim lokalen Router und nicht beim Client landet, könnte der damit auch nichts anfangen, weil er den Inhalt nicht entschlüsseln kann.

Langer Rede kurzer Sinn (auch wenn "Begründungen" nie falsch sein können, zumindest solange sie technisch stimmen): Bitte präzisere Beschreibungen - niemand "sieht" hier, was Du gemacht hast und die einzigen Infos darüber, MUSS man Deinem Text entnehmen - und die Infos auch von der Seite der 6660 (wenn Du da nicht dran kommst, weil Du in der "Firma" keine Zugriffsrechte hast, mußt Du jemanden fragen, der sie hat) liefern. Das AVM-VPN ist da deutlich gesprächiger geworden, im Vergleich zu früheren FRITZ!OS-Versionen - es gibt also keinen Grund, sich da nur auf's "Raten" zu verlegen.

 

[jackyryan]

@PeterPawn
Danke für die sehr ausführliche Antwort! Ehrlich gesagt wollte ich jetzt keine Raketenwissenschaft daraus machen, sondern dachte dass man mit der Fehlermeldung und dem Trace zielgerichtet auf die Ursache kommt.
Aber wenn's hilft soll mir die Ausführlichkeit recht sein

In der Firma steht die Fritzbox 6660 mit je einer VPN-Verbindung für Benutzer 1 (bekommt interne IP 192.168.139.128) und Benutzer 2 (192.168.139.129):



Bisher konnte sich sowohl Benutzer 1 mit einem Win10-PC mit eigener Shrew-Konfig für Benutzer 1 über Ethernet-Kabel (+über 2 zusätzliche Switches unten nicht eingezeichnet) über seine Vodafonebox (internes IP-Netz 192.168.0.x) (muss noch erfragen welches Modell genau) sich übers Internet in die Firma einloggen.
Ebenso kann sich Bentuzer 2 mit seinem Win10-PC und eigener Shrew-Konfig für Benutzer 2 über Ethernet-Kabel über seine Fritzbox 7530 (internes IP-Netz 192.168.178.x) sich übers Internet in die Firma einloggen.

Benutzer 1 bekam einen neuen Win11-PC, hat den alten entfernt und geht nun über das gleiche Ethernet-Kabel über seine Vodafonebox ins Internet. Nur leider kommt beim Shrew-Client mit seiner Shrew-Konfig für Benutzer 1 das "Negotiation timeout occured". Wenn er sich dagegen per WLAN mit seiner Vodafonebox verbindet klappt die Verbindung mit dem Shrew-Client!
Nachfolgend die Übersicht (den alten Win10-PC von Benutzer 1 gibt es nicht mehr, anstelle dessen steht ausschließlich der neue Win11-PC):



Der Fehler kommt auch wenn Benutzer 2 überhaupt nicht verbunden ist (mehrere Tage nicht mehr online), daher unabhängig von Benutzer 2. Zudem sind ja in der Fritzbox 6660 extra 2 getrennte Benutzer mit unterschiedlichen internen IPs angelegt.
Reproduzierbar ist es, weil es bei Benutzer 1 sich immer mit WLAN zur Vodafonebox verbinden kann und immer mit dem Ethernet-Kabel zur Vodafonebox sich nicht verbinden kann.

Da die Vodafonebox bei Benutzer 1 bisher mit seinem Win10-PC alles richtig durchgeleitet hat, muss sie doch prinzipiell geeignet sein?


NAT-Traversal ist (und war es schon immer bei beiden Benutzern) aktiviert, wie kann es sein, dass das erste Paket an UDP500 und nicht 4500 geht?



War das soweit verständlich? Ich habe in meiner bisherigen beruflichen Laufbahn gelernt unnötige Informationen immer besser wegzulassen, um nicht zu verwirren und nicht unnötig Zeit mit Dingen zu verplempern die nichts zur Sache tun. Andererseits würde es mich an Deiner Stelle auch stören, alles nachfragen zu müssen, weil Du ja (noch) nicht tief im Problemthema drin bist. Ich dagegen bin seit Tagen dran und dachte die Zusammenhänge sind klar ;-)

Leider habe ich keinen direkten Zugriff auf Benutzer 2, ich bin nicht vor Ort. Auf die Fritzbox 6660 kann ich aber zugreifen.

Was könnte man nun testen / prüfen / tracen / aufnehmen etc. um die Ursache für Negotation Timeout zu finden?

 

[stsoft]

Kling für mich als ob da der Firewall von Windows 11 beim LAN-port das blockiert.
Einmal falsch geklickt oder gar nicht geklickt ind schon ist so eien Verbindung bei Windows als "öffentliches Net" mit hohen Firewallrestriktionen aktiv.

 

[jackyryan]

@stsoft Ja, in der Tat war ursprünglich "Öffentliches Netz" eingestellt. Das haben wir aber auf "Privates Netz" umgestellt und zudem die ganze Firewall + F-Secure-Virenscanner deaktiviert.
Kann ggf. einen Screenshot nachreichen, aber es war alles was ich gefunden habe von der Firewall ausgeschaltet.
Ist die Firewall nicht für alle Internetverbindungen (Ehternet-Kabel, WLAN, etc.) gleich "streng"?

 

[PeterPawn]

Fange mal damit an, das NAT-T (genau im gezeigten Fenster) von "erlaubt" (enabled) auf "erzwungen" (forced oder so ähnlich) umzustellen.

Ansonsten danke für die jetzt doch sehr klare Schilderung der Ausgangslage. Das hilft (a) dabei, die "üblichen" Probleme auszuschließen und erspart Dir unnütze Ratschläge, die nicht zur Situation passen (jetzt käme ja z.B. niemand mehr auf die Idee, daß da u.U. zweimal derselbe 6660-Benutzer verwendet wird, was aber ansonsten ein gerne genommener Fehler ist, wenn jemand Smartphone und Tablet manuell einrichtet) und (b) können jetzt auch spätere Leser mit einer ähnlichen Frage besser einschätzen, ob das bei ihnen WIRKLICH vergleichbare Umstände sind oder nur ein ähnliches Fehlerbild.

Wenn Du an die 6660 heran kommst, hole Dir dort unmittelbar nach dem nächsten Versuch (Benutzer 1 ist ja der mit dem Problem und an den kommst Du besser ran, bist es aber nicht selbst (weil Du erst nach dem Modell des VF-Routers fragen willst) - wenn ich es richtig verstanden habe; gleichzeitig bist Du aber auch nicht Benutzer 2, sondern ein Dritter, der das Problem lösen soll) die Support-Datei.

Damit kann man zumindest schon mal feststellen, ob das erste Paket die Box überhaupt erreicht - das schließt dann auch gleich die Blockade der ausgehenden Pakete durch die Windows-Firewall aus (aber noch nicht zwingend die der Antworten). Falls W11 tatsächlich getrennte Netze erkennt und damit auch getrennte Profile verwendet, könnte es ja wirklich an der Firewall liegen - das wäre dann aber m.W. eine Änderung ggü. W10, wenn jedes Interface eigene Profile erhält. Bisher gab es schlicht drei Profile und eines davon wurde einem Interface zugewiesen. Benutzen LAN und WLAN dasselbe, ist es eher nicht die Firewall.

Da würde ich dann eher auf MTU tippen (unterschiedliche Technologien haben auch unterschiedliche MTUs) - aber erst mal sicherstelllen, daß überhaupt Pakete ankommen und dann kann man immer noch nach deren Größe schauen. In dem Zusammenhang wäre es u.U. noch wichtig zu wissen, ob Benutzer 1 selbst eine öffentliche IPv4-Adresse hat oder über einen AFTR-Server bei Vodafone auf IPv4 zugreift - das verringert die Paketgröße zusätzlich. Mir ist auch so, als könne man beim ShrewSoft-Client die MTU einstellen - was wird dort denn im Moment verwendet? Wenn bei der WLAN-Verbindung ein kleinerer MTU-Wert automatisch ermittelt/verwendet wird, wäre das zumindest noch eine Erklärung.

Allerdings sind die initialen Pakete üblicherweise noch zu klein, um schon mit MTU-Problemen zu kämpfen - das ist dann wieder ungewöhnlich. Andererseits scheinst Du (wenn ich das Log richtig lese) eine längere Liste von Proposals für P1 zuzulassen, was man auch auf eines (dann eben eine als sicher angesehene Kombination) beschränken kann, womit auch das erste Paket kleiner wird.

 

[jackyryan]

@PeterPawn
Welches forced wäre richtig?



Ich bin Benutzer 2, und momentan nicht vor Ort bei Benutzer 1, der ja das Problem hat.

Wie kann ich nun in der Support-Datei erkennen, ob das erste Paket erreicht wurde? Die Textdatei hat ohne den Haken bei "erweitert" zu setzen, schon 3,5 MB (und dummerweise hab ich das zuerst mal an AVM gesendet anstatt runterzuladen....zzz)

Im Abschnitt "VPN avmike" steht einiges von Benutzer 1, von Benutzer 2 (bei dem es ja funktioniert) aber leider gar nichts?

Weiter unten ist etwas mit "no phase1ss for cert users configured" zu sehen, könnte hier der Hund begraben sein?

2021-11-25 21:06:56 avmike:<<< 4500 infomode[46.5.228.161:37114] benutzer1: V1.0 92 IC 520ba98f43e6df97 RC 3e9b08816807b12f 28ff0df6 HASH flags=e
2021-11-25 21:06:56 avmike:benutzer1: del phase 1 SA 49
2021-11-26 06:11:34 avmike:<<<  identity protection mode[184.105.247.195:15514] ???: V1.0 64 IC 3e35c70729dfedef RC 00000000 0000 SA flags=
2021-11-26 06:11:34 avmike:no phase1ss for cert users configured
2021-11-26 06:11:34 avmike:184.105.247.195:15514: new_neighbour_template failed
2021-11-26 08:42:56 avmike:146.88.240.4:35780: packet check: IKE-Error 0x200a:
2021-11-27 08:35:13 avmike:146.88.240.4:48146: packet check: IKE-Error 0x200a:
2021-11-27 12:27:11 avmike:<<<  identity protection mode[65.49.20.100:60773] ???: V1.0 64 IC 3e35c70729dfedef RC 00000000 0000 SA flags=
2021-11-27 12:27:11 avmike:no phase1ss for cert users configured
2021-11-27 12:27:11 avmike:65.49.20.100:60773: new_neighbour_template failed

Im Anhang der "VPN avmike" - Abschnitt der Support - Datei.

 

[PeterPawn]

Den Anhang kann ich auf dem Tablet nicht richtig lesen, da muß ich erst den PC anwerfen. Das dauert etwas - in der Zwischenzeit könntest Du schon mal die ShrewSoft-Konfiguration beim Benutzer 1 auf "aggressive mode" umstellen lassen. Denn zumindest der letzte Kontakt um 12:27 Uhr will den "main mode" verwenden und das FRITZ!OS kann das nicht (new neighbor failed). EDIT: Ach so, natürlich auch PSK, der Client will offenbar auch noch ein Zertifikat verwenden.

 

[jackyryan]

In Phase 1 ist agressive bereits ausgewählt:



Und bei Authentification Mutual PSK + XAuth:


[Edit Novize: Bilder gemäß der Forumsregeln auf Vorschau verkleinert]

Ist das falsch, wenn ja, auf was müsste es geändert werden?

 

[PeterPawn]

OK, vergiß das mit den Settings einfach wieder ... wenn die Protokoll-Einträge um 12:27 Uhr gar nicht von Deinem Benutzer1 sind (zumindest hatte der vorgestern noch eine vollkommen andere IP-Adresse), dann ist das jemand anderes (ein "Fremder", aka Versuch des Eindringens, der aber gescheitert ist). Da habe ich mich aufs Glatteis führen lassen - mein Beitrag ist ja erst von 12:44 Uhr und der Verbindungsversuch im Protokoll schon von 12:27 Uhr. Außerdem war die bisher von Benutzer1 verwendete IP-Adresse auch erst zu sehen, wenn man den Anhang geöffnet hat.

Also noch einmal ein paar Schritte zurück. Ich bin gerade auf der (mentalen) Suche nach einer Möglichkeit, den avmike im FRITZ!OS neu zu starten (damit der mit einem "cleanen" Protokoll beginnt), ohne daß man gleich die ganze Box neu starten müßte. Wenn das für Dich auch kein Problem wäre, ist so ein Neustart natürlich auch eine gute Gelegenheit, andere Relikte in der Support-Datei loszuwerden (die werden wir noch ein paar Mal abholen müssen, vermutlich), die wird dann auch wieder etwas kleiner.

Ansonsten hat AVM da vieles umgemodelt - ich bin nicht sicher, ob das Hinzufügen/Entfernen einer neuen VPN-Verbindung (dann am besten eine LAN-LAN-Connection, die muß auch nicht funktionieren und wird ja wieder gelöscht) den ctlmgr dazu bewegt, den avmike neu zu starten. Das war mal so (weil die nicht über IPC kommunizierten) - jedoch AVM hat am VPN mächtig geschraubt und es wäre denkbar, daß mittlerweile auch Konfigurationsänderungen einfach signalisiert werden können und keinen Neustart des Daemons mehr erfordern. Aber einen Versuch wäre es zumindest wert - wenn's nicht klappen sollte, ist auch nichts verloren.

Wenn es tatsächlich keine neueren Einträge im avmike-Log gibt, dann erreichen die Pakete von Benutzer1 die Box offenbar auch gar nicht. Da wäre dann (allerdings erst mit einem bereinigten avmike-Protokoll) die Gegenprobe mit dem WLAN gut - da hat man dann automatisch auch die IP-Adresse des Routers von Benutzer1. MTU kannst Du erst einmal vergessen, ich hatte mir den Screenshot in #13 nicht richtig angesehen. Da ist bereits eine kleine Paketgröße für P1 eingestellt und beim "forced NAT-T" kannst Du zwischen RFC und Draft wählen, das FRITZ!OS beherrscht (iirc und ohne Sicherheit, weil eben viel geändert wurde) beides. Wobei ich dann RFC nehmen würde - das ist letztlich "der Standard" geworden. Der Effekt ist letztlich, daß von Beginn an der UDP-Port 4500 verwendet wird und nicht erst ermittelt werden muß, daß da (ja nun definitiv) ein NAT-Router im Wege steht. EDÌT: Außerdem triggert das dann auch keinen - event. vorhandenen - IPSec-Passthrough-Mechanismus im Router.

Wobei das dann tatsächlich immer mehr darauf hinweist, daß beim LAN-Adapter andere Firewall-Einstellungen wirksam sein könnten, als beim WLAN-Adapter - W11 habe ich zugegebenermaßen komplett von meiner "Wunschliste" gestrichen, das wird das erste Windows sein, was ich nicht anfassen werde. Ich weiß also nicht einmal, ob man da noch die Firewall komplett deaktivieren könnte (nur zum Test selbstverständlich), um sie erst einmal als mögliche Ursache auszuschließen.

EDIT/PS: Ob der avmike neu gestartet wurde, sieht man u.a. an seiner PID in der Prozessliste, die ziemlich am Beginn der (kompletten) Support-Datei zu finden ist.

 

[jackyryan]

Interessant, was um 12:27 war, weil ich war's nicht.
Okay, sind ein paar Vorschläge zum Testen, wobei es eventuell etwas dauern könnte (morgen...)
Windows 11 würde ich gerne ausschließen, weil bei mir eine virtuelle Maschine mit Win11 einwandfrei funktioniert. Ich prüfe das mit der Firewall auf jeden Fall nochmal.

 

[PeterPawn]

Das ist bei Benutzer1 aber schon "bare metal" mit W11 und nicht auch eine VM, oder? Ich frage nur zur Sicherheit nach - denn dann wäre u.U. noch ein Fehler in der Netzwerk-Konfiguration der VM(-Hardware) denkbar.

So ungewöhnlich ist Virtualisierung auch auf Clients heute nicht mehr - ich habe auch schon Laptops gesehen, die mit ESXi als Hypervisor verwendet wurden und auch W10-PCs, die - bei passender Hardware und der richtigen Windows-Edition - mit aktiviertem HyperV betrieben wurden, wobei den meisten dabei nicht klar ist, daß dann auch ihr Windows 10-System "nur noch" ein weiteres System auf dem Bare-Metal-Hypervisor ist und NEBEN den anderen VMs läuft, während es genauso wie alle anderen mit der Hardware über den Hypervisor kommuniziert (oder die Hardware wird exklusiv einer VM zugewiesen).

Ich weiß wieder nicht (und es interessiert mich auch nicht genug, um das jetzt zu recherchieren), was unter W11 mit HyperV passiert ist - gleichzeitig kann ich nicht glauben, daß man es eingestampft haben sollte, denn zur Isolation (als Security-Feature) ist das ja nach wie vor ein Weg. Eher wird man es vermutlich per default aktivieren (reine Vermutung meinerseits), weil die höheren Hardware-Anforderungen (zumindest hinsichtlich modernerer Architekturen und der Unterstützung von Virtualisierungsfunktionen) die Bandbreite an möglichen Systemen, die dafür zu schwach oder nicht länger geeignet sind (Stichwort VT-x bzw. AMD-V), doch deutlich einschränkt.

 

[jackyryan]

Natürlich verwendet Benutzer1 WIn11 nativ. Virtuell (Virtuellbox und nicht HyperV) habe ich bei mir Win11 als Benutzer2 getestet, weil ich wissen wollte, ob es an Win11 liegen könnte. Aber hier funktioniert ja alles.

Da ich bei Benutzer1 nicht vor Ort bin, konnte ich bisher nicht alles testen, aber gestern gab es in der Support-Datei der 6660 folgende Erkenntnis:

Benutzer1 hat sich direkt mit dem LAN-Kabel mit dem Vodafone-Router verbunden, sonst nichts dazwischen. Wie üblich bekam er das Negotiation timeout. Im "VPN avmike" - Abschnitt der Log scheint es (mehrmals) einen "IKE-Error 0x2027" zu geben beim Aufbau der phase1:

2021-11-29 20:28:14 avmike:<<<  aggressive mode[46.5.229.199:51146] ???: V1.0 1175 IC da6450763fc482f8 RC 00000000 0000 SA flags=
2021-11-29 20:28:14 avmike:aggressive mode benutzer1: selected lifetime: 28800 sec(notify)
2021-11-29 20:28:14 avmike:benutzer1 receive VENDOR ID Payload: XAUTH
2021-11-29 20:28:14 avmike:benutzer1 receive VENDOR ID Payload: NAT-T RFC 3947
2021-11-29 20:28:14 avmike:benutzer1 receive VENDOR ID Payload: DPD
2021-11-29 20:28:14 avmike:benutzer1: add phase 1 SA: DH2/AES-256/SHA1/28800sec id:50
2021-11-29 20:28:14 avmike:create phase1 responder lifetime payload
2021-11-29 20:28:14 avmike:>>> aggressive mode [46.5.229.199:51146] benutzer1: V1.0 472 IC da6450763fc482f8 RC e22b03a544880150 0000 SA flags=
2021-11-29 20:28:19 avmike:<<<  aggressive mode[46.5.229.199:51146] benutzer1: V1.0 1175 IC da6450763fc482f8 RC 00000000 0000 SA flags=
2021-11-29 20:28:24 avmike:<<<  aggressive mode[46.5.229.199:51146] benutzer1: V1.0 1175 IC da6450763fc482f8 RC 00000000 0000 SA flags=
2021-11-29 20:28:28 avmike:benutzer1: Phase 1 failed (responder): IKE-Error 0x2027
2021-11-29 20:28:28 avmike:benutzer1: del phase 1 SA 50
2021-11-29 20:28:29 avmike:<<<  aggressive mode[46.5.229.199:51146] ???: V1.0 1175 IC da6450763fc482f8 RC 00000000 0000 SA flags=
2021-11-29 20:28:29 avmike:aggressive mode benutzer1: selected lifetime: 28800 sec(notify)
2021-11-29 20:28:29 avmike:benutzer1 receive VENDOR ID Payload: XAUTH
2021-11-29 20:28:29 avmike:benutzer1 receive VENDOR ID Payload: NAT-T RFC 3947
2021-11-29 20:28:29 avmike:benutzer1 receive VENDOR ID Payload: DPD
2021-11-29 20:28:29 avmike:benutzer1: add phase 1 SA: DH2/AES-256/SHA1/28800sec id:51
2021-11-29 20:28:29 avmike:create phase1 responder lifetime payload
2021-11-29 20:28:29 avmike:>>> aggressive mode [46.5.229.199:51146] benutzer1: V1.0 472 IC da6450763fc482f8 RC 5c776dff39f474aa 0000 SA flags=
2021-11-29 20:28:43 avmike:benutzer1: Phase 1 failed (responder): IKE-Error 0x2027
2021-11-29 20:28:43 avmike:benutzer1: del phase 1 SA 51

Bei Benutzer2 dagegen wird "avmike:<<< 4500 aggressive mode" verstanden und "benutzer2: switching to NAT-T (Responder)" gesetzt, so dass phase1 ready ist:

2021-11-29 21:21:39 avmike:<<<  aggressive mode[77.189.38.187:61043] ???: V1.0 1134 IC 8c105b37cb60a256 RC 00000000 0000 SA flags=
2021-11-29 21:21:39 avmike:aggressive mode benutzer2: selected lifetime: 28800 sec(notify)
2021-11-29 21:21:39 avmike:benutzer2 receive VENDOR ID Payload: XAUTH
2021-11-29 21:21:39 avmike:benutzer2 receive VENDOR ID Payload: NAT-T RFC 3947
2021-11-29 21:21:39 avmike:benutzer2 receive VENDOR ID Payload: DPD
2021-11-29 21:21:39 avmike:benutzer2: add phase 1 SA: DH2/AES-256/SHA1/28800sec id:10
2021-11-29 21:21:39 avmike:create phase1 responder lifetime payload
2021-11-29 21:21:39 avmike:>>> aggressive mode [77.189.38.187:61043] benutzer2: V1.0 472 IC 8c105b37cb60a256 RC e279b10c1133fd7f 0000 SA flags=
2021-11-29 21:21:40 avmike:benutzer2: Warning: source changed from 77.12.43.122:52828 to 77.189.38.187:61044
2021-11-29 21:21:40 avmike:<<< 4500 aggressive mode[77.189.38.187:61044] benutzer2: V1.0 108 IC 8c105b37cb60a256 RC e279b10c1133fd7f 0000 HASH flags=e
2021-11-29 21:21:40 avmike:benutzer2: switching to NAT-T (Responder)
2021-11-29 21:21:40 avmike:benutzer2: Phase 1 ready
2021-11-29 21:21:40 avmike:benutzer2: current=77.12.43.122 new=77.189.38.187
2021-11-29 21:21:40 avmike:benutzer2: no valid sa, resetting initialcontactdone flag
2021-11-29 21:21:40 avmike:> user_changed(name=benutzer2,ipaddr=77.189.38.187:61044)
2021-11-29 21:21:40 avmike:benutzer2: local is behind a nat
2021-11-29 21:21:40 avmike:benutzer2: remote is behind a nat
2021-11-29 21:21:40 avmike:benutzer2: sending initial contact message
2021-11-29 21:21:40 avmike:>r> infomode 4500[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f e8aa4aed HASH flags=e
2021-11-29 21:21:40 avmike:>>> transaction mode 4500[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f 880fceb1 HASH flags=e
2021-11-29 21:21:40 avmike:<<< 4500 infomode[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f 693fb82 HASH flags=e
2021-11-29 21:21:40 avmike:benutzer2: initial contact message received
2021-11-29 21:21:40 avmike:benutzer2: inital contact message ignored
2021-11-29 21:21:40 avmike:<<< 4500 transaction mode[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f 880fceb1 HASH flags=e
2021-11-29 21:21:40 avmike:XAUTH REPLY received
2021-11-29 21:21:40 avmike:> user_xauth_query(ipaddr=77.189.38.187,name=benutzer2)
2021-11-29 21:21:40 avmike:user_xauth_query_reply -> XAUTH_STATUS_OK
2021-11-29 21:21:40 avmike:>>> transaction mode 4500[77.189.38.187:61044] benutzer2: V1.0 76 IC 8c105b37cb60a256 RC e279b10c1133fd7f 880fceb1 HASH flags=e
2021-11-29 21:21:40 avmike:<<< 4500 transaction mode[77.189.38.187:61044] benutzer2: V1.0 60 IC 8c105b37cb60a256 RC e279b10c1133fd7f 880fceb1 HASH flags=e
2021-11-29 21:21:40 avmike:XAUTH ACK received
2021-11-29 21:21:40 avmike:<<< 4500 transaction mode[77.189.38.187:61044] benutzer2: V1.0 76 IC 8c105b37cb60a256 RC e279b10c1133fd7f 3216722a HASH flags=e
2021-11-29 21:21:40 avmike:CFG REQUEST Msg erhalten
2021-11-29 21:21:40 avmike:> cfgmode_query(name=benutzer2)
2021-11-29 21:21:40 avmike:CFG_SND_REPLY
2021-11-29 21:21:40 avmike:>>> transaction mode 4500[77.189.38.187:61044] benutzer2: V1.0 76 IC 8c105b37cb60a256 RC e279b10c1133fd7f 3216722a HASH flags=e
2021-11-29 21:21:40 avmike:benutzer2: start waiting connections
2021-11-29 21:21:40 avmike:benutzer2: NO waiting connections
2021-11-29 21:21:44 avmike:<<< 4500 quickmode[77.189.38.187:61044] benutzer2: V1.0 1516 IC 8c105b37cb60a256 RC e279b10c1133fd7f 4c1154a2 HASH flags=e
2021-11-29 21:21:44 avmike:delete configmode retry timer for exchange: IC:8c105b37cb60a256 RC:e279b10c1133fd7f
2021-11-29 21:21:44 avmike:>>> quickmode 4500[77.189.38.187:61044] benutzer2: V1.0 156 IC 8c105b37cb60a256 RC e279b10c1133fd7f 4c1154a2 HASH flags=e
2021-11-29 21:21:44 avmike:<<< 4500 quickmode[77.189.38.187:61044] benutzer2: V1.0 60 IC 8c105b37cb60a256 RC e279b10c1133fd7f 4c1154a2 HASH flags=e
2021-11-29 21:21:44 avmike:benutzer2: Phase 2 ready
2021-11-29 21:21:44 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 56467D5B LT: 3600 I/O: IN
2021-11-29 21:21:44 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 568F9BBE LT: 3600 I/O: OUT
2021-11-29 21:21:44 avmike:< cb_sa_created(name=benutzer2,id=7,...,flags=0x00032003)
2021-11-29 21:21:44 avmike:benutzer2: start waiting connections
2021-11-29 21:21:44 avmike:benutzer2: NO waiting connections
2021-11-29 21:21:54 avmike:>>>4500 nat-t-keepalive[77.189.38.187:61044]
2021-11-29 21:21:55 avmike:<<< 4500 infomode[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f a37beadc HASH flags=e
2021-11-29 21:21:55 avmike:>r> infomode 4500[77.189.38.187:61044] benutzer2: V1.0 92 IC 8c105b37cb60a256 RC e279b10c1133fd7f a37beadc HASH flags=e

Wieso wird phase1 bei Benutzer1 nicht aufgebaut? Wird irgendwas verschluckt oder geht verloren bei >>> aggrssive mode? Was könnte man hier weiter testen?
Wenn der alte Win10-PC aber einwandfrei funktioniert, kann es wohl kaum am Vodafone-Router liegen?

In Google finde ich zu "IKE-Error 0x2027" hauptsächlich Einträge zum Verbinden 2er Fritzboxen per VPN, was ja hier nicht der Fall ist. Dort geht es wohl um eine statische öffentliche IPv4-Adresse. Sowohl Benutzer 1 als auch 2 haben doch eine übliche IPv4-Adresse?

 

[PeterPawn]

Wo ist denn jetzt die Gegenprobe über WLAN, wo das ja auch für Benutzer1 funktionieren soll? Warum jetzt wieder der Rückgriff auf die Annahme "Mit Windows 10 ging es ja auch.", wenn es doch per WLAN auch bei W11 funktioniert?

Jetzt kommen zwar offensichtlich die initialen Pakete von Benutzer1 an, aber die Antworten der FRITZ!Box erreichen den Absender nicht - deshalb wiederholt der Client in Abständen von 5 Sekunden den Versuch der Kontaktaufnahme noch dreimal. Danach gibt er wohl auf ... solche Protokolle manche nun mal nur dann Sinn, wenn man beide Seiten parallel betrachten kann - auf die Bedeutung von synchronisierten Zeitstempeln habe ich schon mal hingewiesen.

Nachdem es im Dialog zwischen der 6660 und Benutzer1 nicht in angemessener Zeit vorwärts geht (nach ca. 15 Sekunden), vergißt dann auch die 6660 wieder diesen Versuch der Kontaktaufnahme und entfernt die für P1 vorbereitete SA wieder, während danach immer noch ein neuer Versuch von Benutzer1 (die dritte Wiederholung) ankommt.

Da Benutzer1 jetzt aber seine Wiederholungen eingestellt hat und auch die Antwort der 6660 - auf den vermeintlich neuen Kontaktversuch bei dieser dritten Wiederholung - Benutzer1 wohl nicht erreicht, gibt es beim "zweiten" Mal halt keine weiteren Pakete von Benutzer1 und wieder wird nach ca. 15 Sekunden (meinetwegen mögen es auch nur 14 sein, wobei die Zeitstempel sicherlich auch gerundet werden) die vorbereitete SA gelöscht. So weit, so klar im Protokoll - aber eben nur in diesem. Der Fehlercode 0x2027 ist beim AVM-VPN ganz schlicht ein "Timeout" ... wenn keine Reaktion ihr Ziel erreicht, ist das nun mal das "normale" Vorgehen, daß man dann nach einer angemessenen Zeit entweder etwas wiederholt (so macht es der Client) oder alles abbricht (so macht es der "Server", dem aber auch nichts anderes bleibt).

Jetzt müßte man eben im Protokoll auf dem Client nachsehen (aber bitte auch tatsächlich in dem, was parallel zu den Einträgen in der FRITZ!Box aufgezeichnet wurde und nicht irgendwie in zwei zusammengestückelten Versuchen), ob der die Antworten gar nicht erst erhält oder ob er sie nur nicht versteht. Wenn die Pakete nicht ankommen, gibt es ja nicht mehr sooo viele Optionen, wo die unterwegs stecken bleiben könnten - erster Verdächtiger wäre halt der Vodafone-Router, der es ja aber nach Deinen Worten nicht sein kann, weil es mit Windows 10 ja alles funktioniert hat.

Also bleibt dann nur noch der Windows 11-Client, der sich ja mal definitiv als Faktor in der ganzen Geschichte geändert hat. Von all den anderen Vorschlägen, die es hier (iirc) schon gab, was man noch testen könnte, um eine Systematik zu erkennen, kann ich aber nichts sehen - weder vom bereits erwähnten Versuch über WLAN, noch von einem Test mit komplett deaktivierter (Windows-)Firewall, um die als potentiellen Störer auch auszuschließen.

Ich weiß also nicht genau, wo Du noch überall "nachsehen" willst ... wenn der Vodafone-Router keine Möglichkeit des Mitschnitts der eingehenden Pakete bietet, kannst Du ja nur HINTER diesem Router wieder auf die Suche nach den verschwundenen Antworten gehen und da ist ja dann auch schon der Windows 11-Client - und auf dem müßtest Du ja ohnehin nachsehen, schon um die (zeitgleichen) Protokolle des Shrewsoft-Clients mal zu zeigen.

Wenn nun aus irgendeinem Grund plötzlich auch bei WLAN-Nutzung der Windows 11-PC von Benutzer1 sich nicht mehr verbinden kann, dann sollte vielleicht doch mal ein Versuch mit einem anderen Endgerät (aber immer noch hinter dem Router von Benutzer1) gestartet werden - auch die Annahme "Der Vodafone-Router kann es ja nicht sein." geht ja offensichtlich davon aus, daß der "unveränderlich" wäre - das ist aber erst dann bewiesen, wenn es auch - Stand jetzt - weiterhin mit Windows 10 funktionieren sollte. Oder hat sich jemand den Stand der Firmware des Routers zu dem Zeitpunkt, wo es mit Windows 10 zuletzt noch lief, notiert? Angesichts der Unsicherheiten, was das überhaupt für ein Modell sein könnte, würde mich das sehr erstaunen.

Und in Anbetracht all dieser "Unwägbarkeiten" solltest Du vielleicht auf solche Annahmen, was es alles nicht sein KANN, verzichten und alle diese vermeintlichen Axiome noch einmal genauer untersuchen. Für die ersten Schritte (Kommen die Pakete vom Client überhaupt bei der 6660 an?) hast Du das jetzt gemacht - nun kann man entweder alles das, was man als sicher erachtet, wieder überspringen und steht dann genauso schlau wieder vor dem Windows-PC oder man versucht als Nächstes zu ergründen, was das für ein Router ist und welche Features der bietet - auch das wird sicherlich wieder davon abhängig sein, ob der Router von Vodafone "verwaltet" wird oder ein kundeneigenes Gerät ist.

---

Außerdem plagt mich so langsam die Frage, ob das wirklich alles 1:1 von Benutzer1 auf Benutzer2 und umgekehrt übertragbar oder auch nur vergleichbar ist. Vermutlich ist Benutzer1 ein Kunde bei KabelBW, während Benutzer2 wohl eher ein DSL-Anschluß bei O2 sein dürfte (alles nur geraten). Wo ist denn jetzt der Dritte im Bunde (also die 6660) bitte verbunden (das wird ja vermutlich ein DOCSIS-Anschluß sein, aber sicher ist das ja auch nicht wirklich, weil man die genauso hinter einem Modem als Router verwenden könnte - einen LAN1-Modus hat sie lt. Handbuch jedenfalls schon mal für den 2,5 GbE-Port) und ist das eine eigene Box oder eine vom Provider?

Ist das bei Benutzer1 tatsächlich eine eigene öffentliche IPv4-Adresse oder doch irgendein AFTR-Server beim Provider? Hinsichtlich der Adressbereiche, die von diesen Servern verwendet werden, sind die meisten Anbieter sehr verschwiegen - daher kann man das aus der Adresse eigentlich nicht ablesen ... aber es ist schon ungewöhnlich, wenn für eine solche IPv4-Adresse (so sie tatsächlich zu einem per DHCP vergebenen Segment gehört) kein Reverse-Lookup-Eintrag existiert. Das sollte zwar immer noch keine Auswirkungen auf P1 haben, solange Benutzer1 dann die Verbindung aufbauen will - aber es wird spätestens bei der Frage der MTU wichtig, wenn die Pakete dann mal etwas größer werden.