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

[jackyryan]

Danke für die schnelle und ausführliche Antwort gestern. Leider bin ich nicht vor Ort und kann nicht so vorgehen wie es sein sollte sondern muss die Erkenntnisse nehmen wie sie kommen. Sobald es möglich ist werde ich selbstverständlich WLAN und LAN testen und dessen Protokoll vergleichen. Wenn die Uhren der Fritzbox und des Win11-PC wirklich gleich gehen, könnte man den Log der Support-Datei der Fritzbox und den Trace-Log vom Shrew Client nebeneinanderlegen.
Wenn der Gegentest mit dem Win10-PC (ich hole das nach) nach wie vor funktioniert, kann es doch nur noch am Win11-PC-Client selbst liegen (und man damit die Vodafonebox und dessen FW, IPv4-v6, AFTR ausschließen)?

Die Fritzbox 6660 ist per DOCSIS3.x mit Vodafone (früher Unitymedia, noch früher KabelBW) verbunden.
Benutzer 1 weiß ich leider nicht ob Vodafone Kabel oder DSL (ja nervig, ich bin dran...)
Benutzer 2 = Ich hat ein O2-DSL (sehr gut geraten!)
Daher richtig, dass man vom Internetzugang Benutzer 1 mit 2 nicht unbedingt vergleichen kann. Mir ging es lediglich um den Support-Datei-Protokollvergleich, aber da muss man natürlich tiefer einsteigen...

Wenn die Pakete laut Shrew-Trace nicht zurückkommen, aber laut Support-Datei der Fritzbox ja zurückgeschickt wurde und der Vodafone-Router keine Pakete loggen kann, bliebe nur noch ein Wireshark-Trace auf dem Win11-PC?
Ich sehe zu, dass weiter getestet wird, hoffentlich gibt es bald eindeutige Erkenntnisse.

Sicher wäre auch ein Test in einem anderen Netzwerk mit anderem Internetprovider mit dem Win11-PC sinnvoll.

 

[PeterPawn]

Ich würde jetzt nicht zuviel querbeet testen - mit der Frage LAN vs. WLAN wäre da ja schon viel neue Erkenntnis möglich. Da jetzt noch andere Faktoren zu tauschen, um damit indirekt irgendeine Ursache auszuschließen, ist in meinen Augen weniger eindeutig, als der Test mit dem WLAN oder meinetwegen noch einem anderen Gerät hinter dem Vodafone-Router (das kann ja jedes gebräuchliche Smartphone auch machen) - ganz unabhängig davon, wie die Ergebnisse so eines "Ausschlußtests", wo sich noch einige weitere Faktoren ändern, am Ende ausfallen.

Der zweite Punkt (und den sollte man m.E. auch erst dann in Angriff nehmen, wenn es per WLAN oder mit einem anderen Gerät tatsächlich funktioniert) wäre es ja immer noch, die Firewall am Windows-PC zu Testzwecken (aber auch nicht länger) zu deaktivieren - auch das ist ja ein "scharfes Schwert" als Ergebnis und teilt die möglichen Ursachen deutlich an einer Stelle im Ablauf - geht es ohne Firewall (der PC ist dabei ja durch das NAT des VF-Routers immer noch geschützt), kann man alles davor (im Weg der Pakete) dann auch vergessen.

Ich weiß, daß man - gerade dann, wenn man selbst nichts machen kann ... das geht einem beim Beantworten von Fragen hier im Board ja eigentlich immer so - immer gleich einen bunten Strauß an möglichen Tests plant und ich beschreibe auch gerne mehrere Alternativen (falls sich etwas nicht so einfach umsetzen/testen läßt), aber i.d.R. soll man sich davon ein Problem/eine Strategie aussuchen und das dann bis zum Ende verfolgen, wobei dieses Ende dann erreicht ist, wenn sich etwas entweder als DIE eigentliche Ursache erwiesen bzw. Hinweise auf sie gegeben hat oder wenn eine These nicht länger haltbar ist, weil es einen klaren Gegenbeweis gibt.

 

[jackyryan]

Jetzt haben wir Logs vom LAN und WLAN aufgenommen.
Beim LAN wiederholt der Shrew wohl 3mal das Paket der phase 1 und hört dann auf:

21/12/04 19:51:15 -> : send IKE packet 192.168.0.101:500 -> 134.3.166.55:500 ( 1203 bytes )
21/12/04 19:51:15 DB : phase1 resend event scheduled ( ref count = 2 )
21/12/04 19:51:15 DB : phase1 ref decrement ( ref count = 1, obj count = 1 )
21/12/04 19:51:20 -> : resend 1 phase1 packet(s) [0/2] 192.168.0.101:500 -> 134.3.166.55:500
21/12/04 19:51:25 -> : resend 1 phase1 packet(s) [1/2] 192.168.0.101:500 -> 134.3.166.55:500
21/12/04 19:51:30 -> : resend 1 phase1 packet(s) [2/2] 192.168.0.101:500 -> 134.3.166.55:500
21/12/04 19:51:35 ii : resend limit exceeded for phase1 exchange
21/12/04 19:51:35 ii : phase1 removal before expire time
21/12/04 19:51:35 DB : phase1 deleted ( obj count = 0 )

Die Fritzbox sagt nur IKE-Error 0x2027 (timeout) (wohl 10s Differenz zwischen Win11-PC und Fritzbox):

2021-12-04 19:51:31 avmike:benutzer1 receive VENDOR ID Payload: DPD
2021-12-04 19:51:31 avmike:benutzer1: add phase 1 SA: DH2/AES-256/SHA1/28800sec id:2
2021-12-04 19:51:31 avmike:create phase1 responder lifetime payload
2021-12-04 19:51:31 avmike:>>> aggressive mode [46.5.229.126:25248] benutzer1: V1.0 472 IC e027faf5bf759a5f RC 648c72198c862a32 0000 SA flags=
2021-12-04 19:51:45 avmike:benutzer1: Phase 1 failed (responder): IKE-Error 0x2027
2021-12-04 19:51:45 avmike:benutzer1: del phase 1 SA 2

Mit WLAN dagegen scheint der Shrew die Antwort von der Fritzbox zu erhalten:

21/12/04 20:01:24 >= : message 00000000
21/12/04 20:01:24 -> : send IKE packet 192.168.0.147:500 -> 134.3.166.55:500 ( 1203 bytes )
21/12/04 20:01:25 DB : phase1 resend event scheduled ( ref count = 2 )
21/12/04 20:01:25 DB : phase1 ref decrement ( ref count = 1, obj count = 1 )
21/12/04 20:01:25 <- : recv IKE packet 134.3.166.55:500 -> 192.168.0.147:500 ( 472 bytes )
21/12/04 20:01:25 DB : phase1 found

Und die Fritzbox schaltet auf NAT-T und stellt phase1 her:

2021-12-04 19:55:09 avmike:benutzer1: add phase 1 SA: DH2/AES-256/SHA1/28800sec id:3
2021-12-04 19:55:09 avmike:create phase1 responder lifetime payload
2021-12-04 19:55:09 avmike:>>> aggressive mode [46.5.229.126:25248] benutzer1: V1.0 472 IC ecd346839a96f7a6 RC e863a53fa1167212 0000 SA flags=
2021-12-04 19:55:09 avmike:benutzer1: Warning: source changed from 0.0.0.0:500 to 46.5.229.126:25246
2021-12-04 19:55:09 avmike:<<< 4500 aggressive mode[46.5.229.126:25246] benutzer1: V1.0 108 IC ecd346839a96f7a6 RC e863a53fa1167212 0000 HASH flags=e
2021-12-04 19:55:09 avmike:benutzer1: switching to NAT-T (Responder)
2021-12-04 19:55:09 avmike:benutzer1: Phase 1 ready

Was könnte hier beim LAN schieflaufen? Hilft jetzt nur noch Wireshark weiter?

Der Router/Modem bei Benutzer 1 ist ein Touchstone TG3442DE von Vodafone und es ist ein Kabelanschluss. WLAN läuft über einen WLAN-Accesspoint von TP-Link TL-WA801ND.





Der Win11-PC ist ein Intel NUC11PABi3. Der Netzwerktreiber zeigt 1.0.2.13 an, von Intel gäbe es einen offiziellen 1.0.2.6, aber der lässt sich so nicht installieren (er findet die Netzwerkkarte irgendwie nicht).
Ein Router-Neustart veränderte nichts, ebenso nochmal alles der Firewall ausschalten nicht und das "force-rfc" im Shrew brachte auch keine Änderung.





Vollbild(er) gemäß Boardregeln als Vorschau eingebunden by stoney

Aber jetzt kommts: Ein USB-LAN-Adapter von D-Link funktioniert! Es sieht genauso aus wie beim WLAN. Muss es dann ein Treiber oder irgendein Hardwareproblem des Onboard-Ethernet-Adapters sein? Das war zwar nur ein temporärer Test, aber zumindest schonmal eine Lösung. Trotzdem unbefriedigend, kann deshalb das Onboard-LAN ohne eine Ursache zu finden nicht genutzt werden?

Im Anhang sind die Logs.
@PeterPawn Es wäre sehr nett, wenn Du mich nochmal unterstützen könntest

 

[PeterPawn]

