[Frage] LAN-LAN-VPN zwischen DS-Lite und v4 - Probleme in Richtung DS-Lite-Standort

[Ja_Nosch]

Hallo,

gegeben ist folgende Situation:

FRITZ!Box 7490 an Standort A
Unitymedia-Internetzugang mit DS-Lite, ConnectBox an LAN 1 der FB angeschlossen
Netz: 192.168.130.0 / 255.255.255.0

FRITZ!Box 7490 an Standort B
FTTH-Anschluss mit IPv4, wie bei DSL-Anschlüssen
Netz: 192.168.120.0 / 255.255.255.0

Ich habe über die Weboberfläche jeweils LAN-LAN-VPN-Verbindungen (in beiden Fällen via MyFritz) hergestellt und die Option, die Verbindung dauerhaft aufrecht zu erhalten, nur bei Standort A aktiviert.

Die Verbindung wird auch aufgebaut. Vom Standort A kann ich auch auf alle Ressourcen an Standort B zugreifen.
Von Standort B komme ich aber - zumindest von dem Windows-PC am Standort B, von dem aus ich via RDP teste - nur teilweise auf die Geräte an Standort A: Ich kann alle Geräte erfolgreich anpingen, ich kann mich mit einem anderen Windows-PC am Standort A per RDP verbinden, ich kann aber keine Weboberfläche eines Gerätes von Standort A über egal welchen Browser aufrufen (auch http://192.168.130.1 - also die IP der FRITZ!Box an Standort A - kann ich nicht aufrufen).

Die Windows-Firewall auf meinem Rechner an Standort B habe ich übrigens testweise deaktiviert. Zudem habe ich von Standort B eine weitere LAN-LAN-Verbindung zu einem anderen Standort mit VDSL-Anschluss hergestellt - dort klappt alles (in beide Richtungen) wie gewünscht.


CFG von Standort A:

                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "Verbindung";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "MyFRITZvonStandortB";
                keepalive_ip = 192.168.120.1;
                localid {
                        fqdn = "MyFRITZvonStandortA";
                }
                remoteid {
                        fqdn = "MyFRITZvonStandortB";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheimerschlüssel";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.130.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.120.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.120.0 255.255.255.0";
                app_id = 0;

CFG von Standort B:
                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "Verbindung";
                boxuser_id = 0;
                always_renew = no;
                reject_not_encrypted = no;
                dont_filter_netbios = yes;
                localip = 0.0.0.0;
                local_virtualip = 0.0.0.0;
                remoteip = 0.0.0.0;
                remote_virtualip = 0.0.0.0;
                remotehostname = "MyFRITZvonStandortA";
                keepalive_ip = 0.0.0.0;
                localid {
                        fqdn = "MyFRITZvonStandortB";
                }
                remoteid {
                        fqdn = "MyFRITZvonStandortA";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "geheimerschlüssel";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.120.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.130.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.130.0 255.255.255.0";
                app_id = 0;

Bin gerade mit meinem Latein am Ende. Wo könnte der Fehler sein? Natürlich schon mehrfach neu gestartet und auch neu eingerichtet. Danke für Tipps.

 

[Micha0815]

In cfg-B würde ich den remotehost leer lassen und in cfg-A allways_renew= yes setzen. Zudem das editable komplett entfernen. Braucht es nicht, wenn die Verbindung korrekt arbeitet. Sonst mal mit den gängigen Vorlagen bzgl. Responder<->Initiator hier im Forum vergleichen.
LG
Edit: Btw. sollte die VPN- Verbindung auf beiden Seiten aktiv gesetzt sein.

 

[Ja_Nosch]

Edit: Btw. sollte die VPN- Verbindung auf beiden Seiten aktiv gesetzt sein.

Danke Dir. Sicher? AVM sagt ja selbst, dies solle nur auf der DS-Lite-Seite der Fall sein. Mit "aktiv" meinst Du sicher "dauerhaft halten"?

 

[Micha0815]

Auf dem Schlauphone (meine Antwort #2) habe ich es nichtso mit den Lesezeichen. Guckst Du hier und dem folgend dort, was bis dato ohne Probleme funktioniert.
Mit aktiv meine ich den Haken bei "Verbinden", der imho auf beiden Boxen aktiviert sein sollte ... zumindest auf Initiator-/DS-Lite-Seite, falls dort lokal kein Client dies vorort aktivieren kann. Ob die Clients auf der jeweiliger FB untereinander kommunizieren dürfen, kannst Du einstellen. Gleichfalls, ob alle Clients ihren I-Netverkehr über FB-B abwickeln oder nur ein bestimmter Client auf der A-Seite. Dann musst Du Clients halt fixe IPs im jeweils lokalen Netz zuordnen und in der accesslist jeweils einschränken.
LG

 

[Ja_Nosch]

Ich komme nicht weiter. Problem besteht weiterhin :-( Wird doch wohl am DSlite liegen?

 

[Micha0815]

Welches Problem? Hast Du denn mal alternativ z.B. Teamviewer versucht, um Probleme des Remote-Desktop auszuschließen? U.U. kommt da auch etwas aus der IPv6-Ecke. Kann man ja testweise ggfs. deaktivieren wie auch DNS-over-TLS.
LG

 

[PeterPawn]

Wird doch wohl am DSlite liegen?

Eher nicht ... aber was genau erwartest Du jetzt vom Board hier?

Da sind noch sooo viele Optionen für Tests, auf die Du selbst kommen solltest. Angefangen bei der Nutzung eines anderen Gerätes am Standort B anstelle des Windows-PCs. Da wird es ja sicherlich noch irgendein anderes Gerät geben, mit dem man mal versuchen könnte, die Web-Oberfläche der FRITZ!Box an Standort A aufzurufen, notfalls kann das auch ein Smartphone (ohne eigene VPN-Verbindung nach A natürlich) sein.

Auch die Benutzung anderer Programme zur Netzwerk-Diagnose (wer nach solchen Problemen im Internet sucht, stößt neben ping ja auch fast zwangsläufig auf traceroute oder die MS-Version davon, die sich dann nur noch tracert nennt) kann Dir hier niemand abnehmen - das mußt Du noch alles selbst machen.

Das Einzige, was hier ggf. möglich wäre, ist die INTERPRETATION der jeweilligen Ergebnisse, falls diese Dir nicht selbst gelingt. Aber auch dafür müßtest Du erst mal deutlich mehr "gucken" lassen ... die beiden Konfigurationsdateien sind zwar ein Anfang, aber das KANN einfach noch nicht alles sein.

In diversen Threads (zum Thema VPN) wird hier im Board auch immer wieder darauf verwiesen, wo man weitere Protokolle finden kann, die ebenfalls bei einer (möglichst eigenen) Fehlersuche hilfreich sein könnten. Das magst Du ja alles getan haben (so klingt zumindest ein "Ich komme nicht weiter.") - aber nichts davon hast Du hier veröffentlicht. Da kann es dann auch die (einigermaßen ausführliche, was aber noch längst nicht ausreichend ist) Problembeschreibung in #1 nicht rausreißen.

Und falls Du doch ein weiteres Gerät an Standort B findest und mit dem klappt auch der HTTP-Request zum Standort A, dann dürfte auch ins Auge springen, daß das eigentliche Problem im PC am Standort B liegt. Mich würde es (aufgrund der Beschreibung in #1) nicht mal wundern, wenn der verwendete Browser auf dem PC das eigentliche Problem ist (soweit ich das verstanden habe, sind ja nur HTTP-Request betroffen?) - manchmal führt auch ein Update des Browsers dazu (wie z.B. beim FF 91, der vor einigen Stunden/Tagen aktualisiert wurde), daß erst mal das falsche Protokoll versucht wird für eine Verbindung (der präferiert jetzt HTTPS) und da kommen dann auch schon mal merkwürdige Probleme ans Licht, gerade dann, wenn irgendwelche Geräte mit "self-signed"-Zertifikaten TLS machen wollen. Aber das ist nur eine Vermutung ... das systematische Testen kann niemand anderes als Du machen und die Ergebnisse solcher Tests überzeugen als Protokoll (in CODE-Tags eingebettet) immer noch mehr, denn als Prosa, wo dann schon Deine eigene Interpretation in die Beschreibung eingeht und die MUSS ja nicht unbedingt stimmen. Selbst "Spezialisten" sind ab und an mal betriebsblind ... und so manche falsche Annahme hat schon den Blick auf offensichtliche Ursachen verstellt. Und ja ... ich habe durchaus auch registriert, daß Du das mit mehreren Browsern probiert hast - nur haben z.B. Chrome und FF mittlerweile dasselbe Problem, daß sie TLS vorziehen.

EDIT: Und wenn Du feststellen willst, ob nicht doch irgendetwas Verbindungen nach Port 80 blockiert (manchmal ist das auch nur ein Plugin wie z.B. die "Privacy Essentials" von DuckDuckGo), dann kannst Du auch einfach mal eine Telnet-Verbindung zur FRITZ!Box an Standort A aufbauen (zum Port 80 natürlich) und dort ein GET / HTTP/1.0, gefolgt von einer weiteren Leerzeile (also mit 2x Enter-Taste) eingeben - eine erfolgreiche Verbindung würde dann mit HTTP/1.0 200 OK (gefolgt von weiterem Text) antworten und wenn auch das nicht klappt, dann blockiert wohl wirklich etwas im Netzwerk (vom lokalen Stack des PC über die Router bis hin zum notwendigen Rückweg) die Kommunikation.

 

[Ja_Nosch]

Danke für die ausführliche Antwort. Außer einem Raspi am Standort B kann ich derzeit auf nichts zugreifen.

Ja, Tracert habe ich bereits genutzt:

Vom betroffenen PC am Standort B aus ergibt Tracert nach FB von Standort A:
1 <1 ms <1 ms <1 ms fritz.box [192.168.120.1]
2 23 ms 24 ms 19 ms 192.168.130.1

Von einem PC an Standort A ergibt Tracert nach FB von Standort B:
1 <1 ms <1 ms <1 ms fritz.box [192.168.130.1]
2 19 ms 29 ms 19 ms 192.168.120.1

Telnet-Verbindung von Standort B zur FB an Standort A via Port 80 funktioniert.

Nach wie vor aber keinerlei Webseite eines Gerätes von Standort A. Vielleicht wichtig: ein mit .htaccess geschütztes Device an Standort A führt in Firefox dazu, dass die User/Passwort-Abfrage aufpoppt, danach geht es aber genausowenig weiter wie bei allen anderen Seiten.

Warum ich den Fehler irgendwo in der DSLite-Thematik vermutet hatte ist, weil die testweise Verbindung von Standort B zu Standort C (normaler VDSL-Anschluss) völlig problemlos funktioniert, d.h. mit dem selben - möglicherweise problematischen - PC an Standort B rufe ich lokale Webseiten (u.a. die der FB) problemlos auf.

Was mir nun gelungen ist, ist auf einen testweise gestarteten Webserver auf meinem PC an Standort A von Standort B - Port 80 - zuzugreifen, d.h. die Webseite wird in Firefox ausgegeben. Alle anderen Geräte (Port 80) gehen nach wie vor nicht.

VPN-Verbindung zu Standort B mit iPhone und dann Zugriff auf alle Webserver (Port 80) an Standort A klappt auch.

Bin mit meinem Latein echt am Ende. Könnte das etwas mit der MTU-Size zu tun haben?

Nachtrag, noch vor dem Absenden: es hat etwas mit der MTU-Size zu tun. Nach dem Ändern der MTU-Size auf 1280 auf dem Test-PC an Standort B funktionieren alle Webseiten problemlos. Hatte das von Euch schonmal wer? Ist/war dieses Problem bekannt? Fehler liegt also damit doch an diesem DSLite-Mist (https://aktuelles.computer-fuechse.com/294/unitymedia-vpn-probleme-ipv4-ipv6-geloest.htm).

Danke Euch!

 

[PeterPawn]

Ist/war dieses Problem bekannt?

Jein. Daß eine zu große MTU-Size beim VPN zu Problemen führen kann, ist bekannt - aber üblicherweise sollte ein TCP-Stack auch in der Lage sein, die tatsächlich noch verwendbare Größe durch "PMTU discovery" zu ermitteln und wenn das nicht klappt, ist da irgendwo auf dem PC dennoch ein Problem.

Aber damit ist dann auch klar, warum einige Protokolle (die nur kurze Datenpakete verwenden) funktionieren und andere wiederum nicht bzw. nur sporadisch (wenn die Daten in ein einzelnes Paket passen und das die MTU-Size nicht überschreitet).

Es ist aber nicht generell so, daß PMTU-Discovery nicht funktionieren würde beim AVM-VPN - was "sieht" denn die 7490 am Standort A von der vorhandenen Netzwerk-Topologie? Wenn die erkennt, daß sie IPv4 (etwas anderes kann das AVM-VPN nicht) nur über einen AFTR-Server benutzen kann, sollte sie eigentlich den IPv6-Overhead von alleine in die Rechnung einbeziehen und die MTU auch für VPN-Verbindungen entsprechend verringern. Welche Angaben sie verwendet, findet man (bei aufgebauter Verbindung) in der Support-Datei. Da kann es u.U. auch einen Unterschied ergeben (das müßte man für aktuelle Firmware noch mal testen), wie genau man den LAN1-Modus konfiguriert hat - da gibt es ja fürs Kabel(-Modem) noch einen gesonderten Punkt bei "Anschluss" (vs. "externes Modem/Router").

 

[Ja_Nosch]

Danke Dir. Das Problem bestand in der Vergangenheit an Standort B schonmal bei Nutzung eines Notebooks mit Windows 10. Hast Du eine Idee, wie man das Problem nicht-client-seitig lösen könnte, also ohne MTU-Änderung in Windows? Ja, das externe Modem ist über LAN 1 als "Vodafone Kabel-Anschluss: Einrichtung an einem Kabel-Anschluss" verbunden; ich habe es gerade aber auch mal über "vorhandener Zugang über LAN" getestet - selbes Ergebnis ... was meinst Du mit der Frage, was die FB am anderen Standort "sieht"?

 

[PeterPawn]

was meinst Du mit der Frage, was die FB am anderen Standort "sieht"?

Den ersten "Kasten" auf der Seite "Internet / Online-Monitor" (mit maskierten IPv6-Adressen bzw. DynDNS-Namen, der Rest sollte unkritisch sein) - mich interessiert in erster Linie, ob da ein AFTR ausgewiesen ist, weil dann eigentlich die zusätzlich benötigten Bytes beim VPN von der MTU-Size abgezogen werden sollten. Die Frage ist halt, WER den zu großen Wert einfach passieren läßt - vermutlich erkennt die Box am Standort A nicht richtig, auf welche MTU-Size sie die VPN-Pakete segmentieren muß und so werden die dann bei der IPv6-Kapselung (auf dem Rückweg über den AFTR, der die dann in IPv6-Pakete einpackt) noch ein zweites Mal segmentiert, weil sie sonst nicht durch den IPv6-Tunnel gehen würden - für die HMAC-gesicherten Daten in einem IPSec-Paket ist das tödlich.

Ich kenne aber im FRITZ!OS auch nur eine einzige Möglichkeit, diesen Wert irgendwie vorzugeben oder zu überschreiben - das ist m.W. die IPv6-Konfiguration bei "Internet / Zugangsdaten". Wobei man die dann auf der FRITZ!Box am DS-Lite-Anschluß einstellen müßte ... einen Versuch ist es sicherlich wert, obwohl dann die MTU für ALLE Pakete verringert wird, die den Router am Standort A passieren. Wenn alles stimmt, sollte damit auch die MTU für die VPN-Strecke gesenkt werden ... aber das sollte man sich in der Support-Datei VOR und NACH dem Ändern von Einstellungen ansehen und nicht ständig weiter an irgendwelchen Stellschrauben drehen.

 

[Ja_Nosch]

Guten Morgen,

Dein Tipp hat mich wohl in die richtige Richtung gebracht: im "Kasten" des Unitymedia-Standortes war nur eine v4-IP aufgelistet. Der Haken bei "IPv6-Unterstützung aktiv" im Reiter IPv6 war NICHT aktiv. Ich habe diesen nun aktiviert und ausgewählt "Native IPv6-Anbindung verwenden" ("AFTR-Adresse automatisch über DHCPv6 ermitteln") - und seither klappt das Aufrufen der problematischen Webseiten via VPN auch, wenn wieder der ursprüngliche MTU-Wert (1500) auf dem Rechner eingetragen ist. "MTU manuell einstellen" im Reiter IPv6 habe ich NICHT aktiviert.

Zudem habe ich mal einen Diffcheck der Support-Daten vor dieser IPv6-Änderung und danach durchgefüht und nach dem MTU-Wert geschaut. Auffallend ist:

Vorher:

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
StandortA-StandortB: pmtu 0 mtu 1500 encaplen 94 dpd_supported dont_filter_netbios local_nat remote_nat

Nachher:

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
StandortA-StandortB: pmtu 0 mtu 1460 encaplen 86 dpd_supported dont_filter_netbios local_nat

Die FRITZ!Box hat also wohl den MTU-Wert von 1500 auf 1460 reduziert, wodurch das Problem behoben zu sein scheint.

An der Stelle nochmal vielen Dank für Deinen Input und die Hilfe zur Lösung!

PS: Mein allererster Fehler war übrigens - den hatte ich vor einigen Tagen schon selbst beseitigt - dass der Standort A das Netz 192.168.100.0 / 255.255.255.0 hatte - 192.168.100.1 ist aber für Kabel-Modems reserviert... (hat mit dem Thema hier aber nichts zu tun).