[Gelöst] VPN FritzFernzugang geht nicht mehr nach Routerwechsel

[wglan]

Und hier noch das ike.log von einem erfolgreichen FritzFernzugang von meinem Laptop daheim zur gleichen Fritzbox 7590 (X). Mein Laptop hängt an einer FB7590. Die Konfig-Daten für den Fernzugang auf meinen Laptop sind identisch zu den Konfig-Daten im Laptop an der FB6591 bis auf die andere Mail-Adresse. Das analoge gilt für die Konfig-Daten in der FB7590 (X).

 

[Micha0815]

jenni... ist der FB als userIn wohl nicht bekannt. ihap... wohl schon.
LG

 

[wglan]

Kann nicht sein, denn wenn ich den Laptop, der sich mit Jenni einwählt, bei mit daheim an meine FB7590 anschließe, geht der Verbindungsaufbau zur FB7590 (X) einwandfrei.

 

[Alex_P]

Viele Wege führen nach Rom.
Lässt sich nicht die RDP direkt über IPv6 aufbauen? Dann wäre VPN Verbindung überflüssig.

 

[Micha0815]

Sorry. Ich hatte die logs nur kurz auf dem Handy geöffnet und voreilig übersehen, dass Du wohl mit 2 Accounts (VPN-UserInnen) an unterschiedlichen Orten hantierst. Ohne den zeitnahen Log der 7590 am Ort X wird es schwer, die Gründe näher zu verstehen, weshalb und woran es scheitert.

Allerdings wenn ich

Dabei bekomme ich eine VPN Verbindung zur Fritzbox (X), egal ob ich bei mir daheim über meine FB7590 oder bei meiner Bekannten an der FB 65901 die Verbindung aufbaue

mit

denn wenn ich den Laptop, der sich mit Jenni einwählt, bei mit daheim an meine FB7590 anschließe, geht der Verbindungsaufbau zur FB7590 (X) einwandfrei

abgleiche, erscheint das bereits von PeterPawn erwähnte MTU-Problem am wahrscheinlichsten.
Nach welcher Anleitung/Vorlage hast Du denn den Shrewsoft-Client eingerichtet?
LG

 

[wglan]

Hallo Micha,
die Logs sind von der Fritzbox am Ort X während der Einwahl. Die Einwahl ist immer erfolgreich (FritzFernzugang oder Shrew), wenn ich sie an einem der beiden Laptops an meiner FB7590 starte und sie ist nie erfolgreich, wenn ich die Laptops (ansonsten unverändert) an die FB6591 hänge.
Shrew habe ich nach den Vorgaben von AVM eingerichtet. Die MTU-Size ist 1380, wie sie bei der Einrichtung voreingestellt wurde, Der Wert kommt dem Vorschlag von PeterPawn sehr nahe. Ich habe ihn deshalb nicht mehr geändert.

Ich habe inzwischen noch einen Eintrag gefunden mit vergleichbaren Symptomen wie beim meinem fehlerhaften Zugang an der FB6591, leider ohne Lösung:

Shrew Client baut VPN mit FritzBox auf aber ohne Zugriffsmöglichkeit auf das LAN

Moin moin! Ich versuche, eine Client-VPN-Verbindung mit Shrew-Soft-Client 2.2.2 aus Win 7 Pro zu einer FritzBox 7490 aufzubauen. Der Tunnel ist ...

administrator.de

 

[PeterPawn]

Was soll der Test mit zwei verschiedenen VPN-Clients? Wenn man sich eben gerade nicht auf "trial & error" verlegen will, dann nimmt man EINEN VPN-Client, der für den gewählten Einsatzzweck definitiv funktioniert (und das dachte ich in #36 im mittleren Absatz deutlich genug gemacht zu haben) und versucht, seine eigenen Fehler bei dessen Einsatz zu korrigieren, anstatt wild zwischen unterschiedlichen Programmen zu wechseln in der Hoffnung, daß es mit einem davon (und dann mehr oder minder nur zufällig, weil man die Ursachen gar nicht versteht) irgendwie doch noch funktionieren könnte.

Im Protokoll in #40 sieht man jedenfalls schon mal, daß mit beiden VPN-Clients (ich hoffe mal inständig, daß Du die nicht wirklich beide auf DEMSELBEN PC installiert hast - an eine Deinstallation und
Installation kann ich innerhalb von 30 Sekunden eigentlich nicht so richtig glauben, daher sind das hoffentlich zwei unterschiedliche PCs) ein VerbindungsVERSUCH bei der FRITZ!Box ankommt.