Ist ja wirklich witzig - da muß ich erst mal eine Weile drauf herumdenken.

Wenn beim USB-Adapter aus demselben Kabel(!) an demselben Anschluß am Router(!) tatsächlich eine Antwort den PC erreicht, dann kann es ja eigentlich tatsächlich nur noch der Onboard-LAN-Adapter sein bzw. irgendwelche Einstellungen bei dem bzw. seinem Treiber. Da muß dann vielleicht doch einmal Wireshark ran, einfach um sicher zu gehen, ob nun beim LAN-Anschluß ein Paket ankommt oder nicht.

Ein weiterer Unterschied wäre die MAC-Adresse - die ist natürlich auch beim USB-Adapter eine andere. Nur kenne ich den Router nicht - aber der Neustart dort brachte ja auch keine Änderung und damit kann das zumindest ja schon mal keine "flüchtige" Einstellung/Einschränkung sein, die da ggf. die MAC-Adresse des PC im Router gesperrt hat. Wobei das vielleicht noch ein weiterer Test wäre, den man jetzt mit dem USB-Adapter und als Gegenprobe mit der/dem Onboard-NIC machen könnte ... einfach mal deren MAC-Adressen tauschen, das sollte (zumindest bei Intel-Treibern kenne ich das so) in den erweiterten Einstellungen des Netzwerk-Adapters unter Windows möglich sein.


Ich weiß nicht genau, wo bei Windows 11 dann der Capture-Treiber in der Verarbeitungskette für ein Paket sitzt - aber zumindest kann man mit dem Mitschnitt ermitteln, ob die Antworten davor oder dahinter versanden und sich dann immer noch schlau machen, was da ggf. anders ist ... denn wenn es mit Windows 10 funktioniert(e), kann das ja eigentlich nur noch der Windows 11-Treiber für den Onboard-NIC sein und dessen Einstellungen muß man dann ggf. genauer ansehen.

Was ich mir noch vorstellen könnte (ohne das jemals angesehen zu haben, denn Windows 11 kommt mir nicht auf die Platte bzw. in die Chips), wäre eine Konfusion zwischen dem Shrewsoft-Client und den Windows-Funktionen, wer nun für IPSec-Pakete zuständig ist. Denn eigentlich müßte eine IPSec/L2TP-Verbindung des Windows-VPN dieselben Ports benutzen - wobei mir auch keine logische Erklärung einfallen will, warum das dann nur mit dem Onboard-NIC auftreten soll. Meines Wissens sind die VPN-Verbindungen von Windows nicht an einen bestimmten Netzwerk-Adapter gebunden. Wenn sich dann aber irgendwelche Reihenfolgen der Filter-Chain im Netzwerk bei Windows 11 so geändert haben, daß die Pakete VOR dem Shrewsoft-Filter weggefangen werden (da KÖNNTE ich mir wieder einen Unterschied in diesen Filter-Ketten für Netzwerk-Verkehr vorstellen, der nur beim Onboard-NIC greift), dann wäre das vielleicht auch noch eine Erklärung.

An dieser Stelle hätte ich auch noch einen Vorschlag ... man könnte einfach mal den Onboard-NIC aus der PC-Konfiguration löschen (den guten alten Geräte-Manager gibt es bestimmt auch noch bei Windows 11) und dabei aber auch aufpassen, daß der nicht als "hidden" überlebt. Anschließend noch mal nach der Hardware suchen lassen und dann sollte Windows den eigentlich auch sofort wieder neu installieren. Die Idee dabei wäre es, daß dann auch die komplette Filter-Chain für das Interface neu aufgebaut wird (das lief bisher immer über die Registry) und das dann auch noch einmal zu einem Zeitpunkt, wo der Shrewsoft-Client schon installiert ist.

Ich gehe dabei mal von der Annahme aus, daß der Onboard-NIC unmittelbar bei der Windows-Installation schon eingerichtet wurde und erst danach kam dann der Shrewsoft-Client hinzu. Wenn der jetzt wirklich irgendwo an einer falschen Stelle in der Chain gelandet ist, kommen die Pakete vielleicht deshalb nicht mehr bei ihm an - was beim USB-Adapter ja offenbar kein Problem war, denn dessen Filter-Kette wurde sicherlich auch erst aufgebaut, als sein Treiber beim Anstecken des Adapters installiert wurde. Das ist zwar auch nur noch ein Schuß ins Blaue, aber zumindest einer, bei dem man sich noch eine halbwegs plausible Erklärung aus den Fingern saugen kann. Und wenn's das nicht ist, sollte das auch kein Problem sein, weil dann der vorhergehende Zustand problemlos wiederhergestellt sein sollte, sowie Windows den Adapter neu installiert hat.

War das eigentlich eine saubere Windows 11-Installation auf dem NUC oder ein Update von Windows 10 (viele wollen ja auch ihre Windows 10-Einstellungen lieber mit "rüber" nehmen)? Vielleicht stand es weiter vorne schon mal, aber ich hatte so viel am Beginn "mißverstanden", daß ich lieber noch einmal nachfrage, anstatt mir aus den vorhergehenden Beiträgen dann selbst etwas zusammenzureimen. Den Punkt mit der Frage, ob das tatsächlich dasselbe Kabel/derselbe Port am Router war, sollte man vielleicht auch noch einmal definitiv abfragen - manchmal steht der Router so nahe am PC, daß man da lieber ein anderes Kabel und einen weiteren Port benutzt, als erst das Kabel aus einem NUC zu "fummeln".

Ich würde also (wenn ich's selbst machen müßte) hier die Reihenfolge:

• Faktoren wie Kabel und Port am Router ausschließen => also wirklich 100% Vergleichbarkeit zwischen Onboard-Anschluß und USB-Adapter, was die Hardware "zum Router" angeht
• Adapter entfernen (inkl. Treiber: ) und neu installieren lassen - vielleicht behebt das auch gleich das Update-Problem (notfalls vorher explizit einen Snapshot vom VSS anlegen lassen)
• MAC-Adresse als Problem ausschließen (s.o.)
• Wireshark-Mitschnitt, am besten sogar mit einem Switch mit Monitor-Port (weil man dann auch sicher sein kann, was auf dem Kabel landet) UND auf dem PC selbst => die Ergebnisse können ja durchaus unterschiedlich sein, je nachdem, wo der Capture-Treiber in der Kette zu finden ist
• irgendwas anderes, was mir noch nicht eingefallen ist

wählen - parallel würde ich mich nach Tools umsehen, mit denen man sich die Filter-Chain eines Interfaces anzeigen lassen kann (ich weiß gerade nicht genau, ob das mit netsh im lan-Kontext alles sichtbar ist oder nicht), falls man da feststellen muß, was vor oder nach dem Capture-Treiber (je nachdem, ob der WS-Mitschnitt auf dem PC das Paket nun sieht oder nicht bzw. was der Mitschnitt am Monitor-Port des Switches dazu sagt) noch zwischen ihm und dem Shrewsoft-Filter hängt.

Wobei mir - während ich das schreibe - auch wieder einfällt, daß der Shrewsoft-Client ja pro VPN-Verbindung auch zwei verschiedene Methoden bietet, sich in den Datenstrom einzuklinken - einmal mit einem eigenen virtuellen Netzwerk-Adapter (der dann allen Traffic, der bei ihm ankommt, ver-/entschlüsselt) und einmal mit dem angesprochenen "Einklinken" in die Verarbeitung der Pakete bei einem "physischen" Netzwerk-Adapter. Das wäre zwar auch (weil es beim Client pro Verbindung konfiguriert werden kann, iirc) noch keine Erklärung, warum es nur mit dem einen physischen Adapter nicht klappt, aber vielleicht hilft es ja auch, wenn man mal den anderen Modus testet (also den, der im Moment nicht genutzt wird). Wenn's dann wider Erwarten doch klappt, kann man immer noch nach einer passenden Erklärung suchen.

 

[jackyryan]

Danke für die Hinweise und die Tipps.

Leider hat das Entfernen des Onboard-NIC inkl. Deinstallation der Treiber und wieder Neuinstallation noch nichts gebracht.
Ebenso ging es leider nicht, den Original Intel I225-V - Treiber zu installieren, weil er den Ethernet-Adapter irgendwie nicht findet.

Die Win11-Installation war lediglich eine Upgrade von Windows 10, wobei das Win10 aber ganz frisch drauf war.
Leider habe ich darauf keinen Einfluss und kann es jetzt nicht mehr ändern.

Das Netzwerkkabel ist definitiv genau das gleiche beim USB-Ethernet-Adapter und dem Onboard-NIC.

MAC-Adresse tauschen können wir noch probieren.
Wireshark muss ich mal schauen, Switch mit Port-Monitoring ist leider nicht vorhanden.
Den anderen Modus des Shrew - Client mit Einklinken in der physischen Adapter muss ich sehen, wie man das einstellt.

Wenn es mit WLAN oder dem USB-Ethernet-Adapter wirklich funktioniert (ich war nicht selbst vor Ort), wäre das trotzdem eine kurzfristige Lösung, wenn auch unschön.
Es hieß zuletzt, dass die lokale Namensauflösung trotz erfolgreich verbundenem Shrew-Client nicht ging.
Ist ein Test mit "nslookup <server.xyz> <dns-server-ip>" das richtige Vorgehen? (In der Shrew-Konfig ist der lokale DNS-Nameserver eingetragen mit Domänen-Suffix) und das ging vorher mit Win10-PC und klappt bei Benutzer2).

 

[jackyryan]

Ich habe die letzten Tage folgendes herausgefunden:
- Mit dem NCP-Client bekomme ich eine erfolgreiche funktionierende VPN-Verbindung zur Fritzbox sowohl über LAN als auch WLAN hin.
- Der erwähnte Win11-PC kann die VPN-Verbindung per Shrew-Client an einem anderen Telekom-DSL-Anschluss über eine Digibox-Smart über WLAN erfolgreich herstellen. Aber über LAN-Kabel geht es auch hier nicht (negotation timeout...).

Ich erwähnte, dass es per WLAN immer klappt am Vodafone-Kabelanschluss, was leider so nicht stimmt. Der Shrew-Client meldet zwar "Tunnel enabled" aber in der Fritzbox sieht man, dass VPN nicht steht. Sämtliche Pings etc. klappen auch nicht. Im Log der Fritzbox kommt es nicht zur phase2, sondern wieder zu del phase1:

2021-12-26 11:30:00 avmike:> user_xauth_query(ipaddr=46.5.228.13,name=benutzer1)
2021-12-26 11:30:00 avmike:user_xauth_query_reply -> XAUTH_STATUS_FAILED
2021-12-26 11:30:00 avmike:>>> transaction mode 4500[46.5.228.13:19680] benutzer1: V1.0 76 IC 32ea4beac2cd83ea RC 8665b075b5559465 8fb2b2a3 HASH flags=e
2021-12-26 11:30:00 avmike:<<< 4500 infomode[46.5.228.13:19680] benutzer1: V1.0 92 IC 32ea4beac2cd83ea RC 8665b075b5559465 f61b0232 HASH flags=e
2021-12-26 11:30:00 avmike:benutzer1: del phase 1 SA 47

Mit dem NCP-Client wird dagegen Phase 2 aufgebaut, sieht aber etwas anders aus (auch per WLAN am Telekom-DSL-Anschluss mit dem Shrew sieht es genau so aus):

2021-12-26 11:27:55 avmike:CFG REQUEST Msg erhalten
2021-12-26 11:27:55 avmike:> cfgmode_query(name=benutzer1)
2021-12-26 11:27:55 avmike:CFG_SND_REPLY
2021-12-26 11:27:55 avmike:>>> transaction mode 4500[46.5.228.13:19648] benutzer1: V1.0 92 IC 5cb551b63aa17953 RC bb816bd977a1fb01 695b0e70 HASH flags=e
2021-12-26 11:27:55 avmike:benutzer1: start waiting connections
2021-12-26 11:27:55 avmike:benutzer1: NO waiting connections
2021-12-26 11:27:55 avmike:<<< 4500 quickmode[46.5.228.13:19648] benutzer1: V1.0 924 IC 5cb551b63aa17953 RC bb816bd977a1fb01 59a8cc94 HASH flags=e
2021-12-26 11:27:55 avmike:delete configmode retry timer for exchange: IC:5cb551b63aa17953 RC:bb816bd977a1fb01
2021-12-26 11:27:55 avmike:>>> quickmode 4500[46.5.228.13:19648] benutzer1: V1.0 156 IC 5cb551b63aa17953 RC bb816bd977a1fb01 59a8cc94 HASH flags=e
2021-12-26 11:27:56 avmike:<<< 4500 quickmode[46.5.228.13:19648] benutzer1: V1.0 60 IC 5cb551b63aa17953 RC bb816bd977a1fb01 59a8cc94 HASH flags=e
2021-12-26 11:27:56 avmike:benutzer1: Phase 2 ready

In der ipsec.log des Shrew finde ich am erwähnten Telekom-DSL-Anschluss keinerlei "!!" - Zeichen. Am problematischen Vodafone-Kabelanschluss dagegen

Am Anfang einmal:
21/12/26 10:19:54 !! : vflt send device attach failed
21/12/26 10:19:54 !! : vflt recv device attach failed
und eine ganze Menge:
21/12/26 10:21:55 ii : inspecting ARP request ...
21/12/26 10:21:55 !! : ARP packet has invalid header

Ich hätte nun die Lösung mit dem NCP-Client, aber er kostet natürlich etwas Geld. Wenn die Nuss mit dem Shrew-Client zu knacken ist, wäre das toll
Im Anhang ist ein Beispiel (Fritzbox Support-Datei-avmike und ipsec.log des Shrew) am Vodafone-Kabelanschluss des Win11-PC über WLAN, wo zwar der Shrew "enabled" meldet, aber die Fritzbox nicht grün ist und es kein ping etc. klappt.

@PeterPawn Könntest Du nochmal einen Blick drüber werfen? Wenn man beim Shrew-Client noch etwas machen kann wäre das super. Könnte es mit dem "ARP packet has invalid header" zusammenhängen?

 

[pl3b]

Hallo PeterPawn, wari, kleinkariert und jackyryan. Ich bin der ominöse Benutzer 1 und möchte mich auf diesem Wege zunächst einmal ganz herzlich für Eure Unterstützung bedanken!

Bitte entschuldigt, dass das Thema hier etwas schleppend läuft, aber es ist wie auf der fantastischen Zeichnung auf Seite 1 dargestellt: jackyryan (Haus 2, o2-DSL) und ich (Haus 1, Vodafone-Kabelinternet) wollen beide per VPN auf das Firmennetzwerk zugreifen. Ich hoffe Ihr seht es mir nach, aber ich habe weder die Expertise noch die Zeit, um mich detailliert mit dem Thema auseinanderzusetzen. Das mach dankenswerterweise jackyryan.

Wie er oben geschrieben hat, haben wir eine Lösung mittels NCP-Client gefunden (diese Variante nutze ich in diesem Moment) und dafür zu bezahlen wäre auch kein Thema. Trotzdem ist es natürlich (vor allem für ihn) etwas unbefriedigend, dass wir nicht herausfinden konnten, was das Problem mit dem Shrew-Client ist. Für mich als Laie in Sachen Netzwerk ist es immer wieder schwer nachvollziehbar, weshalb etwas zunächst funktioniert und dann "plötzlich" nicht mehr (in meinem Fall ist wohl der PC-Wechsel dafür verantwortlich). Vielen Dank, dass Ihr uns mit Eurem Wissen helft! ​

 

[PeterPawn]

Ganz offensichtlich kann sich der Shrewsoft-Client NICHT in den Datenstrom auf dem Netzwerk-Interface einklinken - das hatte ich oben schon als denkbare Ursache aufgeführt, weil es mit anderen Netzwerk-Interfaces ja funktioniert/funktionieren soll. Nur hast Du Dir vermutlich mit der Installation eines weiteren IPSec-Clients selbst ein Ei gelegt - da reagiert der Shrewsoft-Client auch schon mal sensibel, weil i.d.R. mehrere Filter-Driver (siehe MSDN -> NDIS-Stack/Filter Driver), die sich um dieselben Pakete schlagen (hier dann halt ESP bzw. UDP 4500 bei NAT-T), eher mehr als weniger Probleme bereiten. Die zeitliche Nähe der Protokolle von beiden Versionen deutet ja eher darauf hin, daß jetzt mit zwei installierten IPSec-Clients gearbeitet wird und daß dieses selten gut geht (zumindest wenn einer davon der Shrewsoft-Client ist), kann man an mehreren Stellen im Internet nachlesen.