Obendrein sind diese Versuche aber auch noch ineinander verschachtelt ... um 15:40:55 Uhr, wo schon der Versuch für den Account mit der E-Mail-Adresse läuft, kommt noch einmal ein (ggf. auch nur wiederholtes) Paket für "vpnuser" an und das trifft dann auf den Umstand, daß die zugehörige SA schon um 15:39:55 Uhr von der FRITZ!Box wieder abgeräumt wurde.

Wenn Du also tatsächlich den Shrewsoft-Client gestoppt hast, bevor der Versuch mit dem AVM-Client begann und das auch noch auf Erfolg geprüft hast ... woher stammt dann bitte das Paket um 15:40:55 Uhr für diesen VPN-Account? Den Rest der Datei aus #40 kann man dann in der Pfeife rauchen ... weil der (auf gar keinen Fall wirklich gestoppte) Shrewsoft-Client ständig nur noch Pakete wiederholt, mit denen die FRITZ!Box aber gar nichts anfangen kann (Error 0x1C -> https://service.avm.de/help/de/FRITZ-Box-7590/019p2/hilfe_syslog_122), weil sie den Start der Verbindung bereits um 15:39:55 Uhr ABGEBROCHEN hat.

Damit sind aber schon mal alle anderen Spekulationen, daß es irgendwie an einer "Nichterreichbarkeit" liegen könnte, Geschichte (oder sie sollten es zumindest sein, wenn man die Zusammenhänge verstanden hat).

Angesichts dieser Umstände (es gibt noch weitere "Indizien", auf die ich gleich noch eingehe) halte ich es jedenfalls für sehr, [ , sehr ] (...) unwahrscheinlich, daß diese Aussage:

Die Verbindung kam zustande

korrekt ist. Denn zum Aufbau einer FUNKTIONIERENDEN IPSec-Verbindung gehören zwei Phasen (üblicherweise als P1 und P2 bezeichnet) und P2 sähe für eine VPN-Verbindung, wie sie bei Dir offensichtlich auch verwendet wird, dann ungefähr so aus (kriegt man nebenbei bemerkt auch problemlos selbst heraus, wenn man mal den auch wirklich erfolgreichen Verbindungsaufbau gegen eine FRITZ!Box in der Protokoll-Datei ansieht):

2022-02-24 04:24:26 avmike:<<<  aggressive mode[<ip_of_peer>:62503] ???: V1.0 367 IC ad291587e09db0f8 RC 00000000 0000 SA flags=
2022-02-24 04:24:26 avmike:aggressive mode username: selected lifetime: 3600 sec(no notify)
2022-02-24 04:24:26 avmike:username receive VENDOR ID Payload: XAUTH
2022-02-24 04:24:26 avmike:username receive VENDOR ID Payload: DPD
2022-02-24 04:24:26 avmike:username receive VENDOR ID Payload: NAT-T RFC 3947
2022-02-24 04:24:27 avmike:username: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:1
2022-02-24 04:24:27 avmike:>>> aggressive mode [<ip_of_peer>:62503] username: V1.0 564 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 0000 SA flags=
2022-02-24 04:24:27 avmike:username: Warning: source changed from 0.0.0.0:500 to <ip_of_peer>:62504
2022-02-24 04:24:27 avmike:<<< 4500 aggressive mode[<ip_of_peer>:62504] username: V1.0 236 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 0000 HASH flags=e
2022-02-24 04:24:27 avmike:username: switching to NAT-T (Responder)
2022-02-24 04:24:27 avmike:username: Phase 1 ready
2022-02-24 04:24:27 avmike:username: current=0.0.0.0 new=<ip_of_peer>
2022-02-24 04:24:27 avmike:> user_changed(name=username,ipaddr=<ip_of_peer>:62504)
2022-02-24 04:24:27 avmike:username: local is behind a nat
2022-02-24 04:24:27 avmike:username: remote is behind a nat
2022-02-24 04:24:27 avmike:username: sending initial contact message
2022-02-24 04:24:27 avmike:>r> infomode 4500[<ip_of_peer>:62504] username: V1.0 124 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 bdb81c70 HASH flags=e
2022-02-24 04:24:27 avmike:>>> transaction mode 4500[<ip_of_peer>:62504] username: V1.0 124 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 f267c370 HASH flags=e
2022-02-24 04:24:27 avmike:<<< 4500 transaction mode[<ip_of_peer>:62504] username: V1.0 156 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 f267c370 HASH flags=e
2022-02-24 04:24:27 avmike:XAUTH REPLY received
2022-02-24 04:24:27 avmike:> user_xauth_query(ipaddr=<ip_of_peer>,name=username)
2022-02-24 04:24:27 avmike:user_xauth_query_reply -> XAUTH_STATUS_OK
2022-02-24 04:24:27 avmike:>>> transaction mode 4500[<ip_of_peer>:62504] username: V1.0 108 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 f267c370 HASH flags=e
2022-02-24 04:24:27 avmike:<<< 4500 transaction mode[<ip_of_peer>:62504] username: V1.0 124 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 f267c370 HASH flags=e
2022-02-24 04:24:27 avmike:XAUTH ACK received
2022-02-24 04:24:27 avmike:<<< 4500 transaction mode[<ip_of_peer>:62504] username: V1.0 124 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 5169bc38 HASH flags=e
2022-02-24 04:24:27 avmike:CFG REQUEST Msg erhalten
2022-02-24 04:24:27 avmike:> cfgmode_query(name=username)
2022-02-24 04:24:27 avmike:CFG_SND_REPLY
2022-02-24 04:24:27 avmike:>>> transaction mode 4500[<ip_of_peer>:62504] username: V1.0 124 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 5169bc38 HASH flags=e
2022-02-24 04:24:27 avmike:username: start waiting connections
2022-02-24 04:24:27 avmike:username: NO waiting connections
2022-02-24 04:24:27 avmike:<<< 4500 quickmode[<ip_of_peer>:62504] username: V1.0 220 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 c694dd0b HASH flags=e
2022-02-24 04:24:27 avmike:delete configmode retry timer for exchange: IC:ad291587e09db0f8 RC:26d56d4a04e2a8e4
2022-02-24 04:24:27 avmike:WARNING !!! local id differs from received id
2022-02-24 04:24:27 avmike:>>> quickmode 4500[<ip_of_peer>:62504] username: V1.0 204 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 c694dd0b HASH flags=e
2022-02-24 04:24:27 avmike:<<< 4500 quickmode[<ip_of_peer>:62504] username: V1.0 108 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 c694dd0b HASH flags=e
2022-02-24 04:24:27 avmike:username: Phase 2 ready
2022-02-24 04:24:27 avmike:NEW Phase 2 SA: ESP-AES-128/SHA1 SPI: 663C1C97 LT: 3600 I/O: IN
2022-02-24 04:24:27 avmike:NEW Phase 2 SA: ESP-AES-128/SHA1 SPI: CE2237B4 LT: 3600 I/O: OUT
2022-02-24 04:24:27 avmike:< cb_sa_created(name=username,id=1,...,flags=0x00032003)
2022-02-24 04:24:27 avmike:username: start waiting connections
2022-02-24 04:24:27 avmike:username: NO waiting connections
2022-02-24 04:24:37 avmike:>>>4500 nat-t-keepalive[<ip_of_peer>:62504]
2022-02-24 04:24:58 avmike:<<< 4500 infomode[<ip_of_peer>:62504] username: V1.0 140 IC ad291587e09db0f8 RC 26d56d4a4e2a8e4 e090ae0e HASH flags=e