Die Protokolle sind am Ende auch nicht wirklich vollständig (so schön es auch ist, wenn man sich selbst um die Interpretation bemüht, so hinderlich ist das dann auch, wenn man dabei falsche Entscheidungen trifft und die wirklich relevanten Stellen letztlich gar nicht mehr zeigt - in der ipsec.log in #26 finde ich gar nichts zu den Fehlernachrichten bzgl. des vfilter-Drivers des Shrewsoft-Clients) - man kann auch nicht erkennen, ob das nun ein neues Problem ist (das mit dem Fehler beim Aktivieren des vFilter-Modules für das Senden und Empfangen auf irgendeinem Interface - das müßte m.E. in der Protokolldatei des IKED noch viel ausführlicher stehen) und damit ggf. erst durch den neu installierten NCP-Client hervorgerufen wird oder ob das von Beginn an schon ein Problem war, sich da in die Filter-Chain des Onboard-NIC einzuklinken.

Auf die alternative Implementierung (eigenes Interface für den Client, ähnlich zum TUN-/TAP-Interface bei OpenVPN u.a.) hatte ich schon hingewiesen - diese ist nicht darauf angewiesen, sich in die Filter-Chain eines anderen Interfaces einzubauen, weil da der gesamte Traffic über das (virtuelle) Interface behandelt wird und keine Notwendigkeit besteht, die Pakete "live" auf einem anderen Interface zu identifizieren, die zu ver- bzw. entschlüsseln sind, bevor ihr Inhalt einen Sinn ergibt in der weiteren Verarbeitung.

 

[jackyryan]

Meinst Du die 2 Varianten "Virtual Adapter Mode" und "Direct Adapter Mode"? In der Config ist "Virtual adapter" ausgewählt:



Trotzdem sehe ich bei den Netzwerkadaptern (cmd-r, ncpa.cpl) keinen extra virtuellen Adapter wie man es z.B. von virtuellen Maschinen gewohnt ist. Kann das sein?

Muss die Installation eines weiteren IPSec-Clients wirklich eine Sorge sein? Wenn ich den Intel-Nuc (Win11) zum erwähnten Telekom-DSL-Anschluss trage, geht es sofort über WLAN wieder. Und ich hatte ja vor der Installation getestet, es ist nach der Installation des NCP-Client weder besser noch schlechter geworden, sondern so weit ich sehen kann genau gleich geblieben. Kann den NCP auch wieder deinstallieren, aber er wird offensichtlich momentan verwendet.

Aus der ipsec.log habe ich nichts entfernt, warum fehlt dann etwas?
Zusätzlich jetzt angehängt die iked.log

Man sieht diese 3 fehlerhaften Zeilen:

21/12/26 10:32:56 !! : peer violates RFC, transform number mismatch ( 1 != 2 )
21/12/26 10:32:56 !! : invalid private netmask, defaulting to 255.255.255.0
21/12/26 10:33:04 !! : failed to remove IPSEC policy route for ANY:192.168.139.0/24:*

Zu dem Zeitpunkt war der NCP-Client schon installiert, aber es verhält sich gefühlt genau gleich wie davor.

Wie meinst Du es mit der alternativen Implementierung, soll ich meinen eigenen IPSec-Clienten programmieren? Oder gibt es alternative kostenlose VPN-Clients zur Fritzbox, die einen virtuellen Adapter installieren?
Ist der "Virtual Adapter Mode" des Shrew-Client nicht schon genau das wie hier beschrieben?
https://www.shrew.net/static/help-2.1.x/vpnhelp.htm?ClientManagement.html

 

[PeterPawn]

Wenn ich den Intel-Nuc (Win11) zum erwähnten Telekom-DSL-Anschluss trage, geht es sofort über WLAN wieder.

DAS ist schon wieder etwas, wo ich den Sinn überhaupt nicht (mehr) verstehe. Soweit ich das verstanden habe, gab es grundsätzlich nur dann Probleme, wenn der Onboard-LAN-Adapter des Intel-NUCs benutzt wurde. Wieso ist es dann "bemerkenswert" (bzw. welche Rolle spielt es), wenn das dann an einem anderen Anschluß ebenfalls über WLAN funktioniert? Vielleicht bin ich ja auch nur zu müde bzw. es ist zu lange her, daß ich das hier in der Gesamtheit gelesen habe (und ich will das nicht wiederholen, dazu habe ich gar nicht die Zeit) - aber was wäre damit denn nun bewiesen oder widerlegt? Wo ist da der Unterschied zu dem Anschluß mit dem Vodafone-Router?

Aus der ipsec.log habe ich nichts entfernt, warum fehlt dann etwas?

Woher soll ich das wissen? Die von Dir beschriebenen Zeilen:

Am Anfang einmal:
21/12/26 10:19:54 !! : vflt send device attach failed
21/12/26 10:19:54 !! : vflt recv device attach failed

finde ich jedenfalls in der ipsec.log in #26 gar nicht, die startet erst um 10:32:35 Uhr.

Ist der "Virtual Adapter Mode" des Shrew-Client nicht schon genau das wie hier beschrieben?

Ja, das wäre tatsächlich der Modus, den ich meinte. Nur verstehe ich dabei dann überhaupt nicht mehr, wie es zu den Fehlermeldungen hinsichtlich des vfilter-Treibers des Shrewsoft-Clients kommen soll. Was passiert denn auf einem anderen/älteren Windows, wenn man den Modus mit dem eigenen virtuellen Adapter wählt? Es wäre ja durchaus denkbar, daß auch dieser Modus gar nicht mehr funktioniert unter Windows 11 - auch wenn es durchaus weiterhin denkbar wäre, daß so ein Adapter (bei passenden Rechten für den verantwortlichen Prozess) nur noch dynamisch erzeugt wird.

Denn immerhin ist im Protokoll des IKE-Daemons etwas zu sehen, daß da ein Adapter ROOT\VNET\0000 aus- und eingeschaltet wird - das wird vermutlich genau dieser virtuelle Adapter sein, der in diesem Modus vom Shrewsoft-Client benötigt wird.

Die beiden Protokolle des Shrewsoft-Clients zeigen jetzt auch - anders als die, welche ich zuvor gesehen habe in diesem Thread - Datenverkehr zwischen den beiden Peers ... denn immerhin sieht man jetzt ja schon, daß überhaupt irgendwelche Antworten den PC wieder erreichen - was zuvor m.W. nie der Fall war. Wobei auch hier wieder geraten werden muß, welcher der vielen Fälle, die Du im Text beschrieben hast, denn nun mit diesen zwei (erstmals tatsächlich nachvollziehbar zusammengehörenden) Protokoll-Dateien illustriert werden soll. Jedenfalls kriegt der PC im gezeigten Log (des IKED) in Zeile 283 auch eine Antwort der FRITZ!Box auf seine Frage nach der VPN-Konfiguration (mit seiner IP-Adresse 192.168.139.128 und einer DNS-Server-Adresse) - warum dann innerhalb kürzester Zeit (nämlich innerhalb der nächsten acht Sekunden) die Verbindung wieder abgebaut wird, kann ich auch nicht erkennen.

Aber das ist es auch, was ich so gar nicht verstehen kann - einerseits beschreibst Du immer, daß sich etwas gar nicht ändert und dann zeigen die Protokolle, daß da doch etwas vollkommen anders läuft als das zuvor der Fall war und andererseits findest Du Dinge, die nach meinem Verständnis (s.o. in diesem Beitrag) längst geklärt waren, irgendwie wichtig und erwähnenswert.

So langsam habe ich offenbar vollkommen den Durchblick verloren und da sich auch Dein Problem (nachweislich!) geändert hat (denn zuvor kam gar keine Antwort der FRITZ!Box beim Shrewsoft-Client an, siehe hier: https://www.ip-phone-forum.de/attachments/lan_iked-log-txt.114174/ - da ist nicht eine einzige Zeile mit einem erfolgreich empfangenen Paket zu sehen), solltest Du den derzeitigen Stand einfach noch einmal so zusammenfassen, daß man sich mit dem Lesen eines einzigen Beitrags ein Bild machen kann und dafür nicht erst die bisherigen 29 Beiträge der Reihe nach lesen muß, wobei man dann beim Lesen eines Beitrags auch noch nicht wissen kann, ob dessen Inhalt/Erkenntnisse/Vermutungen nicht im nächsten schon wieder komplett über den Haufen geworfen werden.

Dabei spielt es sicherlich auch eine (nicht unbeachtliche) Rolle, daß ich das hier schon lange wieder verdrängt habe, denn der Thread (zumindest dessen Beginn) ist inzwischen auch schon wieder 5 Wochen her und seitdem sind hier so viele andere Probleme durchgelaufen, daß ich gar nicht mehr alle Infos präsent habe. Ich habe gerade mal spaßeshalber nachgesehen ... seit dem letzten Lebenszeichen in diesem Thread habe ich selbst (obwohl ich mittlerweile sehr zurückhaltend beim Schreiben bin) 21 Beiträge in anderen Threads verfaßt und mind. das Zehnfache an Beiträgen (das wird nicht reichen) gelesen - da KANN (und will) ich mich einfach nicht mehr in allen Einzelheiten erinnern nach so langer Zeit, wo es offenbar ja auch anders ging. Bei geeigneter Zusammenfassung (die ich dann auch verstehen kann) denke ich gerne noch weiter darüber nach.

Aber im Moment ist das für mich alles immer mehr nur ein Buch mit sieben Siegeln, weil eben Protokolle und Beschreibungen auch nur dann hilfreich sind, wenn sie zueinander passen und man auch erkennen/verstehen kann, was wozu gehört und was am Ende das "Ergebnis" war, als ein bestimmtes Protokoll erstellt wurde ... von "immer noch das Gleiche" kann ich jedenfalls beim besten Willen nichts erkennen (oder ich erinnere mich falsch und kann das mit einer neuen Zusammenfassung dann auf den aktuellen Stand korrigieren) und dann macht es ja auch keinen Sinn, wenn ich meinen Senf dazu gebe.

 

[jackyryan]

Na gut, ich versuche es nochmal (auch für Andere, die einen Tipp haben, aber sich hier nicht alles durchlesen wollen.

Zusammenfassung Stand 26.12.2021:
Es soll ein Windows 11 PC (Intel NUC11PABi3) mit einer Fritzbox 6660 mit dem Shrew-Client per VPN verbunden werden. Der Win11-PC hat einen Vodafone-Kabelanschluss über ein Touchstone TG3442DE mit lokalem IP-Bereich 192.168.0.x. Die Fritzbox 6660 ist ebenfalls über einen Vodafone-Kabelanschluss im Internet und hat den lokalen IP-Bereich 192.168.139.x.

Wenn man den Win11-PC über das LAN-Kabel mit dem Touchstone verbindet, tritt der Fehler "Negotiation timeout occured" auf. In der Support-Datei der Fritzbox sieht man

avmike:benutzer1: Phase 1 failed (responder): IKE-Error 0x2027
avmike:benutzer1: del phase 1 SA 51

Wenn man den Win11-PC über WLAN mit dem Touchstone verbindet, meldet der Shrew-Client "Tunnel enabled". In der Fritzbox 6660 - Webseite sieht man in der Übersicht anhand der LEDs, dass der Benutzer nicht verbunden ist. In der Support-Datei steht nur

avmike:benutzer1: del phase 1 SA 47

Im ipsec.log unter anderem

21/12/26 10:19:54 !! : vflt send device attach failed
21/12/26 10:19:54 !! : vflt recv device attach failed
21/12/26 10:21:55 !! : ARP packet has invalid header

und iked.log

21/12/26 10:32:56 !! : peer violates RFC, transform number mismatch ( 1 != 2 )
21/12/26 10:32:56 !! : invalid private netmask, defaulting to 255.255.255.0
21/12/26 10:33:04 !! : failed to remove IPSEC policy route for ANY:192.168.139.0/24:*

Wenn man diesen Win11-PC an einem anderen Telekom-DSL mit Digibox Smart mit dem Internet verbindet, klappt es über das LAN-Kabel ebenso wenig. Jedoch funktioniert es über WLAN. Es könnte daher am Router/Provider liegen.
Dagegen spricht, dass die Verbindung am Vodafone-Kabelanschluss zuvor mit einem Win10-PC (anderer NUC, andere Hardware) funktionierte. Daher könnte es an den Treibern/Win11 liegen.

An einem anderen Win11-PC (andere Hardware) an einem O2-DSL-Anschluss funktioniert die VPN-Verbindung zur Fritzbox 6660 sowohl über LAN-Kabel als auch WLAN problemlos. Es wurde dazu ein zweiter Benutzer in der FB eingerichtet mit selbstverständlich anderen Passwort, Secret-Key etc.

Zum Test wurde am problematischen Win11-PC versucht mit dem NCP-Client eine VPN-Verbindung zur FB aufzubauen. Diese klappt sowohl über das LAN-Kabel als auch WLAN! Aber der Vergleich hinkt, da andere Software / Treiber etc. Es zeigt aber, dass es mit bestehender Netzwerkinfrastruktur und angelegtem Benutzer in der Fritzbox möglich sein sollte.

@PeterPawn Warum ist es unsinnig an einem anderen Telekom-DSL-Anschluss zu testen? Ist doch immerhin eine Erkenntnis, dass es dort über WLAN funktioniert. Das Problem löst es natürlich nicht.
Sorry, dass es teilweise verwirrend ist, aber da ich nur sehr selten vor Ort bin, gibt es hin und wieder neue Erkenntnisse und alte waren falsch oder wurden falsch interpretiert (that's life).
Im Anhang alle 3 Protokolle, die etwa um 10:32 am 26.12. losgehen. Hierbei wurde versucht mit dem Win11-PC über WLAN eine VPN-Verbindung mit dem Shrew aufzubauen. Er meldete "Tunnel enabled" aber leider steht die Verbindung laut FB gar nicht.
Ich erwarte in diesem Forum keine vollumfängliche Analyse, schließlich kostet es hier nichts. Vielleicht klingelt es bei der ein oder anderen Fehlermeldung, die ich genannt habe. Wenn nicht, dann muss man natürlich mehr zu den Randbedingungen wissen, die ich gerne liefere (wollte jedoch keine Romane schreiben...).
Was könnte man versuchen? Anderer LAN-Treiber klappte bisher nicht. Im Touchstone-Modem/Router lässt sich kaum etwas einstellen (keine Filtermöglichkeiten, Netzwerksettings). Ein USB-LAN-Adapter scheint sich gleich wie das WLAN zu verhalten (Tunnel enabled, aber FB meldet nicht "grün").
"Virtual Adapter Mode" ist im Shrew-Client gesetzt, aber warum sieht man den Adapter nicht bei den Windows-Netzwerkadaptern (bei bestehender Verbindung)?
Vielleicht die MTU-Größe verkleinern (sollte in Windows auf 1500 stehen)?

 

[PeterPawn]

Und Du bist Dir auch sicher, daß die Protokolle untereinander (und das von Dir dazu Geschriebene) jeweils zueinander passen und auch vollständig (und original) sind?

Ich bin da etwas am Zweifeln, denn Du schreibst etwas von:

Im ipsec.log unter anderem

21/12/26 10:19:54 !! : vflt send device attach failed
21/12/26 10:19:54 !! : vflt recv device attach failed
21/12/26 10:21:55 !! : ARP packet has invalid header

, während in der Datei ipsec.log das genaue Gegenteil davon protokolliert wurde:

21/12/26 10:19:54 ## : IPSEC Daemon, ver 2.2.2
21/12/26 10:19:54 ## : Copyright 2013 Shrew Soft Inc.
21/12/26 10:19:54 ## : This product linked OpenSSL 1.0.1c 10 May 2012
21/12/26 10:19:54 ## : This product linked zlib v1.2.3
21/12/26 10:19:54 ii : network send process thread begin ...
21/12/26 10:19:54 ii : vflt send device attached
21/12/26 10:19:54 ii : network recv process thread begin ...
21/12/26 10:19:54 ii : vflt recv device attached
21/12/26 10:19:54 ii : pfkey server process thread begin ...
21/12/26 10:32:36 ii : pfkey client process thread begin ...

und bemerkenswerterweise auch alle anderen Zeilen zwischen 10:19:54 und 10:32:36 fehlen, während da nach dem oben stehenden Zitat noch mind. eine Zeile mit dem Zeitstempel 21/12/26 10:21:55 zu erwarten gewesen wäre.

Vielleicht verstehst Du ja meine Skepsis - irgendwie PASST das nun mal alles nicht so richtig zueinander und ich komme mir ein wenig "vorgeführt" vor.

---

Aber ungeachtet dessen (ich vergesse jetzt einfach mal den größten Teil der Informationen vor #31 bzw. lege den als "alt und überholt" ab) ... die Kombination der Log-Dateien (so deren Inhalt tatsächlich korrekt ist) zeigt für den 26.12.2021 um 10:32:56 Uhr einen Verbindungsversuch durch den Shrewsoft-Client (den nenne ich ab sofort nur noch "SC") über den eigenen virtuellen Netzwerk-Adapter (so interpretiere ich zumindest die Verwendung des Adapters ROOT\VNET\0000, die in der iked.log zu sehen ist), bei dem die Phase 1 des IKE-Prozesses tatsächlich erfolgreich abgeschlossen wurde (und zwar inkl. XAUTH und Config-Pull durch den SC).

Entgegen meiner Empfehlung hier:

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.

wird dabei (zumindest nach meiner Interpretation der Zeilen:

21/12/26 10:32:56 DB : new phase1 ( ISAKMP initiator )
21/12/26 10:32:56 DB : exchange type is aggressive
21/12/26 10:32:56 DB : 192.168.0.203:500 <-> 134.3.166.55:500
21/12/26 10:32:56 DB : 956c86b30b6c629c:0000000000000000
21/12/26 10:32:56 DB : phase1 ref increment ( ref count = 1, obj count = 0 )
21/12/26 10:32:56 DB : phase1 added ( obj count = 1 )
21/12/26 10:32:56 >> : security association payload
21/12/26 10:32:56 >> : - proposal #1 payload 
21/12/26 10:32:56 >> : -- transform #1 payload 
21/12/26 10:32:56 >> : -- transform #2 payload 
21/12/26 10:32:56 >> : -- transform #3 payload 
21/12/26 10:32:56 >> : -- transform #4 payload 
21/12/26 10:32:56 >> : -- transform #5 payload 
21/12/26 10:32:56 >> : -- transform #6 payload 
21/12/26 10:32:56 >> : -- transform #7 payload 
21/12/26 10:32:56 >> : -- transform #8 payload 
21/12/26 10:32:56 >> : -- transform #9 payload 
21/12/26 10:32:56 >> : -- transform #10 payload 
21/12/26 10:32:56 >> : -- transform #11 payload 
21/12/26 10:32:56 >> : -- transform #12 payload 
21/12/26 10:32:56 >> : -- transform #13 payload 
21/12/26 10:32:56 >> : -- transform #14 payload 
21/12/26 10:32:56 >> : -- transform #15 payload 
21/12/26 10:32:56 >> : -- transform #16 payload 
21/12/26 10:32:56 >> : -- transform #17 payload 
21/12/26 10:32:56 >> : -- transform #18 payload 
21/12/26 10:32:56 >> : key exchange payload
21/12/26 10:32:56 >> : nonce payload
21/12/26 10:32:56 >> : identification payload
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports XAUTH
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v00 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v01 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v02 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v03 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( rfc )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports FRAGMENTATION
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports DPDv1
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is SHREW SOFT compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is NETSCREEN compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is SIDEWINDER compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is CISCO UNITY compatible
21/12/26 10:32:56 >= : cookies 956c86b30b6c629c:0000000000000000
21/12/26 10:32:56 >= : message 00000000
21/12/26 10:32:56 -> : send IKE packet 192.168.0.203:500 -> 134.3.166.55:500 ( 1203 bytes )

, die nicht zwingend korrekt sein muß - zur Prüfung dieser Aussage müßte ich erst selbst den SC irgendwo installieren und das testen, wozu ich aber gar keine Veranlassung habe), weiterhin ein "bunter Strauß" an Melodien für die Verschlüsselung/Transformation in P1 angeboten - was auch dieses initiale Paket schon auf 1203 Byte aufpustet, obwohl nach früheren Screenshots (https://www.ip-phone-forum.de/attachments/1638014336442-png.114078/) für P1 eigentlich eine maximale Paketgröße von 540 Bytes eingestellt sein soll (die Einstellungen auf dieser Registerkarte beziehen sich alle auf Optionen, die in P1 von IKE/ISAKMP eine Rolle spielen).

Aber das geht dann offenbar auch noch gut ... offensichtlich wird dabei die MTU der (physikalischen) Verbindung zwischen den Peers noch nicht überschritten. Jedenfalls kommt es - trotz offensichtlicher Mißverständnisse zwischen den Peers:

21/12/26 10:32:56 <- : recv IKE packet 134.3.166.55:500 -> 192.168.0.203:500 ( 472 bytes )
21/12/26 10:32:56 DB : phase1 found
21/12/26 10:32:56 DB : phase1 ref increment ( ref count = 2, obj count = 1 )
21/12/26 10:32:56 ii : processing phase1 packet ( 472 bytes )
21/12/26 10:32:56 =< : cookies 956c86b30b6c629c:200d36ea41c80bbb
21/12/26 10:32:56 =< : message 00000000
21/12/26 10:32:56 << : security association payload
21/12/26 10:32:56 << : - propsal #1 payload 
21/12/26 10:32:56 << : -- transform #1 payload 
21/12/26 10:32:56 ii : unmatched isakmp proposal/transform
21/12/26 10:32:56 ii : hash type ( hmac-sha1 != hmac-md5 )
21/12/26 10:32:56 !! : peer violates RFC, transform number mismatch ( 1 != 2 )
21/12/26 10:32:56 ii : matched isakmp proposal #1 transform #1
21/12/26 10:32:56 ii : - transform    = ike
21/12/26 10:32:56 ii : - cipher type  = aes
21/12/26 10:32:56 ii : - key length   = 256 bits
21/12/26 10:32:56 ii : - hash type    = sha1
21/12/26 10:32:56 ii : - dh group     = group2 ( modp-1024 )
21/12/26 10:32:56 ii : - auth type    = xauth-initiator-psk
21/12/26 10:32:56 ii : - life seconds = 86400
21/12/26 10:32:56 ii : - life kbytes  = 0
21/12/26 10:32:56 << : key exchange payload
21/12/26 10:32:56 << : nonce payload
21/12/26 10:32:56 << : identification payload
21/12/26 10:32:56 ii : phase1 id match ( natt prevents ip match )
21/12/26 10:32:56 ii : received = ipv4-host 134.3.166.55
21/12/26 10:32:56 << : hash payload
21/12/26 10:32:56 << : notification payload
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports XAUTH
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports DPDv1
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( rfc )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( draft v02 )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( draft v03 )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : unknown vendor id ( 16 bytes )
21/12/26 10:32:56 0x : a2226fc3 64500f56 34ff77db 3b74f41b
21/12/26 10:32:56 << : nat discovery payload
21/12/26 10:32:56 << : nat discovery payload
21/12/26 10:32:56 ii : nat discovery - local address is translated
21/12/26 10:32:56 ii : switching to src nat-t udp port 4500
21/12/26 10:32:56 ii : switching to dst nat-t udp port 4500
21/12/26 10:32:56 == : DH shared secret ( 128 bytes )
21/12/26 10:32:56 == : SETKEYID ( 20 bytes )
21/12/26 10:32:56 == : SETKEYID_d ( 20 bytes )
21/12/26 10:32:56 == : SETKEYID_a ( 20 bytes )
21/12/26 10:32:56 == : SETKEYID_e ( 20 bytes )
21/12/26 10:32:56 == : cipher key ( 32 bytes )
21/12/26 10:32:56 == : cipher iv ( 16 bytes )
21/12/26 10:32:56 == : phase1 hash_i ( computed ) ( 20 bytes )
21/12/26 10:32:56 >> : hash payload
21/12/26 10:32:56 >> : nat discovery payload
21/12/26 10:32:56 >> : nat discovery payload
21/12/26 10:32:56 >= : cookies 956c86b30b6c629c:200d36ea41c80bbb
21/12/26 10:32:56 >= : message 00000000
21/12/26 10:32:56 >= : encrypt iv ( 16 bytes )
21/12/26 10:32:56 == : encrypt packet ( 100 bytes )
21/12/26 10:32:56 == : stored iv ( 16 bytes )
21/12/26 10:32:56 DB : phase1 resend event canceled ( ref count = 1 )
21/12/26 10:32:56 -> : send NAT-T:IKE packet 192.168.0.203:4500 -> 134.3.166.55:4500 ( 140 bytes )
21/12/26 10:32:56 == : phase1 hash_r ( computed ) ( 20 bytes )
21/12/26 10:32:56 == : phase1 hash_r ( received ) ( 20 bytes )
21/12/26 10:32:56 ii : phase1 sa established
21/12/26 10:32:56 ii : 134.3.166.55:4500 <-> 192.168.0.203:4500
21/12/26 10:32:56 ii : 956c86b3b6c629c:200d36ea41c80bbb

noch zu einer Einigung (zumindest aus Sicht des SC, wobei der weitere Traffic zeigt, daß die FB das ähnlich sieht) auf AES256/SHA1/DH2 + XAUTH mit PSK für eine SA und der SC setzt den Prozess danach mit einer "initial contact"-Message fort:

21/12/26 10:32:56 ii : sending peer INITIAL-CONTACT notification
21/12/26 10:32:56 ii : - 192.168.0.203:4500 -> 134.3.166.55:4500
21/12/26 10:32:56 ii : - isakmp spi = 956c86b30b6c629c:200d36ea41c80bbb
21/12/26 10:32:56 ii : - data size 0
21/12/26 10:32:56 >> : hash payload
21/12/26 10:32:56 >> : notification payload
21/12/26 10:32:56 == : new informational hash ( 20 bytes )
21/12/26 10:32:56 == : new informational iv ( 16 bytes )
21/12/26 10:32:56 >= : cookies 956c86b30b6c629c:200d36ea41c80bbb
21/12/26 10:32:56 >= : message 72079e0b
21/12/26 10:32:56 >= : encrypt iv ( 16 bytes )
21/12/26 10:32:56 == : encrypt packet ( 80 bytes )
21/12/26 10:32:56 == : stored iv ( 16 bytes )
21/12/26 10:32:56 -> : send NAT-T:IKE packet 192.168.0.203:4500 -> 134.3.166.55:4500 ( 124 bytes )

, mit der die Gegenseite veranlaßt wird, alle event. noch vorhandenen Reste einer vorhergehenden Verbindung (übrig gebliebene, aber noch gültige SA und Transformationen) zu vergessen, damit tatsächlich die neue Verbindung "sauber" etabliert werden kann.

In der Folge tauschen die Peers dann noch ein paar weitere Nachrichten aus, um die in P1 noch erforderlichen Aktionen (XAUTH, Client-Konfiguration) abzuschließen, was hier dann beendet ist:

21/12/26 10:32:56 ii : received config pull response
21/12/26 10:32:56 ii : - IP4 Address = 192.168.139.128
21/12/26 10:32:56 ii : - IP4 DNS Server
21/12/26 10:32:56 DB : config resend event canceled ( ref count = 1 )
21/12/26 10:32:56 DB : config ref decrement ( ref count = 0, obj count = 1 )
21/12/26 10:32:56 DB : phase1 ref decrement ( ref count = 3, obj count = 1 )
21/12/26 10:32:56 !! : invalid private netmask, defaulting to 255.255.255.0
21/12/26 10:32:56 ii : enabled adapter ROOT\VNET\0000 
21/12/26 10:32:56 ii : apapter ROOT\VNET\0000 MTU is 1380

und wo in der Folge dann der virtuelle Netzwerk-Adapter entsprechend (mit den empfangenen Angaben) konfiguriert wird - mit der lokalen IP-Adresse 192.168.139.128 (die auch schon "komisch" ist und eher auf heftig geänderte Einstellungen in der FB hinweist, die m.W. bisher auch noch nirgendwo Erwähnung fanden).

Die Feststellung, daß die FB keine Netzwerkmaske mitgesendet hat (obwohl sie zuvor vom SC angefordert wurde), spielt letztlich auch keine entscheidende Rolle, solange die vom SC angenommene Maske zu der paßt, die in der FB konfiguriert wurde (solange das niemand geändert hat, ist das i.d.R. auch eine /24-Maske). Danach werden entsprechende Filter/Transformationen und Routen gesetzt (21/12/26 10:32:56 ii : created IPSEC policy route for 192.168.139.0/24, was in der ipsec.log mit 21/12/26 10:32:56 ii : installed divert rule for 192.168.139.0/255.255.255.0 auftaucht), die dafür sorgen sollen, daß der Traffic zu den Adressen 192.168.139.0/24 nur noch über das verschlüsselnde Interface geht (der "eingepackte" Traffic geht zu bzw. kommt dann von der öffentlichen IP-Adresse der FB) - das wird dann in weiteren Einzelheiten (SPDADD/SPDDELETE) in der ipsec.log protokolliert.

Danach ist P1 für den SC dann beendet und er beginnt (aus seiner Sicht) mit P2:

21/12/26 10:33:00 DB : new phase2 ( IPSEC initiator )
21/12/26 10:33:00 DB : phase2 ref increment ( ref count = 1, obj count = 0 )
21/12/26 10:33:00 DB : phase2 added ( obj count = 1 )
21/12/26 10:33:00 K> : send pfkey GETSPI ESP message
21/12/26 10:33:00 DB : phase2 ref decrement ( ref count = 0, obj count = 1 )
21/12/26 10:33:00 DB : tunnel ref decrement ( ref count = 7, obj count = 1 )
21/12/26 10:33:00 DB : policy ref decrement ( ref count = 0, obj count = 6 )
21/12/26 10:33:00 DB : policy ref decrement ( ref count = 0, obj count = 6 )
21/12/26 10:33:00 K< : recv pfkey GETSPI ESP message
21/12/26 10:33:00 DB : phase2 found
21/12/26 10:33:00 DB : phase2 ref increment ( ref count = 1, obj count = 1 )
21/12/26 10:33:00 ii : updated spi for 1 ipsec-esp proposal
21/12/26 10:33:00 DB : phase1 found
21/12/26 10:33:00 DB : phase1 ref increment ( ref count = 4, obj count = 1 )
21/12/26 10:33:00 >> : hash payload
21/12/26 10:33:00 >> : security association payload
21/12/26 10:33:00 >> : - proposal #1 payload 
21/12/26 10:33:00 >> : -- transform #1 payload 
21/12/26 10:33:00 >> : -- transform #2 payload 
21/12/26 10:33:00 >> : -- transform #3 payload 
21/12/26 10:33:00 >> : -- transform #4 payload 
21/12/26 10:33:00 >> : -- transform #5 payload 
21/12/26 10:33:00 >> : -- transform #6 payload 
21/12/26 10:33:00 >> : -- transform #7 payload 
21/12/26 10:33:00 >> : -- transform #8 payload 
21/12/26 10:33:00 >> : -- transform #9 payload 
21/12/26 10:33:00 >> : -- transform #10 payload 
21/12/26 10:33:00 >> : -- transform #11 payload 
21/12/26 10:33:00 >> : -- transform #12 payload 
21/12/26 10:33:00 >> : -- transform #13 payload 
21/12/26 10:33:00 >> : -- transform #14 payload 
21/12/26 10:33:00 >> : -- transform #15 payload 
21/12/26 10:33:00 >> : -- transform #16 payload 
21/12/26 10:33:00 >> : -- transform #17 payload 
21/12/26 10:33:00 >> : -- transform #18 payload 
21/12/26 10:33:00 >> : -- transform #19 payload 
21/12/26 10:33:00 >> : -- transform #20 payload 
21/12/26 10:33:00 >> : -- transform #21 payload 
21/12/26 10:33:00 >> : -- transform #22 payload 
21/12/26 10:33:00 >> : -- transform #23 payload 
21/12/26 10:33:00 >> : -- transform #24 payload 
21/12/26 10:33:00 >> : -- transform #25 payload 
21/12/26 10:33:00 >> : -- transform #26 payload 
21/12/26 10:33:00 >> : -- transform #27 payload 
21/12/26 10:33:00 >> : -- transform #28 payload 
21/12/26 10:33:00 >> : -- transform #29 payload 
21/12/26 10:33:00 >> : -- transform #30 payload 
21/12/26 10:33:00 >> : -- transform #31 payload 
21/12/26 10:33:00 >> : -- transform #32 payload 
21/12/26 10:33:00 >> : -- transform #33 payload 
21/12/26 10:33:00 >> : -- transform #34 payload 
21/12/26 10:33:00 >> : -- transform #35 payload 
21/12/26 10:33:00 >> : -- transform #36 payload 
21/12/26 10:33:00 >> : -- transform #37 payload 
21/12/26 10:33:00 >> : -- transform #38 payload 
21/12/26 10:33:00 >> : -- transform #39 payload 
21/12/26 10:33:00 >> : -- transform #40 payload 
21/12/26 10:33:00 >> : -- transform #41 payload 
21/12/26 10:33:00 >> : -- transform #42 payload 
21/12/26 10:33:00 >> : -- transform #43 payload 
21/12/26 10:33:00 >> : -- transform #44 payload 
21/12/26 10:33:00 >> : -- transform #45 payload 
21/12/26 10:33:00 >> : nonce payload
21/12/26 10:33:00 >> : identification payload
21/12/26 10:33:00 >> : identification payload
21/12/26 10:33:00 == : phase2 hash_i ( input ) ( 1460 bytes )
21/12/26 10:33:00 == : phase2 hash_i ( computed ) ( 20 bytes )
21/12/26 10:33:00 == : new phase2 iv ( 16 bytes )
21/12/26 10:33:00 >= : cookies 956c86b30b6c629c:200d36ea41c80bbb
21/12/26 10:33:00 >= : message bc28be05
21/12/26 10:33:00 >= : encrypt iv ( 16 bytes )
21/12/26 10:33:00 == : encrypt packet ( 1508 bytes )
21/12/26 10:33:00 == : stored iv ( 16 bytes )
21/12/26 10:33:00 -> : send NAT-T:IKE packet 192.168.0.203:4500 -> 134.3.166.55:4500 ( 1548 bytes )
21/12/26 10:33:00 ii : fragmented packet to 1514 bytes ( MTU 1500 bytes )
21/12/26 10:33:00 ii : fragmented packet to 82 bytes ( MTU 1500 bytes )
21/12/26 10:33:00 DB : phase2 resend event scheduled ( ref count = 2 )
21/12/26 10:33:00 DB : phase1 ref decrement ( ref count = 3, obj count = 1 )
21/12/26 10:33:00 DB : phase2 ref decrement ( ref count = 1, obj count = 1 )
21/12/26 10:33:04 ii : hard halt signal received, shutting down

Auch hierbei bietet der SC wieder sinnloserweise eine riesige Auswahl an möglichen Transformationen an - das ist in etwa so, als würde im Restaurant dem Stammgast, der seit 10 Jahren einmal pro Woche kommt, um sich ein Schnitzel mit Pommes zu genehmigen, erst noch die komplette Menü-Karte vorgesungen, bevor er seine Bestellung aufgeben darf.

Das führt dann auch gleich dazu, daß dieser ganze Müll gar nicht mehr in ein einzelnes Paket paßt und dieses in zwei Pakete zerlegt werden muß, obwohl der IPSec-Server der FB mit keinem Wort (bzw. Flag) zu erkennen gab, daß er mit einer Fragmentierung einverstanden wäre - beim SC gibt es dafür (im oben schon verlinkten Screenshot etwas verdeckt) eine gesonderte Einstellung.

21/12/26 10:32:56 << : notification payload
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports XAUTH
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports DPDv1
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( rfc )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( draft v02 )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : peer supports nat-t ( draft v03 )
21/12/26 10:32:56 << : vendor id payload
21/12/26 10:32:56 ii : unknown vendor id ( 16 bytes )
21/12/26 10:32:56 0x : a2226fc3 64500f56 34ff77db 3b74f41b

Ich sehe hier jedenfalls kein Anzeichen dafür, daß die FB IKE-Fragmentierung unterstützen würde, während das der SC für sich selbst doch deutlich annonciert hat im allerersten P1-Paket:

21/12/26 10:32:56 >> : identification payload
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports XAUTH
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v00 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v01 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v02 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( draft v03 )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports nat-t ( rfc )
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports FRAGMENTATION
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local supports DPDv1
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is SHREW SOFT compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is NETSCREEN compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is SIDEWINDER compatible
21/12/26 10:32:56 >> : vendor id payload
21/12/26 10:32:56 ii : local is CISCO UNITY compatible

Ich weiß halt auch nicht, was die tatsächliche Ursache für die letzte weiter oben noch gezeigte Reaktion (hard halt signal received) ist, aber ich könnte mir sehr gut vorstellen, daß die FB nicht bereit ist, sich bei der Schlüsselaushandlung auch noch mit fragmentierten Paketen herumschlagen zu müssen, nur weil sich die Gegenstelle nicht entscheiden kann und so viel Unsinn sendet, daß der (ersichtlich) nicht mehr in ein einzelnes Paket paßt und für eine Verarbeitung des vollständigen Pakets auf ihrer Seite erst wieder die gesendeten Fragmente aggregiert werden müßten.

---

Dabei lasse ich aber durchaus noch weitere "Merkwürdigkeiten" weg - warum der PC plötzlich einen ARP-Request für eine Adresse 192.168.139.103 erhält und den dann "spooft" (also vermutlich mit seiner eigenen MAC-Adresse antwortet, weil er das Gateway zu diesem Netz wäre), obwohl seine eigene IP-Adresse doch 192.168.139.128 wäre (für welche er ARP-Requests aber lt. Protokoll fleißig ignoriert), verstehe ich jedenfalls auch nicht so wirklich - dazu bräuchte es aber vermutlich auch den Mitschnitt des Netzwerk-Verkehrs auf dem PC, weil für mich nicht mal klar ist, ob die ARP-Requests von "local" kommen (was eigentlich zu erwarten wäre, denn ARP wird grundsätzlich nicht geroutet und daher KANN der eigentlich nicht von der FB kommen) oder doch durch ankommende IPSec-Pakete (von der FB) verursacht wurde, für die jetzt der passende lokale Empfänger (das wäre ja das lokale virtuelle Interface des SC) gesucht wird.

 

[kleinkariert]

Was war eigentlich der Grund, den AVM-Client nicht zu testen?

 

[jackyryan]

Vielen Dank für Deine Analyse!
Ich will dich nicht vorführen, es ärgert mich selbst, dass ich nur eine Stunde vor Ort war und jetzt mit dem Leben muss, was ich aufgenommen habe.
Dummerweise beginnt die ipsec.log um 10:19. Damit es nicht verwirrt habe ich den ersten Teil (außer die allerersten Botschaften) entfernt bis 10:32 und dadurch fehlen die genannten Zeilen mit vflt send device attach failed. Der Schuss ist nach hinten losgegangen und es verwirrt noch mehr. Aber ich kann leider gerade keinen sauberen neuen Trace aufnehmen, ich bin nicht dort (sonst wäre das auch einfacher).

Den AVM-Client konnten wir ursprünglich nicht verwenden, weil der Win10-PC als 32bit installiert war und der läuft nur unter 64bit. Jetzt beim Win11-PC geht es, da 64bit. Aber nach Kontakt mit dem AVM-Support wurde mir bestätigt, dass dieser keine DNS-Namensauflösung ("Split-DNS") unterstützt. Im Wissensdokument 48 steht auch:
https://avm.de/service/wissensdaten...ung-auf-Datei-und-Druckerfreigaben-zugreifen/

Um über eine VPN-Verbindung auf freigegebene Bibliotheken, Dateien und Drucker im entfernten Netzwerk zuzugreifen, nutzen Sie die IP-Adressen der jeweiligen Computer.

Das ist unschön, weil sämtliche installierte Programme und Netzlaufwerke mit den UNC-Namen arbeiten. Als Lösung wurde mir der Shrew-Client (müsste irgendwie laufen) oder der NCP-Client (nicht kostenlos) empfohlen.

Die ominöse 192.168.139.103 ist der lokale DNS-Server im Fritzbox 6660-Netz, d.h. der DNS (und auch DHCP) in der Fritzbox ist deaktiviert. Das hat aber laut AVM-Support nichts mit dem nicht vorhandenen Split-DNS zu tun, sondern das ist einfach nicht implementiert (und mir wurde auch nicht gesagt, wann die "Lust" hätten das mal zu machen).

Kann man das mit den Transformationen irgendwie beschränken, so dass es nicht zur Fragmentierung kommt? Oder warum ist sich der SC sicher, dass "local" Fragmentierung unterstützt, wenn das die FB offensichtlich nicht will?

 

[PeterPawn]

Oder warum ist sich der SC sicher, dass "local" Fragmentierung unterstützt, wenn das die FB offensichtlich nicht will?

"local" ist nun mal der SC und was Du da einstellst, sendet der dann halt auch zum Peer - warum der dann der FB in P2 Pakete anbietet, welche die für den VNET-Adapter eingestellte MTU überschreiten (das wären 1380 Bytes lt. Log), weiß ich auch nicht ... allerdings ist eben auch P2 noch Traffic zwischen den Peers und keiner, der schon durch den "Tunnel" (bzw. über das VNET-Interface) gehen würde. Aber die MTU spielt hier ohnehin schon keine Geige mehr, da die Paketgröße ja deutlich jenseits JEDER denkbaren MTU für die Verbindung zwischen den Peers liegt mit 1548 Bytes reinem Payload (da kommen ja noch die Header für die darunter liegenden Schichten dazu).

Kann man das mit den Transformationen irgendwie beschränken

Klar kann man das - sonst hätte ich das ja nicht schon vor fünf Wochen empfohlen. Dazu dienen die anderen Registerkarten in dem Dialog, dessen Screenshot (von Dir "gezeigt") in #33 von mir verlinkt wurde.

Überall AES256 mit SHA1 (sicher, aber rechenintensiv und m.W. bei der 6660 ohne Hardware-Beschleunigung) eingestellt und für P1 noch DH2 (andere Gruppen KANN die FRITZ!Box meines Wissens und nach meinen Tests in P1 nicht) und es sollte jeweils nur noch ein Vorschlag im Paket enthalten sein (was vermutlich auch gleich noch die Fehlernachrichten zu den Mißverständnissen in P1 beseitigen wird). Wobei man berücksichtigen muß, daß die FB wohl für Verbindungen mit conntype_user kein PFS unterstützt - also darf man das (bei dieser Art von Verbindung) auch nicht für P2 konfigurieren (hier: https://www.ip-phone-forum.de/threads/strongswan-linux-als-vpn-client-für-einen-fritz-os-benutzeraccount.309500/post-2413592 habe ich das bei der Kopplung eines strongSwan-Clients an die FB näher erklärt).

---

Nur ergibt das mit ziemlicher Sicherheit auch dann schon eine vollkommen andere Situation, wenn es immer noch nicht richtig funktionieren sollte - aber da helfen dann eben auch keine alten Protokolle, die man "von Hand" zusammenstellt, sondern nur die tatsächlichen, jeweils aktuellen Protokolle für den Verbindungsversuch ... und auch die bitte wieder "von beiden Seiten", damit man auch sehen kann, welches Paket von der einen Seite da welche Reaktionen auf der anderen bewirkte.

Das Zugeben des Fehlens "echter" Protokolle ist jedenfalls immer noch deutlich sinnvoller, als das Zurechtbiegen vorhandener Fragmente ... denn so richtig habe ich immer noch nicht verstanden, wie aus einem vflt send device attach failed ein vflt send device attached mit demselben Zeitstempel werden kann. Das ist dann entweder ein anderes Interface, wo dieser Fehler auftrat oder halt "schlecht geschönt" ... denn ein "attached" ist deutlich etwas anderes als "trying to attach" und bedeutet eigentlich, daß der Vorgang (erfolgreich) abgeschlossen wurde - warum sollte der jetzt innerhalb derselben Sekunde plötzlich wieder fehlschlagen (für dasselbe Interface)?

Wenn man keine aktuellen Protokolle hat, muß man sie eben neu erstellen (lassen) ... auch wenn man dann in der Konsequenz vielleicht mal 24 Stunden länger warten muß, bevor man seinen nächsten Beitrag schreiben kann.

 

[PeterPawn]

Da hier seit 17 Tagen nichts Neues mehr zu lesen ist, vermute ich einfach mal, daß das Problem dann auch gelöst werden konnte - wo und wie genau, werden wir dann wohl nicht mehr erfahren.

 

[jackyryan]

Leider falsch vermutet, es gibt meines Wissens nichts Neues. Ich bin leider nicht vor Ort und unterstütze lediglich auf Anforderung. Da ich nichts gehört habe bis heute, wird vermutlich der NCP-Client weiterhin verwendet.
Mich persönlich würde es auch interessieren, ob man's weiter eingrenzen kann und wo die Ursache liegt. Sobald es was Neues gibt schreibe ich es hier gerne.

 

[PeterPawn]

Danke für die Info. Das Bemerkenswerte an DIESEM Problem war/ist es ja, daß es (a) das erste Mal mit Windows 11 ist (soweit ich das richtig verfolgt habe) und (b) auf Probleme mit einem bestimmten Netzwerk-Adapter beschränkt war (wenn die Aussagen hinsichtlich des USB-Adapters am Intel-NUC noch stimmen).

 

[jackyryan]

Das stimmt, dennoch funktioniert die VPN-Verbindung mit Shrew prinzipiell an einem anderen Win11-PC. Und mit einem DLink-USB-Ethernet - Adapter meldet Shrew zwar "Connection established" aber wie geschildert steht die Verbindung nicht laut Fritzbox und tut auch nicht. Und der ISP hat auch einen Einfluss, da es per WLAN an anderem Telekom-DSL funktioniert.
Es gibt mehrere Stellschrauben und Testmöglichkeiten. Leider wurde bisher nicht alles (Gegen-) Getestet und nicht vollständig dokumentiert. Vielleicht bin ich mal wieder vor Ort und kann das dann nachholen. Solange werden wir wohl in dieser Sache nicht schlauer werden

 

[KluthR]

Hi,

ich weiß nicht, ob ich das exakte Problem habe - aber mit ner 7490 un VPN auf dem iPhone habe ich die selben Fehler:

2021-11-01 16:21:59 avmike:<<< identity protection mode[80.187.117.153] ???: V1.0 848 IC 30ebdc1b5d8eb230 RC 00000000 0000 SA flags= 2021-11-01 16:21:59 avmike:no phase1ss for cert users configured 2021-11-01 16:21:59 avmike:80.187.117.153:500: new_neighbour_template failed

Via Wireshark sieht man, dass die Pakete eingehen aber keins zurückgeschickt wird.

Dazu meinte AVM nach ein paar Tests: Inkonsistente Einstellungen meiner FB, bitte Reset versuchen. Neu aufgesetzt: selbes Problem. Mal sehen, was jetzt kommt.

Zur Info.