Der grüne Teil ist dann die Phase 2 und erst ab der roten Zeile ist auch eine FUNKTIONSFÄHIGE VPN-Verbindung aufgebaut. Davon sehe ich aber in der Datei in #40 nicht mal einen Ansatz ... das wären dann die erwähnten "Indizien", daß Du Dich OFFENSICHTLICH täuschst, was den erfolgreichen Aufbau der Verbindung betrifft.

Soviel erst mal zu #40 ... ich gehe chronologisch vor und arbeite Deine Antworten der Reihe nach ab. Damit wäre ich dann bei #41 und da gibt es ja tatsächlich ein Protokoll einer ERFOLGREICH aufgebauten Verbindung ... bliebe die Frage, ob Du da mal selbst einen Blick hinein geworfen hast. Denn da ist ja auch eine erfolgreiche Phase 2 zu sehen ... genau das, was bei dem Protokoll in #40 FÜR BEIDE Versuche fehlt.

Die MTU-Size ist 1380, wie sie bei der Einrichtung voreingestellt wurde, Der Wert kommt dem Vorschlag von PeterPawn sehr nahe. Ich habe ihn deshalb nicht mehr geändert.

Nun ... es ist ja Dein PC (oder der Deiner Bekannten/Freundin) - da entscheidest natürlich auch Du, was Du wo einstellst. Aber gibt es - außer "Bauchgefühl" - auch noch eine logische Begründung für diese Entscheidung und mit "logisch" meine ich eine, die auch angesichts des bisherigen Thread-Verlaufs und der Erläuterungen zu den jeweiligen Vorschlägen für andere nachvollziehbar wäre?

Dabei würde mich auch interessieren, was Du meinst, WARUM ich mir die Arbeit machen würde, das noch einmal für Dich aufzuschreiben (es gibt genug Threads hier, wo das Thema immer wieder auftaucht, z.B. diesen hier: https://www.ip-phone-forum.de/threa...ichtung-ds-lite-standort.310971/#post-2440676), wenn doch der Standardwert (1380) im SC schon funktionieren sollte? Die pure Langeweile war es nicht - das kann ich versichern. Auch wenn dieser Beitrag erneut diesen Eindruck vermitteln mag - ich hoffe halt immer auch darauf, daß sich weitere Leser finden, die das über Suchmaschinen lokalisieren, wenn sie ein ähnlich gelagertes Problem haben und damit die Worte und Erklärungsversuche dann doch nicht umsonst sind.

---

Wie ich weiter vorne im Thread auch schon schrieb, könntest/solltest Du Dich halt auch mal "schlau machen", was es mit dem IPSec-Overhead genau auf sich hat und wie man eine MTU dann wählen muß/sollte. Es gibt sicherlich sehr viele Quellen, wo dieses Thema behandelt wird, aber eine kann/muß man sich dann eben mal heraussuchen ... am besten noch in Verbindung mit einem Mitschnitt eines ESP-Pakets, wo man die Länge des Payloads exakt kennt, z.B. ein `ping -s 1` o.ä. - wobei hier bei 1 und 2 kein Unterschied in der Größe der ESP-Pakete auftauchen sollte (erst ab 3 wieder) und das rührt daher, daß bei den verwendeten Algorithmen für die Verschlüsselung immer eine feste Blockgröße zum Einsatz kommt (bei AES sind das 128 Bit oder auch 16 Byte) und wenn die zu verschlüsselnden Nutzdaten IPSec-Daten keine durch 16 teilbare Länge haben, wird auf die nächste integrale Grenze aufgefüllt.

Rechnen wird doch einfach mal selbst. Ein ESP-Paket besteht zunächst mal aus 32-Bit (4 Byte) SPI, gefolgt von einer 32-bittigen "sequence number" - macht bis hier schon mal 8 Byte. Danach folgt der Payload ...

Nehmen wir das ping -s 1 an (also 1 Byte ICMP-Daten + 28 Byte ICMP-Paket drum herum - in so einem IPSec-Tunnel wird ja immer irgendein komplettes Netzwerk-Paket als Payload übertragen und der (ESP-)Rest drum herum ist nur die Verpackung, wobei da - wie bei den russischen Matrjoschkas - immer noch eine Verpackung außen herum dazu kommt) und damit ein "padding" von einem Byte an (32 ist das nächste Vielfache der "cipher block size" und zwei Byte werden noch für IPSec-Daten benötigt nach dem Padding) - macht zusammen dann 30 Byte zzgl. ein Byte "padding length" (die Angabe, wieviele "padding bytes" der vorhergehende Payload enthält) und ein weiteres Byte mit der Angabe, daß danach ein ICV folgt. Dieses Byte als "next header" ist noch Bestandteil der verschlüsselten Daten - damit kommen wir auf einen "cipher block" von 32 Byte Länge, der sich mit zwei AES-Aufrufen verschlüsseln läßt.

Wer's nicht glauben will, kann ja mal ein paar ESP-Pakete mitschneiden für einen Tunnel, in dem ein ping -c 2 -s <n> <ziel> seine Daten transportieren läßt ... beim Wechsel von 2 zu 3 Byte (ICMP-)Daten sollte genauso ein Sprung in der Paketgröße (um jeweils 16 Byte) auftreten, wie beim Wechsel von 18 zu 19 Byte.

Danach folgt der ICV, wobei hier bei Verwendung von SHA-1 der tatsächlich 160 Bit große Ausgabewert der Funktion auf 96 Bit abgeschnitten wird (RFC 2404 - daher auch die manchmal auftretende Bezeichnung HMAC-SHA-1-96) und damit nur 12 Byte im IPSec-Paket belegt. Bei moderneren Verfahren wie SHA-2 (RFC 4868) wird dann nur noch die Länge des Ausgabewertes der Hash-Funktion halbiert (siehe Tabelle in Punkt 2.6 im RFC 4868) -> also auf 128 / 8 Bit = 16 Byte im besten Fall und das Doppelte (32 Byte) bei SHA-512. Damit ist der effektive Overhead bei einer IPSec-Verbindung also auch noch davon abhängig, welches HMAC-Verfahren verwendet wird ... und das handeln die Peers erst in P2 miteinander aus. Aber bleiben wir mal bei SHA-1 ... da sind wir also mittlerweile bei 8 (ESP-Header) + 16 (ESP-Payload + Padding + Pad-Size + Next-Header) + 12 Byte (ICV) Overhead für die IPSec-Kapselung im ESP-Paket.

Da wir es hier auch noch mit einem NAT-T-Szenario zu tun haben (erkennbar einerseits an den Nachrichten, andererseits an der UDP-Portnummer 4500, die bei NAT-T verwendet wird), wird dieses ESP-Paket jetzt also noch einmal in ein UDP-Paket gesteckt, dafür braucht es dann einerseits einen UDP-Header (macht noch einmal 8 Byte) und gleichzeitig einen IPv4-Header für dieses (nunmehrige) UDP-Paket, der seinerseits auch noch einmal 20 Byte auf die Waage bringt. Alles in allem sind das also (bei einem einzigen zu übertragenden ICMP-Paket mit einem Byte Payload) schon 64 Byte als IPv4-Paket und ein solches schnürt dann jeder der beiden VPN-Clients auch, weil das IPSec-VPN von AVM nur mit IPv4 als Transport-Protokoll umgehen kann.

Somit haben wir eine Paketgröße von mind. 64 Byte, wobei die Größe des Pakets jeweils um 16 Byte zunimmt, sowie die zu transportierenden Daten + IPSec-Overhead die nächste Grenze eines Cipher-Blocks überschreiten ... es geht also weiter mit 80, 96, 112, usw. bis zur 1296, 1312, usw. bis 1376, 1392, usw. bis letztlich (bei MTU-Size 1500 angenommen) 1488 - mehr als 1424 1438 Byte Nutzlast kriegt man dann auch im besten Falle nicht in ein ESP-Paket bei IPSec mit NAT-T. (EDIT: da hatte ich die max. 14

Wenn dieses IPv4-Paket dann aber an einem DS-Lite-Anschluß in einem IPv4-in-IPv6-Tunnel übertragen werden soll, kommen noch einmal mind. 40 Byte für den dafür benötigten IPv6-Header hinzu ... ich dachte, das hätte ich weiter vorne im Thread auch schon erwähnt. Somit sind wir bei 104 Byte Overhead (mindestens, denn bei IPv6 können auch noch "extension headers" dabei sein) und wenn die Peers die Existenz dieses zusätzlichen Flaschenhalses "IPv4-in-IPv6" nicht richtig ermitteln können, werden sie diesen zusätzlichen Overhead auch nicht einberechnen.

Obendrauf kommt dann noch die Tatsache, daß auch die "physikalische Verbindung" zwischen der (vermutlich ja an einem DOCSIS-Anschluß hängenden) 6591, die tatsächlich eine MTU-Size von 1500 Byte auf der WAN-Seite nutzen kann und dem DSL-Anschluß (auch das nur vermutet, aber der ganze Unsinn hier paßt nun mal dazu wie die Faust aufs Auge), der sicherlich mit PPPoE-Kapselung arbeitet und daher per se schon nur noch 1492 Byte MTU-Size hätte, eben keine "vollen" Pakete verkraftet. Da muß also die MTU-Size für den Tunnel irgendwie anders begrenzt werden, wenn das automatische Ermitteln der MTU-Size über Path-MTU-Discovery nicht funktioniert ... und das tut es bei VPN-Verbindungen eben in der Regel nicht. Daß das Internet voll ist mit Beschreibungen von Problemen, die sich aus einer falschen MTU bei VPN-Verbindungen ergeben (das gilt auch für andere VPN-Software, bis hin zum WireGuard), hatte ich - glaube ich jedenfalls - auch schon zuvor erwähnt ...

---

Ich hatte (wenn mich die Erinnerung nicht täuscht) dabei ja auch geschrieben, daß 1300 sicherlich etwas übertrieben sein könnte und man das - nachdem es vielleicht erst einmal auch wirklich funktionierte - dann immer noch durch entsprechende Tests weiter eingrenzen kann, falls wirklich das letzte Byte aus dem Tunnel herausgequetscht werden muß (was üblicherweise auch schon sehr schwer zu begründen sein dürfte, denn der Unterschied zwischen einer MTU-Size von 1300 und einer von 1340 oder gar 1372 fällt beim interaktiven Arbeiten über den Tunnel garantiert gar nicht auf).

Und ich hatte Dir zwar die "Online-Hilfe" für den Shrewsoft-Client verlinkt und war damit in der Hoffnung, daß Du die auch lesen würdest ... aber da es sich ja auch an spätere Leser richtet: Wie man dort in der Hilfe nachlesen kann, wird diese MTU-Einstellung/-Limitierung nur dann auch wirksam, wenn man den "virtual adaper mode" verwendet. Wer also vor einem ähnlichen Problem stehen sollte, wie in diesem Thread ventiliert (daß zwar eine P1-Verbindung zustande kommt, danach aber keine P2-Pakete sinnvoll übertragen werden können), der kann es zumindest mal VERSUCHEN, das Problem durch geänderte Einstellungen bei Shrewsoft-Client zu beheben:

1. "Virtual Adapter Mode" auswählen
2. MTU-Size auf 1300 begrenzen (spätere Experimente, ab wann genau es nicht länger funktioniert, sind damit ja nicht ausgeschlossen)
3. die Proposals für P2 deutlich reduzieren - der SC (Shrewsoft-Client) bietet da einen bunten Strauß an Möglichkeiten an, die man gar nicht alle benötigt und damit wird u.U. schon das erste Paket für P2 (die "quickmode initiation") so groß, daß es die üblicherweise mögliche MTU-Size (erst recht bei der Kombination mit DS-Lite und IPv4 über AFTR auf der einen und DSL mit PPPoE auf der anderen Seite) übersteigt. Man braucht auch nicht eine so große Auswahl - gerade bei einer FRITZ!Box 7590, bei der es ja auch eine Hardware-Unterstützung für AES-Verschlüsselung gibt, ist AES mit 128 oder 256 Bit Schlüssellänge (die Blocksize bleibt immer bei 128 Bit) schon ziemlich optimal und beim HMAC in P2 reicht sicherlich (selbst bei 8 Stunden Lifetime für eine SA) auch SHA1 (wie man es auch im Protokoll in #41 in den Zeilen 26 und 27 sehen kann), ansonsten kann man auch SHA-2-Verfahren nehmen, wobei die größeren ICV-Daten dann auch den IPSec-Overhead weiter vergrößern.

Und wenn es dann immer noch nicht funktionieren will, bietet der Shrewsoft-Client (auch weiter vorne im Thread schon erwähnt von mir) noch ein Programm zur Verwaltung der erzeugten Protokoll-Daten ... dort kann man sogar sehen, welche Paketgrößen von diesem Client jeweils auf die Reise geschickt oder empfangen wurden - eine ausbleibende Antwort auf ein Paket deutet schon mal darauf hin, daß das Paket sein Ziel nicht erreicht hat oder dort - aufgrund unerlaubter Veränderungen auf dem Weg, wozu auch das Fragmentieren zu großer Pakete zählen würde - nicht "verstanden" wurde und somit gar nicht erst eine Antwort auslöste.

---

So ... jetzt habe ich mich aber auch genug abgestrampelt mit meinem Versuch einer Erklärung, wo ich eine mögliche Ursache der Probleme sehe. Wenn das jetzt immer noch "nahe genug dran ist", kann ich auch nicht mehr helfen - und ich könnte ja auch immer noch komplett daneben liegen (auch wenn die Zeichen dafür weniger geworden sind, nachdem nun feststeht, daß die Verbindungsversuche an der 7590 ankommen).

Wenn's doch noch fruchten sollte - schön. Wenn nicht - auch egal.

Und um der Frage zuvor zu kommen, ob ich irgendwie "angefressen" sein könnte ... ja, das kann durchaus sein (und ich wette, man merkt es oben gar nicht). Wenn ich nicht schon die Zeit für die vorhergehenden Beiträge in diesem Thread investiert hätte (und ja, ich weiß auch, daß ich die ja nicht schreiben MUSSTE), hätte ich das vermutlich auch einfach ad acta gelegt - es ist immerhin nicht mein Problem. Aber vielleicht überzeuge ich @wglan ja doch noch, es wenigstens mal zu versuchen ... ansonsten hilft es vielleicht - wie bereits erwähnt und an anderen Stellen ja auch schon erlebt - dem nächsten Leser mit ähnlichen Problemen.

(Ausnahmsweise habe ich auch mal gar keine Lust, hier noch einmal Korrektur zu lesen ... wer also Fehler (orthographisch oder grammatikalisch) findet, darf sie behalten. Den Teil, in dem ich den Aufbau der Pakete auch noch anhand eines Wireshark-Mitschnitts erklärt hatte, habe ich wieder gelöscht - das ist eher etwas für ein Thema, wie IPSec nun eigentlich funktioniert und dafür gibt es eigentlich auch genug andere Quellen im Netz - man muß sie nur finden und dann auch nutzen wollen.)

EDIT: Beim Korrekturlesen (nun doch) fiel mir dann noch auf, daß ich hier einfach den ESP-Payload und die zu übertragenden Pakete gleichsetze - das ist ja auch Unsinn, denn bei AES-CBC wird ja auch noch der IV mit übertragen (16 Byte) und damit sind es schon 80 Byte mehr als die verschlüsselt zu übertragenden Daten. Aber das sind auch alles Faktoren, die von den IPSec-Clients einberechnet werden können und so tun sie das auch ... woran es letztlich scheitert, ist das Erkennen zusätzlicher "Engstellen" auf dem Transportweg für IPSec-Pakete, weil PMTU-D kein "MUSS" ist für IPSec (RFC 4301 - Kapitel 8).

 

[wglan]

@ alle, die an einem DS-Lite Anschluss hängen, empfehle ich die ausführliche Beschreibung von PeterPawn. Mit den angehängten geänderten Shrew-Parametern läuft die VPN-Verbindung wunderbar,

@PeterPawn: Ich melde mich später noch einmal. Ich verstehe deinen Ärger über soviel Naivität und entschuldige mich. Wichtig ist erst einmal, dass die "Jenni" ab sofort HomeOffice machen kann. Danke!!!!!

Die alten Anhänge habe ich aus Datenschutzgründen gelöscht, da sie persönliche Daten beinhalten

Gruß, wglan

 

[PeterPawn]

Nichts wird so heiß gegessen, wie es gekocht wird ... es freut mich, wenn ich Dich doch noch überzeugen konnte und das Problem letztlich gelöst ist. Dann ist es hier im Board üblich, den Präfix im ersten Beitrag des Threads auf "gelöst" zu setzen, wenn man der "thread opener" war. Danke.

 

[wglan]

@PeterPawn: Nochmals herzlichen Dank und dass du dir gestern die Zeit genommen hast - obgleich angefressen - die Geschichte ausführlich zu beschreiben. Ich hatte mich bisher mit VPN und Fritzboxen nie auf dieser Ebene beschäftigt und wusste nicht einmal, wie man in der FB an debug-Info herankommt, geschweige denn Logs interpretiert. Deshalb habe ich wahnsinnig viel gelernt.

Über eine Sache bin ich erstaunt, die ich auch in anderen Logs gefunden habe, dass Shrew und FritzFernzugang nicht verträglich sind. Ich hatte sie sowohl auf meinem Laptop als auch auf J's Laptop parallel installiert und konnte sie bei mir daheim an meiner FB7590 beliebig verwenden und schließen. Die Verbindung klappte immer. Deshalb hatte ich sie auch bei dem Trace hintereinander angewendet, ohne dass ich Shrew komplett beendet hatte. Das war bei mir daheim alles erlaubt.

Die Aussage, dass Shrew sich verbindet, aber kein Ping im LAN ging, hatte ich daraus geschlossen, dass das VPN Connect Fenster nach dem Connect nur noch im Tray angezeigt wurde. Dass in Wirklichkeit nur die Phase1 erfolgreich war, habe ich dann erst durch dich aus dem Trace gelernt. Und die Aussage, dass bei FritzFernzugang die Gegenstelle nicht erreicht werden konnte, basierte auf der Fehlermeldung im Journal. Auch hier wurde ich im Log dann eines besseren belehrt.

Die Paar "Watsch" in deinem Beitrag akzeptiere ich gerne, da sie zum Glück mit jeder Menge Erklärungen einhergingen. Ich habe mein Problem mehrfach im Netz gefunden. Ich hoffe, es stolpern noch viele über deine Lösung.

Ich werde den Thread gleich als gelöst markieren.

Die Kuh ist vom Eis! Danke! ​

 

[PeterPawn]

Da der Thread ja auch noch weiterhin zu lesen sein wird ... einiges an meiner Argumentation/Berechnung von Paket-Größen ist nicht klar genug formuliert oben - da macht sich das fehlende Korrekturlesen (sogar inhaltlich) bemerkbar.

Nur als ein Beispiel ... man muß natürlich nicht sowohl die 40 Byte für IPv4-in-IPv6 UND die 8 Byte für PPPoE einrechnen, solange die nicht auf DERSELBEN Seite der Verbindung auch benötigt werden. Wenn die DS-Lite-Seite die Pakete zum AFTR sendet und der die dann auspackt, fällt der IPv6-Header weg und die 8 Byte PPPoE-Header auf der anderen Seite führen dann nicht mehr zum Überschreiten der MTU-Size.

Aber wenn DS-Lite UND DSL mit PPPoE auf derselben Seite zusammen kommen, dann addiert sich auch der Overhead. Wie gesagt, nur ein Beispiel, auch andere Zahlen oben stimmen wohl nicht 100% bzw. es wird für mich selbst nicht mehr unzweideutig klar (mit zwei Tagen Abstand), was ich da geschrieben habe.

Also bitte den Teil mit den Berechnungen (zumindest mit den Additionen, die Grundlagen, was wieviel Overhead erzeugt, stimmen schon einigermaßen) ausnahmsweise mal nicht auf die Goldwaage legen - da wäre einiges zu korrigieren bzw. unmißverständlicher zu formulieren und ich muß mal sehen, ob/wann ich die Zeit dafür finde.