LAN2LAN: Remotenetz nicht erreichbar trotz erfolgreicher Verbindung

[tplus]

Hallo,

seit Jahren ist bei mir eine Zweitwohnung im Ausland über LAN2LAN (2 x 7490) mit meinem Wohnsitz in Deutschland verbunden, lief immer problemlos. Seit einigen Wochen kann ich keine IP im Remote-Netz mehr erreichen, auch die FB nicht mehr.

Remote habe ich eine LTE-Verbindung mit Carrier-Grade NAT, deswegen initiiert die Remote-FB die VPN Verbindung (Smokeping und SIP).

Die Remote-FB und die Netzwerkgeräte haben Verbindung, SIP und Netatmo sind online, ich kann die Webcam über einen Chinaserver erreichen.

Die VPN Verbindung wird korrekt aufgebaut, "grüner Punkt" und Meldung im Ereignismonitor (VPN Verbindung ... erfolgreich hergestellt). Trotzdem erreiche ich das Netz nicht, ein Ping auf 192.168.10.1 gibt eine Zeitüberschreitung.

Auf beiden Seiten ist pi.hole aktiv, DNS Probleme schließe ich aber aus, da ich die IP anpinge.

Hier die Config:

                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "XXXXX";
                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 = "XXX.selfhost.bz";
                keepalive_ip = 192.168.10.1;
                localid {
                        fqdn = "$$$$UOOA";
                }
                remoteid {
                        fqdn = "$$$$XVLA";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "$$$$AA";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.10.0 255.255.255.0";
                app_id = 0;

Besten Dank für Tipps...

 

[PeterPawn]

Weird … ich dachte bisher immer, eine funktionierende VPN-Verbindung bräuchte auf BEIDEN Seiten der Verbindung jeweils eine eigene Konfigurationsdatei.

Jetzt bin ich ja mal gespannt, wann sich das geändert hat und falls das doch immer noch so sein sollte, wann die zweite Konfiguration nachgeliefert wird und für welche Seite der VPN-Verbindung (die mit dem CGN, die ja der Initiator sein soll, wenn man die Beschreibung liest, wäre hier irgendwie naheliegend, wenn der remotehostname gesetzt ist) die bisher einzige in #1 wohl sein mag.

EDIT: Etwas so Simples wie eine aktive Firewall, die Pakete in ein bzw. aus einem "fremden" IPv4-Netz blockiert, wird es ja sicherlich nicht sein, wobei auch Linux-Installationen mit firewalld dabei inzwischen gerne mal freidrehen und versuchen, mit Windows-Installationen beim fehlenden Durchblick für die Benutzer gleichzuziehen.

Und häufig "vergessen" die Benutzer ja auch mal, daß sie zwischendrin eben DOCH irgendwelche Updates gemacht haben und daher Versicherungen, es hätte sich gar nichts weiter geändert, glatt gelogen sind (wenn auch vielleicht ohne Absicht). Glücklicherweise wurde so etwas hier ja nicht wirklich behauptet - auch wenn es (für mich) irgendwie so klingt.

 

[tplus]

Das Problem ist eben, dass hier "Remote" 1200 km bedeuten und wenn die FB nicht antwortet, ich kaum die Config auslesen und posten kann.

Die Remote-Location war bis Ende Februar bewohnt, seitdem ist da keiner, also keine Updates (auch Remote nicht). Das Netz war problemlos bis zum 2.4. zu erreichen (lt. Smokeping D).

Als Firewall ist - meines Wissens - nur die der Fritzbox im Einsatz (und Windows 10, aber der Remote-PC ist abgeschaltet).

 

[PeterPawn]

Es wird ja hoffentlich auch irgendwo eine Sicherung der Einstellungen in der entfernten FRITZ!Box geben, erst recht dann, wenn die sich schon so lange nicht mehr geändert haben sollen.

Aber das klärt dann zumindest mal einen Teil der aufgeworfenen Fragen, wenn es sich um die "lokale" Konfiguration handeln soll. Offenbar ist das dann auch keine "handgemachte" Konfiguration, wenn editable gesetzt ist und (bei einem bekanntermaßen nicht erreichbaren Peer) auch remotehostname angegeben ist.

Und bei der Firewall beziehe ich mich natürlich auf den Client, der für die (vergeblichen) Zugriffsversuche verwendet wird - etwas mehr "Fleisch" (vulgo: ETWAS genauer) darf die Beschreibung dessen, was Dich zu dem Schluß kommen läßt, daß die VPN-Verbindung keine Daten transportieren will, schon enthalten (bzw. sein).

Dazu gehört dann u.a. auch das VPN-Protokoll aus dem FRITZ!OS, zumindest für die lokale Box sollte das ja kein Problem sein. Es würde mich auch nicht wirklich wundern, wenn alte Probleme, die zwischenzeitlich behoben waren, erneut in der VPN-Implementierung auftauchen (zumal die Angaben zu den verwendeten OS-Versionen ja auch fehlen), weil das vermutlich auch nicht bei jeder neuen Version einem entsprechenden Regressionstest unterzogen wird.

Aber bei den geschilderten Symptomen tippe ich immer noch als Erstes auf ein Firewall-Problem im verwendeten Client (von Versuchen mit unterschiedlichen Clients stand (iirc) noch nichts in diesem Thread), zumindest solange ich das VPN-Protokoll nicht sehen kann.

Ich würde hier die VPN-Verbindung mal ordentlich (manuell) konfigurieren und eben remotehostname auf der Responder-Box weglassen … dann KANN es da keinen weiteren Zweifel an der Rollenverteilung geben und die VPN-"Verbindung" muß vom Peer initiiert werden. Dann die lokale Box neu starten und nach dem (dann hoffentlich auch noch erfolgreichen) Aufbau der VPN-Verbindung das Protokoll auslesen (und hier posten).

 

[tplus]

OS ist auf beiden Seiten 7.29.

Die Sicherung gibt es, ist aber auf einem (ausgeschalteten) PC an der Remote Location gespeichert.

Wenn ich den remotehostname auf der lokalen Box leer lasse (wird von der FB mit 0.0.0.0 ersetzt), wird keine Verbindung mehr aufgebaut. Ich muss die dyndns Adresse eingeben, dann ist wieder Verbindung:

VPN-Verbindung zu XXXX [77.205.22.196] IKE SA: DH2/AES-256/SHA2-512 IPsec SA: ESP-AES-256/SHA2-512/LT-3600 wurde erfolgreich hergestellt.

Gibt es noch ein umfangreicheres Log? Wo?

Wie bereits oben geschrieben: Timeout bei Pings auf die Remote FB, dem Raspberry dahinter, der Klimaanlagensteuerung, den shellies dahinter... Die Geräte funktionieren aber und sind online. Die Klima kann ich über den Sensibo-Server regeln.

 

[PeterPawn]

Wie bereits oben geschrieben: Timeout bei Pings auf die Remote FB, dem Raspberry dahinter, der Klimaanlagensteuerung, den shellies dahinter.

Das sagt aber immer noch nichts darüber aus, WOMIT Du (deshalb schrieb ich ja auch vom "Client" im Gegensatz zu dem Gerät, welches die aufzurufenden/zu nutzenden Dienste bereithält - das ist dann der "Server" in diesem Kontext und auch der ICMP-Echo-Responder wäre dann ein solcher "Server-Dienst") jeweils versuchst, die Geräte im LAN beim Peer zu erreichen. Wenn das immer dasselbe (lokale) Gerät ist und dieses hat dann ein Problem, dann suchst Du (mit einiger Wahrscheinlichkeit) eben an der falschen Stelle.

Ich muss die dyndns Adresse eingeben

Deshalb schrieb ich von "manueller Konfiguration" der VPN-Verbindung.

Beispiele und Vorgehen sind hier mehrfach zu finden/erklärt, ebenso der Fakt, wo und wie man in den Support-Daten des FRITZ!OS die (einzig wahre) Protokoll-Datei für die Vorgänge im Rahmen der VPN-Implementierung finden kann. Man KANN den entfernten Host-Namen bei der Benutzung des GUI für die Konfiguration einer VPN-Verbindung tatsächlich nicht einfach "auslassen" - denn dann fehlt in der Verbindung auch der korrekte FQDN bei localid (das mit den vier Dollarzeichen in Deiner Konfigurationsdatei ist nur der verschlüsselte Wert, der stimmt normalerweise mit der Angabe bei remotehostname überein, wenn man ihn entschlüsseln läßt), weil AVM BEIDE Angaben in der Konfiguration aus ein und demselben Wert ableiten will.

Gibt es noch ein umfangreicheres Log? Wo?

Wie bereits geschrieben: In der Support-Datei - aber das ist hier auch schon mehrfach erklärt und ebenso wurde die Tatsache, daß dieses Protokoll von AVM Zug um Zug zu etwas ausgebaut wurde, was diesen Namen auch wirklich verdient, schon mehrfach gewürdigt.

Ich denke/hoffe mal, daß bei der überwiegenden Anzahl von VPN-Problemen, die hier im Board geschildert (und häufig ja auch gelöst) wurden (in den letzten 8 Jahren sagen wir mal ... und da waren auch Konfigurationen mit dedizierter Rollenverteilung als Initiator/Responder oft genug schon vertreten), auch darauf hingewiesen wurde, daß eine (sinnvolle - d.h. für mich, eine die nicht nur auf "Raten" basiert) Diagnose einer (IPSec-)VPN-Verbindung im FRITZ!OS eigentlich nur dann möglich ist, wenn von BEIDEN Seiten einer solchen (nicht funktionierenden) Verbindung die Konfiguration(en) und auch die Protokoll-Dateien vorliegen - am besten noch direkt nach einem Neustart auf beiden Seiten.

Wenn das dann aus objektiven(!) Gründen nicht ohne weiteres möglich ist, hilft es dem Verständnis beim Leser aber auch deutlich, wenn man diese (widrigen) Umstände dann auch erklärt - dann kommt man als Leser auch nicht auf den Gedanken, daß da irgendetwas (ohne Gründe) fehlen würde.

Aber ich bin (immer noch, auch und gerade in Anbetracht der Tatsache, daß die VPN-Verbindung der Nachricht im Ereignis-Protokoll zufolge (was nicht mit dem VPN-Protokoll zu verwechseln wäre) auch aktuell neu aufgebaut werden kann) immer noch bei der Annahme, daß der zu den Verbindungstests verwendete Client (und immer noch steht da nichts von "mehreren Geräten" im (lokalen) LAN) seinerseits von (s)einer Firewall behindert wird, weil das eben Adressen sind, die NICHT dem lokalen (IPv4-)Segment zuzuordnen sind.

Hier wäre es ja u.U. AUCH noch hilfreich, wenn man wenigstens wüßte, WAS FÜR EIN Gerät da verwendet wird (oder ob es tatsächlich schon mehrere - auch auf unterschiedlichen Plattformen basierende - waren) - das kann ja nun alles sein, vom (Android- oder iOS-)Smartphone über ein Tablet bis zu "richtigen" Laptops, einem (oder mehreren) offenbar ja auch vorhandenen RasPis (wobei die bisher auch nur als "remote" erwähnt wurden) oder gar zu Desktop-PCs - mit welchen OS das jeweils getestet wurde, ist ebenso "nicht ganz unwichtig".

 

[tplus]

Okay, getestet mit lokalem Win10, Android und Raspi, keine Verbindung.

Hier der Auszug aus den Support-Daten:

VPN avmike
-------
ls: /var/tmp/ike.old: No such file or directory
-rw-r--r--    1 root     root          3590 May  1 18:24 /var/tmp/ike.log
1970-01-01 01:02:28 avmike:< add(appl=vpnd,cname=XXremote,localip=92.116.84.52, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=192.168.10.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
1970-01-01 01:02:28 avmike:new neighbour XXremote:  nat_t
1970-01-01 01:02:28 avmike:XXremote keepalive enabled
1970-01-01 01:02:28 avmike:XXremote start_vpn_keepalive 192.168.10.1
2023-05-01 18:24:06 avmike:<<<  aggressive mode[77.205.22.248:1525] ???: V1.0 709 IC d1e8a178dbdb3695 RC 00000000 0000 SA flags=
2023-05-01 18:24:06 avmike:aggressive mode XXremote: selected lifetime: 3600 sec(no notify)
2023-05-01 18:24:06 avmike:XXremote receive VENDOR ID Payload: XAUTH
2023-05-01 18:24:06 avmike:XXremote receive VENDOR ID Payload: DPD
2023-05-01 18:24:06 avmike:XXremote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-01 18:24:07 avmike:XXremote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:1
2023-05-01 18:24:07 avmike:>>> aggressive mode [77.205.22.248:1525] XXremote: V1.0 579 IC d1e8a178dbdb3695 RC 476841733c82f3cf 0000 SA flags=
2023-05-01 18:24:07 avmike:XXremote: Warning: source changed from <illegal INADDR> to 77.205.22.248:4500
2023-05-01 18:24:07 avmike:<<< 4500 aggressive mode[77.205.22.248:4500] XXremote: V1.0 268 IC d1e8a178dbdb3695 RC 476841733c82f3cf 0000 HASH flags=e
2023-05-01 18:24:07 avmike:XXremote: switching to NAT-T (Responder)
2023-05-01 18:24:07 avmike:XXremote: embedded inital contact message received
2023-05-01 18:24:07 avmike:XXremote start_vpn_keepalive already running
2023-05-01 18:24:07 avmike:XXremote: Phase 1 ready
2023-05-01 18:24:07 avmike:XXremote: current=<illegal INADDR> new=77.205.22.248
2023-05-01 18:24:07 avmike:XXremote start_vpn_keepalive already running
2023-05-01 18:24:07 avmike:XXremote: no valid sa, resetting initialcontactdone flag
2023-05-01 18:24:07 avmike:XXremote: remote is behind a nat
2023-05-01 18:24:07 avmike:XXremote: start waiting connections
2023-05-01 18:24:07 avmike:XXremote: NO waiting connections
2023-05-01 18:24:07 avmike:<<< 4500 infomode[77.205.22.248:4500] XXremote: V1.0 124 IC d1e8a178dbdb3695 RC 476841733c82f3cf 631006a8 HASH flags=e
2023-05-01 18:24:07 avmike:XXremote: initial contact message received
2023-05-01 18:24:07 avmike:XXremote start_vpn_keepalive already running
2023-05-01 18:24:08 avmike:<<< 4500 quickmode[77.205.22.248:4500] XXremote: V1.0 764 IC d1e8a178dbdb3695 RC 476841733c82f3cf d9664239 HASH flags=e
2023-05-01 18:24:09 avmike:>>> quickmode 4500[77.205.22.248:4500] XXremote: V1.0 348 IC d1e8a178dbdb3695 RC 476841733c82f3cf d9664239 HASH flags=e
2023-05-01 18:24:09 avmike:<<< 4500 quickmode[77.205.22.248:4500] XXremote: V1.0 108 IC d1e8a178dbdb3695 RC 476841733c82f3cf d9664239 HASH flags=e
2023-05-01 18:24:09 avmike:XXremote: Phase 2 ready
2023-05-01 18:24:09 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 578D7B4E LT: 3600 I/O: IN
2023-05-01 18:24:09 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: FAB93878 LT: 3600 I/O: OUT
2023-05-01 18:24:09 avmike:< cb_sa_created(name=XXremote,id=1,...,flags=0x00022001)
2023-05-01 18:24:09 avmike:XXremote stop_vpn_keepalive to 192.168.10.1
2023-05-01 18:24:09 avmike:XXremote start_keepalive_timer 3540 sec
2023-05-01 18:24:09 avmike:XXremote: start waiting connections
2023-05-01 18:24:09 avmike:XXremote: NO waiting connections
2023-05-01 18:24:53 avmike:<<< 4500 infomode[77.205.22.248:4500] XXremote: V1.0 140 IC d1e8a178dbdb3695 RC 476841733c82f3cf 7ac5512d HASH flags=e
2023-05-01 18:24:53 avmike:>r> infomode 4500[77.205.22.248:4500] XXremote: V1.0 140 IC d1e8a178dbdb3695 RC 476841733c82f3cf 7ac5512d HASH flags=e

VPN assocs
----------
/proc/kdsld/dsliface/internet/ipsec/assocs:
XXremote: 92.116.84.52:0.0.0.0 77.205.22.248:0.0.0.0 1 SAs  valid enabled dynlocalip
    permit ip any 192.168.10.0 255.255.255.0
    Forbidden Clients: 192.168.179.0/24

VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
XXremote: pmtu 0 mtu 1492 encaplen 86 dpd_supported dont_filter_netbios remote_nat


VPN informations (VPND)
----------

Active VPN connections:
  +--------+--------------------------+---------------+--------------------+--------------+------------------+---------------+
  | Name   | SPIs (Receiving,Sending) | Remote IP     | Remote Virtual IP  | Local IP     | Local Virtual IP | UDP           |
  |        |                          |               | (Benutzer-Einwahl) |              | (Firmen-VPN)     | Encapsulation |
  +--------+--------------------------+---------------+--------------------+--------------+------------------+---------------+
  | XXremote | (578D7B4E,FAB93878)      | 77.205.22.248 |                    | 92.116.84.52 |                  | X             |
  +--------+--------------------------+---------------+--------------------+--------------+------------------+---------------+

 

[tplus]

Hallo, ich bin jetzt an der Remote location und auch in Richtung Remote > Deutschland ist das Deutsche Netz nicht erreichbar. Verbindung ist aufgebaut und "grün".

Die Remote Konfiguration:

                enabled = yes;
                editable = yes;
                conn_type = conntype_lan;
                name = "YYYYYY";
                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 = "YYYYY.selfhost.bz";
                keepalive_ip = 192.168.1.1;
                localid {
                        fqdn = "SECRET";
                }
                remoteid {
                        fqdn = "SECRET";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "SECRET";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.10.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.1.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.1.0 255.255.255.0";
                app_id = 0;
        }
}

 

[PeterPawn]

Beide Boxen neu starten - den "responder" zuerst, wobei hier ja (man sieht es auch im VPN-Protokoll, wo schon VOR dem Setzen einer gültigen Uhrzeit:

1970-01-01 01:02:28 avmike:XXremote start_vpn_keepalive 192.168.10.1

ein Keepalive-Prozess von der falschen Seite gestartet wird) keine Differenzierung zwischen Initiator und Responder auf der Basis passender Konfigurationen erfolgt.

Dann auf BEIDEN Seiten das VPN-Protokoll in den Support-Daten suchen (und die GESAMTE Support-Datei aufheben, damit man auch später noch andere Informationen suchen kann, die sich auf genau dieselbe Situation beziehen).

Was im Protokoll in #7 (für mich) auffällig wäre, ist die Zeile:

2023-05-01 18:24:07 avmike:XXremote: Warning: source changed from <illegal INADDR> to 77.205.22.248:4500

Die gibt es hier bei mir nicht - das kann aber durchaus auch daran liegen, daß ich mich eben NICHT darauf verlasse, daß bei AVM schon irgendwie der Responder "merken" würde, daß er die Gegenstelle gar nicht erreichen kann. Das "Auslassen" von remotehostname und remoteip hat sich in diesen Konfigurationen bewährt und ich sehe keinen Grund, davon abzuweichen.

Auch der Umstand, daß da ein CGN beim Provider (der ja wohl sfr.fr ist?) sein soll und DENNOCH der (zweite!) Connection-Request vom Port 4500 an der Adresse 77.205.22.248 kommt (der erste verwendet ja noch einen "beliebigen" Port), sieht zunächst mal komisch aus. Das kann (bei gemeinsamer Nutzung einer IPv4-Adresse durch mehrere Kunden eines Providers) eigentlich nur dann vorkommen, wenn tatsächlich NIEMAND anderes zuvor diesen Port benutzen wollte und der Provider in solchen Fällen dann auch noch 1:1 mappt (was m.W. auch ungewöhnlich wäre, weil für dynamische Verbindungen i.d.R. eine (deutlich kleinere) Range definiert wird) oder wenn der Provider tatsächlich PCP (Port Control Protocol - RFC6887) unterstützt und dann wieder das mit "noch kein Anderer hat Anspruch darauf erhoben" hinzukommt. PCP findet man dann aber auch wieder in den Support-Daten der Box (hinter dem CGN).

Bei dem, was man an Parametern für die VPN-Verbindung ansonsten sehen kann (konkret die IPv4-Segmente und die Selektoren für den IPSec-Traffic), fällt mir zunächst mal nichts auf - eben abgesehen von der (nicht sinnvollen) Angabe für keepalive_ip auf der Responderseite.

Wenn auch nach dem Neustart BEIDER Boxen keine Daten übertragen werden können, dann muß man eben mal systematischer an die Sache herangehen und sich z.B. mit einem traceroute vergewissern, welchen Weg die Pakete am Ende TATSÄCHLICH nehmen ... denn ein ping ist da nicht wirklich aussagekräftig und wenn ich schon lese, daß da auf beiden Seiten noch ein Pi-hole vorhanden ist, dann braucht's nur irgendwo ein automatisches Update, welches einen (weiteren) DHCP-Server aktiviert, damit die Clients falsche Daten erhalten und dann auch für die VPN-Pakete nicht mehr den Weg über das Standard-Gateway nehmen, was ja möglichst die FRITZ!Box am entfernten Standort sein sollte ... ansonsten wird das mit dem VPN ohnehin nichts.

Erst recht dann, wenn die Geräte im "entfernten Netz" ansonsten keine Auffälligkeiten zeigen, wenn es um den Zugriff auf andere Adressen im Internet geht. Grundsätzlich wäre dabei zwischen mehreren Fällen zu unterscheiden:

1. Zugriff eines LAN-Clients auf die FRITZ!Box
2. Zugriff eines LAN-Clients auf eine Internet-Adresse
3. Zugriff eines LAN-Clients auf das GUI der entfernten FRITZ!Box
4. Zugriff eines LAN-Clients auf ein weiteres Gerät im LAN der entfernten FRITZ!Box

Das ist vielleicht nicht auf den ersten Blick ersichtlich, aber das sind alles unterschiedliche "Qualitäten", was die Netzwerk-Konfiguration(en) angeht.

Je nachdem, wo es dann beginnt "zu klemmen", kommen andere Ursachen in Frage - wobei man tatsächlich auch erst einmal mit ICMP- und/oder UDP-Paketen (also traceroute) beginnen sollte, denn wenn die schon nicht durchkommen, wird es mit TCP-Verbindungen (die zum "Aufbau" der Verbindung schon drei Pakete benötigen, die dann ihr Ziel auch jeweils zuverlässig erreichen können) gar nicht funktionieren.

Die Anzeige mit der "grünen LED" ist zwar schön und gut ... aber das gibt auch nur zu erkennen, daß zwischen den beiden FRITZ!Boxen (einige wenige) Daten einigermaßen erfolgreich ausgetauscht werden konnten und andere Probleme, die ggf. aufgrund von Änderungen im Netz des Providers neu auftreten, machen sich da noch gar nicht bemerkbar. Zum Beispiel die leidigen MTU-Probleme - die Box in D ist ja der Ansicht, sie könne die vollen 1492 Bytes (Ethernet: 1500 Bytes minus 8 Bytes PPP(oE)-Overhead) belegen, was bei einem CGN beim Provider in F ja nur dann funktionieren wird, wenn dafür KEIN zusätzlicher Raum in irgendwelchen Paketen benötigt wird.

Andererseits sind MTU-Probleme, die sich schon bei einem ping mit i.d.R. eher kurzen ICMP-Paketen zeigen, auch eher ungewöhnlich - meist machen die sich erst bemerkbar, wenn ein Protokoll die Pakete voll auslastet und sie dann irgendwo segmentiert werden müssen. Daher wäre die MTU hier mal nicht meine erste Idee ... aber ich habe bisher (dafür ist die Datenlage dann doch deutlich zu dünn) auch noch keine bessere.

 

[tplus]

Besten Dank für die Mühe. Ein tracert auf 192.168.1.1 endet in der lokalen Fritzbox (192.168.10.1). Neustarts haben nichts gebracht.

Ich betreibe noch einen Wireguard VPN Server (mit Pihole) auf einem Oracle Free-Tier den ich eigentlich nur für die Smartphones nutze. Als Workaround wollte ich auch den Datenverkehr der FB in F dort hin leiten um dann auch aus D darauf zugreifen zu können. Resultat:

Ihre Einstellungen konnten leider nicht erfolgreich übernommen werden.
Importierte Konfigurationsdatei passt nicht zu den erweiterten Einstellungen (Gesamter Datenverkehr).

Die Wireguard config läuft auf dem Smartphone problemlos:

[Interface]
Address = 10.66.66.2/24, fd33:33:42::2/64
DNS = 10.66.66.1, fd33:33:42::1
MTU = 1420
PrivateKey = xxxxxxxxxxxxxxxxxx

[Peer]
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = XXX.XXX.X.190:51515
PreSharedKey = xxxxxxxxxxxxxxxxxxxxxx
PublicKey = xxxxxxxxxxxxxxxxxx

Ist das eine der Einschränkungen auf der 7490, dass es einfach nicht funktioniert?

 

[PeterPawn]

Resultat

Was bedeutet das genau? Woher kommt diese Fehlermeldung? Aus einer der beteiligten FRITZ!Boxen (7490 mit FRITZ!OS (113.)07.29) kann sie eigentlich nicht stammen, denn da wird noch gar kein WireGuard® unterstützt.

---

Und ansonsten quält hier den Leser sicherlich auch noch die Frage, was denn die anderen traceroute-Kommandos für Ergebnisse erbracht haben mögen und was dabei in den Protokollen in den Support-Dateien auf BEIDEN Seiten der VPN-Verbindung wohl stehen könnte.

Es ist zwar sicherlich nicht auszuschließen, daß Du diese Protokolle (und ggf. zu fertigende Mitschnitte des Netzwerverkehrs) bereits selbst (korrekt) interpretiert hast - angesichts der bis vor kurzem noch bestehenden Unkenntnis, daß solche Protokolle in den Support-Daten überhaupt zu finden sind, bin ich da aber durchaus skeptisch.

Zumal die Frage zur WireGuard®-Konfiguration obendrein noch zeigt (beim Bezug darauf, daß diese Konfiguration auf einem Smartphone problemlos funktioniert), daß Dir andere, durchaus wesentliche VPN-Themen auch nicht so ohne weiteres geläufig sind.

Ein Smartphone ist eben KEIN Router (außer ggf. beim Tethering), denn dahinter befindet sich kein LAN, aus dem Geräte auch noch mit anderen Clients kommunizieren wollen oder müssen - was bei einem Router wie der FRITZ!Box in aller Regel aber der Fall ist.

Um Dir u.U. wirksam helfen zu können, braucht es DEUTLICH mehr an Informationen und irgendwie (ich weiß auch nicht genau warum) habe ich den Eindruck, daß Du Dir diese nicht wirklich abringen kannst und anstelle einer (systematischen) Suche nach der Ursache des Problems, lieber irgendeinen "Workaround" hättest.

In meinen Augen hast Du Dir jedenfalls (sofern meine Vermutung stimmt) schon mit der Installation einer Inhouse- oder Labor-Version einen Bärendienst erwiesen, denn welche Fehler in der VPN-Implementierung in DIESEN Versionen noch stecken (und im VPN-Bereich ist alles seit der 07.39 eine Dauerbaustelle - zumindest in meinen Augen), wissen vermutlich nicht mal die für das VPN verantwortlichen Entwickler bei AVM zu 100 Prozent.

Somit müßte man auf Deinen Boxen (wenn die jetzt doch unter FRITZ!OS > 07.39 laufen) nicht nur nach einer fehlerhaften Konfiguration i.V.m. einen LTE-Anschluß bei sfr.fr suchen, sondern auch noch die Möglichkeit von Fehlern in der Firmware berücksichtigen.

 

[tplus]

Traceroutes auf andere IPs führen um selben Ergebnis. Hier das Protokoll nach dem tracert:

VPN IKEv1
---------
-rw-r--r--    1 root     root          2239 May 22 19:57 /var/tmp/ike.log
-rw-r--r--    1 root     root         20545 May 22 19:51 /var/tmp/ike.old
2023-05-22 12:39:14 avmike:D-remote: Phase 1 ready
2023-05-22 12:39:14 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 12:39:14 avmike:D-remote: local is behind a nat
2023-05-22 12:39:14 avmike:D-remote: remote is behind a nat
2023-05-22 12:39:14 avmike:D-remote: start waiting connections
2023-05-22 12:39:14 avmike:D-remote: NO waiting connections
2023-05-22 12:39:16 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 12:39:16 avmike:D-remote: Phase 2 starting
2023-05-22 12:39:17 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 3321cb1b4b6d97ee RC 8a6eb56c2313978 1be75564 HASH flags=e
2023-05-22 12:39:18 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 3321cb1b4b6d97ee RC 8a6eb56c2313978 1be75564 HASH flags=e
2023-05-22 12:39:18 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 3321cb1b4b6d97ee RC 8a6eb56c2313978 1be75564 HASH flags=e
2023-05-22 12:39:18 avmike:D-remote: Phase 2 ready
2023-05-22 12:39:18 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: B10275EA LT: 3600 I/O: IN
2023-05-22 12:39:18 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 7304E9CF LT: 3600 I/O: OUT
2023-05-22 12:39:18 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 12:39:18 avmike:D-remote: start waiting connections
2023-05-22 12:39:18 avmike:D-remote: NO waiting connections
2023-05-22 12:39:28 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 12:45:12 avmike:D-remote: del phase 1 SA 2
2023-05-22 12:45:15 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=2,what=7,reason=Lifetime expired)
2023-05-22 12:45:15 avmike:FreeIPsecSA: spi=8F8BBF19        protocol=3 iotype=1
2023-05-22 12:45:15 avmike:FreeIPsecSA: spi=8FA5A643        protocol=3 iotype=2
2023-05-22 13:33:14 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 13:33:14 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC b0d49a1d7c4c64ba RC 00000000 0000 SA flags=
2023-05-22 13:33:15 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC b0d49a1d7c4c64ba RC 5400ed4dd833af7 0000 SA flags=
2023-05-22 13:33:15 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 13:33:16 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:4
2023-05-22 13:33:16 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 13:33:16 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 13:33:16 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 13:33:16 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC b0d49a1d7c4c64ba RC 5400ed4dd833af7 0000 HASH flags=e
2023-05-22 13:33:16 avmike:D-remote: Phase 1 ready
2023-05-22 13:33:16 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 13:33:16 avmike:D-remote: local is behind a nat
2023-05-22 13:33:16 avmike:D-remote: remote is behind a nat
2023-05-22 13:33:16 avmike:D-remote: start waiting connections
2023-05-22 13:33:16 avmike:D-remote: NO waiting connections
2023-05-22 13:33:19 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 13:33:19 avmike:D-remote: Phase 2 starting
2023-05-22 13:33:20 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC b0d49a1d7c4c64ba RC 5400ed4dd833af7 c60edac7 HASH flags=e
2023-05-22 13:33:20 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC b0d49a1d7c4c64ba RC 5400ed4dd833af7 c60edac7 HASH flags=e
2023-05-22 13:33:21 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC b0d49a1d7c4c64ba RC 5400ed4dd833af7 c60edac7 HASH flags=e
2023-05-22 13:33:21 avmike:D-remote: Phase 2 ready
2023-05-22 13:33:21 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 32E1E001 LT: 3600 I/O: IN
2023-05-22 13:33:21 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 36AF845A LT: 3600 I/O: OUT
2023-05-22 13:33:21 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 13:33:21 avmike:D-remote: start waiting connections
2023-05-22 13:33:21 avmike:D-remote: NO waiting connections
2023-05-22 13:33:31 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 13:39:14 avmike:D-remote: del phase 1 SA 3
2023-05-22 13:39:18 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=3,what=7,reason=Lifetime expired)
2023-05-22 13:39:18 avmike:FreeIPsecSA: spi=B10275EA        protocol=3 iotype=1
2023-05-22 13:39:18 avmike:FreeIPsecSA: spi=7304E9CF        protocol=3 iotype=2
2023-05-22 14:27:16 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 14:27:16 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC 2eb3b76bce7472d8 RC 00000000 0000 SA flags=
2023-05-22 14:27:17 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC 2eb3b76bce7472d8 RC 2fce5fc655f497bc 0000 SA flags=
2023-05-22 14:27:17 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 14:27:17 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:5
2023-05-22 14:27:17 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 14:27:17 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 14:27:17 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 14:27:17 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC 2eb3b76bce7472d8 RC 2fce5fc655f497bc 0000 HASH flags=e
2023-05-22 14:27:17 avmike:D-remote: Phase 1 ready
2023-05-22 14:27:17 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 14:27:17 avmike:D-remote: local is behind a nat
2023-05-22 14:27:17 avmike:D-remote: remote is behind a nat
2023-05-22 14:27:17 avmike:D-remote: start waiting connections
2023-05-22 14:27:17 avmike:D-remote: NO waiting connections
2023-05-22 14:27:22 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 14:27:22 avmike:D-remote: Phase 2 starting
2023-05-22 14:27:22 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 2eb3b76bce7472d8 RC 2fce5fc655f497bc 61d197e0 HASH flags=e
2023-05-22 14:27:23 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 2eb3b76bce7472d8 RC 2fce5fc655f497bc 61d197e0 HASH flags=e
2023-05-22 14:27:24 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 2eb3b76bce7472d8 RC 2fce5fc655f497bc 61d197e0 HASH flags=e
2023-05-22 14:27:24 avmike:D-remote: Phase 2 ready
2023-05-22 14:27:24 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 53533876 LT: 3600 I/O: IN
2023-05-22 14:27:24 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: CACAD345 LT: 3600 I/O: OUT
2023-05-22 14:27:24 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 14:27:24 avmike:D-remote: start waiting connections
2023-05-22 14:27:24 avmike:D-remote: NO waiting connections
2023-05-22 14:27:34 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 14:33:16 avmike:D-remote: del phase 1 SA 4
2023-05-22 14:33:21 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=4,what=7,reason=Lifetime expired)
2023-05-22 14:33:21 avmike:FreeIPsecSA: spi=32E1E001        protocol=3 iotype=1
2023-05-22 14:33:21 avmike:FreeIPsecSA: spi=36AF845A        protocol=3 iotype=2
2023-05-22 15:21:17 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 15:21:18 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC 325ae34e986c24a7 RC 00000000 0000 SA flags=
2023-05-22 15:21:19 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC 325ae34e986c24a7 RC b9c1f3d149394f2 0000 SA flags=
2023-05-22 15:21:19 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 15:21:19 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:6
2023-05-22 15:21:19 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 15:21:19 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 15:21:19 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 15:21:19 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC 325ae34e986c24a7 RC b9c1f3d149394f2 0000 HASH flags=e
2023-05-22 15:21:19 avmike:D-remote: Phase 1 ready
2023-05-22 15:21:19 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 15:21:19 avmike:D-remote: local is behind a nat
2023-05-22 15:21:19 avmike:D-remote: remote is behind a nat
2023-05-22 15:21:19 avmike:D-remote: start waiting connections
2023-05-22 15:21:19 avmike:D-remote: NO waiting connections
2023-05-22 15:21:25 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 15:21:25 avmike:D-remote: Phase 2 starting
2023-05-22 15:21:25 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 325ae34e986c24a7 RC b9c1f3d149394f2 d08a8a2 HASH flags=e
2023-05-22 15:21:26 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 325ae34e986c24a7 RC b9c1f3d149394f2 d08a8a2 HASH flags=e
2023-05-22 15:21:27 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 325ae34e986c24a7 RC b9c1f3d149394f2 d08a8a2 HASH flags=e
2023-05-22 15:21:27 avmike:D-remote: Phase 2 ready
2023-05-22 15:21:27 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 4E809C6E LT: 3600 I/O: IN
2023-05-22 15:21:27 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: DCF3E4D7 LT: 3600 I/O: OUT
2023-05-22 15:21:27 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 15:21:27 avmike:D-remote: start waiting connections
2023-05-22 15:21:27 avmike:D-remote: NO waiting connections
2023-05-22 15:21:37 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 15:27:17 avmike:D-remote: del phase 1 SA 5
2023-05-22 15:27:24 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=5,what=7,reason=Lifetime expired)
2023-05-22 15:27:24 avmike:FreeIPsecSA: spi=53533876        protocol=3 iotype=1
2023-05-22 15:27:24 avmike:FreeIPsecSA: spi=CACAD345        protocol=3 iotype=2
2023-05-22 16:15:19 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 16:15:20 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC ec3e6906f1d7c42c RC 00000000 0000 SA flags=
2023-05-22 16:15:20 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC ec3e6906f1d7c42c RC 67a635283f03c246 0000 SA flags=
2023-05-22 16:15:20 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 16:15:21 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:7
2023-05-22 16:15:21 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 16:15:21 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 16:15:21 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 16:15:21 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC ec3e6906f1d7c42c RC 67a635283f03c246 0000 HASH flags=e
2023-05-22 16:15:21 avmike:D-remote: Phase 1 ready
2023-05-22 16:15:21 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 16:15:21 avmike:D-remote: local is behind a nat
2023-05-22 16:15:21 avmike:D-remote: remote is behind a nat
2023-05-22 16:15:21 avmike:D-remote: start waiting connections
2023-05-22 16:15:21 avmike:D-remote: NO waiting connections
2023-05-22 16:15:28 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 16:15:28 avmike:D-remote: Phase 2 starting
2023-05-22 16:15:28 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC ec3e6906f1d7c42c RC 67a635283f03c246 a5ba9d5b HASH flags=e
2023-05-22 16:15:29 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC ec3e6906f1d7c42c RC 67a635283f03c246 a5ba9d5b HASH flags=e
2023-05-22 16:15:29 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC ec3e6906f1d7c42c RC 67a635283f03c246 a5ba9d5b HASH flags=e
2023-05-22 16:15:29 avmike:D-remote: Phase 2 ready
2023-05-22 16:15:29 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 534BA1BB LT: 3600 I/O: IN
2023-05-22 16:15:29 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: BD123945 LT: 3600 I/O: OUT
2023-05-22 16:15:29 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 16:15:29 avmike:D-remote: start waiting connections
2023-05-22 16:15:29 avmike:D-remote: NO waiting connections
2023-05-22 16:15:39 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 16:21:19 avmike:D-remote: del phase 1 SA 6
2023-05-22 16:21:27 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=6,what=7,reason=Lifetime expired)
2023-05-22 16:21:27 avmike:FreeIPsecSA: spi=4E809C6E        protocol=3 iotype=1
2023-05-22 16:21:27 avmike:FreeIPsecSA: spi=DCF3E4D7        protocol=3 iotype=2
2023-05-22 17:09:21 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 17:09:21 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC f10fccf981d7986f RC 00000000 0000 SA flags=
2023-05-22 17:09:22 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC f10fccf981d7986f RC ff8ea6ee920fdf55 0000 SA flags=
2023-05-22 17:09:22 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 17:09:23 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:8
2023-05-22 17:09:23 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 17:09:23 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 17:09:23 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 17:09:23 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC f10fccf981d7986f RC ff8ea6ee920fdf55 0000 HASH flags=e
2023-05-22 17:09:23 avmike:D-remote: Phase 1 ready
2023-05-22 17:09:23 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 17:09:23 avmike:D-remote: local is behind a nat
2023-05-22 17:09:23 avmike:D-remote: remote is behind a nat
2023-05-22 17:09:23 avmike:D-remote: start waiting connections
2023-05-22 17:09:23 avmike:D-remote: NO waiting connections
2023-05-22 17:09:31 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 17:09:31 avmike:D-remote: Phase 2 starting
2023-05-22 17:09:31 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC f10fccf981d7986f RC ff8ea6ee920fdf55 6b40cf0f HASH flags=e
2023-05-22 17:09:32 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC f10fccf981d7986f RC ff8ea6ee920fdf55 6b40cf0f HASH flags=e
2023-05-22 17:09:32 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC f10fccf981d7986f RC ff8ea6ee920fdf55 6b40cf0f HASH flags=e
2023-05-22 17:09:32 avmike:D-remote: Phase 2 ready
2023-05-22 17:09:32 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 30EE5246 LT: 3600 I/O: IN
2023-05-22 17:09:32 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 24512D6E LT: 3600 I/O: OUT
2023-05-22 17:09:32 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 17:09:32 avmike:D-remote: start waiting connections
2023-05-22 17:09:32 avmike:D-remote: NO waiting connections
2023-05-22 17:09:42 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 17:15:21 avmike:D-remote: del phase 1 SA 7
2023-05-22 17:15:29 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=7,what=7,reason=Lifetime expired)
2023-05-22 17:15:29 avmike:FreeIPsecSA: spi=534BA1BB        protocol=3 iotype=1
2023-05-22 17:15:29 avmike:FreeIPsecSA: spi=BD123945        protocol=3 iotype=2
2023-05-22 18:03:23 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 18:03:23 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC 46b5aa1ab323cabc RC 00000000 0000 SA flags=
2023-05-22 18:03:24 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC 46b5aa1ab323cabc RC ee1b1899c484f5f2 0000 SA flags=
2023-05-22 18:03:24 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 18:03:24 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:9
2023-05-22 18:03:24 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 18:03:24 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 18:03:24 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 18:03:24 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC 46b5aa1ab323cabc RC ee1b1899c484f5f2 0000 HASH flags=e
2023-05-22 18:03:24 avmike:D-remote: Phase 1 ready
2023-05-22 18:03:24 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 18:03:24 avmike:D-remote: local is behind a nat
2023-05-22 18:03:24 avmike:D-remote: remote is behind a nat
2023-05-22 18:03:24 avmike:D-remote: start waiting connections
2023-05-22 18:03:24 avmike:D-remote: NO waiting connections
2023-05-22 18:03:33 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 18:03:33 avmike:D-remote: Phase 2 starting
2023-05-22 18:03:34 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 46b5aa1ab323cabc RC ee1b1899c484f5f2 8fe12b43 HASH flags=e
2023-05-22 18:03:35 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 46b5aa1ab323cabc RC ee1b1899c484f5f2 8fe12b43 HASH flags=e
2023-05-22 18:03:35 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 46b5aa1ab323cabc RC ee1b1899c484f5f2 8fe12b43 HASH flags=e
2023-05-22 18:03:35 avmike:D-remote: Phase 2 ready
2023-05-22 18:03:35 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: A908E4C4 LT: 3600 I/O: IN
2023-05-22 18:03:35 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 43930782 LT: 3600 I/O: OUT
2023-05-22 18:03:35 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 18:03:35 avmike:D-remote: start waiting connections
2023-05-22 18:03:35 avmike:D-remote: NO waiting connections
2023-05-22 18:03:45 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 18:09:23 avmike:D-remote: del phase 1 SA 8
2023-05-22 18:09:32 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=8,what=7,reason=Lifetime expired)
2023-05-22 18:09:32 avmike:FreeIPsecSA: spi=30EE5246        protocol=3 iotype=1
2023-05-22 18:09:32 avmike:FreeIPsecSA: spi=24512D6E        protocol=3 iotype=2
2023-05-22 18:57:24 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 18:57:25 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC 9f8f181d5505070f RC 00000000 0000 SA flags=
2023-05-22 18:57:26 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC 9f8f181d5505070f RC a18b5bf623353776 0000 SA flags=
2023-05-22 18:57:26 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 18:57:26 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:10
2023-05-22 18:57:26 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 18:57:26 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 18:57:26 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 18:57:26 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC 9f8f181d5505070f RC a18b5bf623353776 0000 HASH flags=e
2023-05-22 18:57:26 avmike:D-remote: Phase 1 ready
2023-05-22 18:57:26 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 18:57:26 avmike:D-remote: local is behind a nat
2023-05-22 18:57:26 avmike:D-remote: remote is behind a nat
2023-05-22 18:57:26 avmike:D-remote: start waiting connections
2023-05-22 18:57:26 avmike:D-remote: NO waiting connections
2023-05-22 18:57:37 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 18:57:37 avmike:D-remote: Phase 2 starting
2023-05-22 18:57:37 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 9f8f181d5505070f RC a18b5bf623353776 efb477c7 HASH flags=e
2023-05-22 18:57:38 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 9f8f181d5505070f RC a18b5bf623353776 efb477c7 HASH flags=e
2023-05-22 18:57:38 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 9f8f181d5505070f RC a18b5bf623353776 efb477c7 HASH flags=e
2023-05-22 18:57:38 avmike:D-remote: Phase 2 ready
2023-05-22 18:57:38 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: B1C21EDF LT: 3600 I/O: IN
2023-05-22 18:57:38 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: E966F0B1 LT: 3600 I/O: OUT
2023-05-22 18:57:38 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 18:57:38 avmike:D-remote: start waiting connections
2023-05-22 18:57:38 avmike:D-remote: NO waiting connections
2023-05-22 18:57:48 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 19:03:24 avmike:D-remote: del phase 1 SA 9
2023-05-22 19:03:35 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=9,what=7,reason=Lifetime expired)
2023-05-22 19:03:35 avmike:FreeIPsecSA: spi=A908E4C4        protocol=3 iotype=1
2023-05-22 19:03:35 avmike:FreeIPsecSA: spi=43930782        protocol=3 iotype=2
2023-05-22 19:51:26 avmike:wolke_neighbour_renew_sa 1 SAs
2023-05-22 19:51:27 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 709 IC 63e4663fe8128f2d RC 00000000 0000 SA flags=
2023-05-22 19:51:27 avmike:<<< 4500 aggressive mode[92.116.84.xxx:4500] D-remote: V1.0 579 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 0000 SA flags=
2023-05-22 19:51:27 avmike:aggressive mode D-remote: selected lifetime: 3600 sec(no notify)
2023-05-22 19:51:28 avmike:D-remote: add phase 1 SA: DH2/AES-256/SHA2-512/3600sec id:11
2023-05-22 19:51:28 avmike:D-remote receive VENDOR ID Payload: XAUTH
2023-05-22 19:51:28 avmike:D-remote receive VENDOR ID Payload: DPD
2023-05-22 19:51:28 avmike:D-remote receive VENDOR ID Payload: NAT-T RFC 3947
2023-05-22 19:51:28 avmike:>>> aggressive mode 4500[92.116.84.xxx:4500] D-remote: V1.0 236 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 0000 HASH flags=e
2023-05-22 19:51:28 avmike:D-remote: Phase 1 ready
2023-05-22 19:51:28 avmike:D-remote: current=92.116.84.xxx new=92.116.84.xxx
2023-05-22 19:51:28 avmike:D-remote: local is behind a nat
2023-05-22 19:51:28 avmike:D-remote: remote is behind a nat
2023-05-22 19:51:28 avmike:D-remote: start waiting connections
2023-05-22 19:51:28 avmike:D-remote: NO waiting connections
2023-05-22 19:51:39 avmike:< create_sa(appl=vpnd,cname=D-remote)
2023-05-22 19:51:39 avmike:D-remote: Phase 2 starting
2023-05-22 19:51:40 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 764 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 b646902f HASH flags=e
2023-05-22 19:51:41 avmike:<<< 4500 quickmode[92.116.84.xxx:4500] D-remote: V1.0 348 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 b646902f HASH flags=e
2023-05-22 19:51:41 avmike:>>> quickmode 4500[92.116.84.xxx:4500] D-remote: V1.0 108 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 b646902f HASH flags=e
2023-05-22 19:51:41 avmike:D-remote: Phase 2 ready
2023-05-22 19:51:41 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: DB223754 LT: 3600 I/O: IN
2023-05-22 19:51:41 avmike:NEW Phase 2 SA: ESP-AES-256/SHA2-512 SPI: 523D16FE LT: 3600 I/O: OUT
2023-05-22 19:51:41 avmike:D-remote stop_vpn_keepalive to 192.168.1.1
2023-05-22 19:51:41 avmike:D-remote: start waiting connections
2023-05-22 19:51:41 avmike:D-remote: NO waiting connections
2023-05-22 19:51:51 avmike:>>>4500 nat-t-keepalive[92.116.84.xxx:4500]
2023-05-22 19:52:26 avmike:>r> infomode 4500[92.116.84.xxx:4500] D-remote: V1.0 140 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 653786ad HASH flags=e
2023-05-22 19:52:26 avmike:<<< 4500 infomode[92.116.84.xxx:4500] D-remote: V1.0 140 IC 63e4663fe8128f2d RC fcbe3cd0579beaf7 653786ad HASH flags=e
2023-05-22 19:57:26 avmike:D-remote: del phase 1 SA 10
2023-05-22 19:57:38 avmike:< delete_sa(appl=vpnd,cname=D-remote,id=10,what=7,reason=Lifetime expired)
2023-05-22 19:57:38 avmike:FreeIPsecSA: spi=B1C21EDF        protocol=3 iotype=1
2023-05-22 19:57:38 avmike:FreeIPsecSA: spi=E966F0B1        protocol=3 iotype=2

"D-remote": Name der VPN Verbindung. 92.116.84.xxx = IP in Deutschland (kann ich anpingen).

Ich habe die Supportdaten zuletzt vor ein paar Jahren gebraucht. Seitdem lief ja alles problemlos - bis zum 16. März.

Die Wireguard Fehlermeldung kommt aus der FB mit Labor 7.51.

Ein generelles VPN-Problem bei SFR wäre eher unwahrscheinlich. Ich kann über Wireguard (läuft auf meinem Raspi in D) meine Fritzbox in D erreichen.

 

[tplus]

Okay, das Problem ist gelöst. Aber nicht über Gewürge mit den Fritzboxen sondern mit einem Zerotier Netz.

Das Netz ist in Minuten eingerichtet, kostenlos und funktioniert perfekt. Ich kann (über die Raspis) auf alle IPs der Netzwerke zugreifen, auch vom Smartphone, CGNAT stört nicht. DynDNS oder MyFritz ist nicht erforderlich. Geschwindigkeitseinbußen gibt es nicht, da ja der Traffic direkt von peer zu peer läuft.

Es wäre schön, wenn AVM Zerotier in die Boxen integrieren würde.

Ich kann nur jedem mit ähnlichen Problemen empfehlen sofort diesen Weg zu gehen.

Trotzdem besten Dank für die Hilfe...

 

[PeterPawn]

Ich kann nur jedem mit ähnlichen Problemen empfehlen sofort diesen Weg zu gehen.

Na ja ... da übersiehst Du (für meinen Geschmack) deutlich zu viele Faktoren - angefangen bei der Verfügbarkeit entsprechender Klein-Computer, falls man die eben NICHT gerade noch herumliegen hat oder sie gar an JEDEM zu verbindenden Standort schon einsetzt.

Die Regale bei den üblichen Verdächtigen, die den Raspberry Pi zu regulären(!) Preisen anbieten (weil sie offizielle Reseller sind), sind praktisch leer - exemplarisch mal ein (durchaus bekannter) Reseller hier aus Berlin: https://www.berrybase.de/raspberry-pi/raspberry-pi-computer/boards/?p=1&o=2&n=36&delivery=1

Ansonsten werden schon für die blanken Boards (da braucht es dann meistens noch Netzteil, Kühlung (beim Pi 4 nach meiner Erfahrung unumgänglich), HDMI-Kabel (außer man installiert tatsächlich "blind", ist dann aber bei Problemen auch ziemlich hilflos) und sicherlich auch irgendetwas wie ein Gehäuse - alles in allem sind das üblicherweise auch noch einmal 30 bis 50 EUR "Aufpreis", wenn man auch noch eine einigermaßen große SD-Karte einrechnet) mittlerweile für echt astronomische Preise gehandelt (Pi 4 mit 4 GB für 175 EUR) - wenn die diversen Treffer in Preissuchmaschinen nicht am Ende sogar auf Fake-Shops landen.

Deine Empfehlung erinnert mich daher etwas an den berühmt-berüchtigten Ausspruch mit dem Kuchenessen, der (vermutlich zu Unrecht) der ehemaligen framzösischen Königin zugeschrieben wird - selbst wenn jemand gewillt ist, sich tatsächlich für jeden Standort noch zusätzlich einen Klein-Computer wie den Raspberry Pi zuzulegen, scheitert das heutzutage häufig schon an der Verfügbarkeit dieser Geräte, sofern man nicht Mondpreise dafür ausgeben will, für die man glatt eine weitere FRITZ!Box bekäme.

Und mit systematischer Fehlersuche dürften auch (die meisten) VPN-Probleme bei der Verwendung von IPSec (oder ab 07.5x auch auf der Basis von WireGuard®) zu lösen sein ... nur muß man dafür eben auch den Willen haben, das tatsächlich SYSTEMATISCH anzugehen und davon war (nach meiner Einschätzung) hier bisher deutlich zu wenig zu sehen. Auch das "nachgereichte" VPN-Protokoll aus den Support-Daten der Box in F (in #12) entsprach eben nicht mal im Ansatz dem, was tatsächlich erforderlich wäre.

Im Gegensatz zu den ausdrücklichen Hinweisen, was man VOR dem Erstellen der Support-Daten ausführen sollte, wurde auch hier nur irgendein Protokoll aus einem bereits länger laufenden System bereitgestellt, in dem noch nicht einmal der Beginn des Protokolls nach dem letzten Booten des Routers zu finden ist, sich die ständigen Erneuerungen der SA für P1 und P2 über mehrere Stunden erstrecken (WANN da tatsächlich mal Daten übertragen werden sollten in den 7 Stunden und 18 Minuten, über die sich das Protokoll erstreckt, muß man auch "raten" - zu sehen sind jedenfalls erfolgreiche Erneuerungen nach jeweils 90% der "lifetime" einer früher erstellten SA) und es fehlt natürlich auch das Protokoll für den Peer - wobei anzunehmen ist, daß sich darin auch nichts wirklich Ungewöhnliches finden dürfte.

Da dann jeweils für 6 Minuten ZWEI SA parallel existieren, stellt sich die Frage, welche SPI tatsächlich für die Verschlüsselung der zu übertragenden Daten verwendet werden (oder ob gar zweimal verschlüsselt und gesendet wird) - oder ob am Ende, beim Einrichten einer neuen SA von der Initiator-Seite aus, die vorherigen SA auf der Responder-Seite DIREKT abgeräumt werden und das nur auf der Initiator-Seite nicht unmittelbar erfolgt, sondern erst zum Ende der vereinbarten Lifetime.

Vermutlich dürfte es da sogar zwischen der 7490 und einer 7590 noch erhebliche Unterschiede geben bei der Aufgabenverteilung zwischen den VPN-Komponenten ... denn im Gegensatz zu einer 7590, ist bei der 7490 auch der (EDIT: ohnehin nur rudimentäre) XFRM-Support im Kernel gar nicht aktiviert:

vidar:~/._fritzbox $ grep XFRM FB7490/firmware/GPL_07.27/linux/avm/conf/linux-3.10.vr9
# CONFIG_XFRM_USER is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
vidar:~/._fritzbox $ grep XFRM FB7590/GPL_07.50/sources/kernel/linux/avm/conf/linux-4.9.grx5
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
CONFIG_XFRM_INTERFACE=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
CONFIG_XFRM_STATISTICS=y
CONFIG_XFRM_IPCOMP=m
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET6_XFRM_TUNNEL=m
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_SECURITY_NETWORK_XFRM is not set
vidar:~/._fritzbox $

Daher muß man bei solchen Problemen eben auch immer genau hinsehen, welche FRITZ!Box-Modelle mit welchen FRITZ!OS-Versionen zum Einsatz kommen, aber es dürfte jedenfalls auch beim IPSec-VPN von AVM keine GRUNDSÄTZLICHEN Probleme geben, denn dann würden sich hier (nach meiner Ansicht) deutlich mehr Leute mit solchen Themen melden - sowohl für die aktuelle als "stable" gehandelten Versionen als auch für die Inhouse- und Labor-Reihen.

Nach meiner (aber deutlich unmaßgeblichen) Meinung handelt(e) es sich hier um ein Problem im Einzelfall und das dürfte eher mit einer falschen Konfiguration oder sehr ungewöhnlichen Umständen in Verbindung stehen (siehe das Durcheinander bei den Portnummern, was ich oben angetextet hatte).

Auch wenn ich NATÜRLICH gelesen habe, daß das alles schon mal funktionierte - nur hört das dann eben auch nicht "einfach so" auf zu funktionieren und die Spanne der möglichen Fehlerquellen nach irgendwelchen Änderungen reicht hier eben vom Provider in F und der verwendeten "Transport-Technik" (es ist ja offensichtlich ein LTE-Stick an der 7490 als Modem in Benutzung) bis zu (ggf. auch "unbemerkten") Updates der Firmware beteiligter Geräte. Darauf basierend jetzt die pauschale Aussage zu treffen, man solle sich lieber gleich auf eine Zerotier-basierte Lösung verlegen, finde ich etwas kühn.

Und dem frommen Wunsch an AVM, man möge dort doch bitte auch noch ZeroTier implementieren, dürften am Ende die Lizenzbestimmungen für die Zerotier-Software im Wege stehen: https://github.com/zerotier/ZeroTierOne/blob/dev/LICENSE.txt:

Additional Use Grant:
You may make use of the Licensed Work, provided you do not use it in any of the following ways:

* Sell hosted ZeroTier services as a "SaaS" Product
[...]
* Create Non-Open-Source Commercial Derviative Works (Buchstabendreher aus dem Original übernommen)
[...]
* Certain Government Uses

(der rot markierte Punkt dürfte nicht so nach dem Geschmack von AVM sein) - wobei auch noch in #13 durchscheinende Mißverständnisse hinsichtlich der Architektur eines ZeroTier-Netzwerks zu klären sein könnten.

Was ich hier aber tatsächlich nicht weiter vertiefen will ... man KANN sicherlich (mit entsprechenden Ressourcen) seine Standorte auch mit einem VPN vernetzen, das auf ZeroTier basiert (was bei der Kryptographie dieselben (bzw. sehr ähnliche) Funktionen verwendet, wie WireGuard® und daher auch mit den derzeit verfügbaren Prozessoren (in den Boxen) nicht mit Hardware-Support betrieben werden kann), aber das jetzt direkt als alleinigen "Königsweg" ansehen zu wollen, ist etwas sehr euphorisch (und einseitig) in meinen Augen und wird den anderen VPN-Lösungen nicht gerecht. Nur weil man selbst damit nicht anders klar kam, muß man nicht anderen gleich empfehlen, diese Lösungen komplett zu vergessen und "something completely different" zu versuchen - nicht jeder ist ein "trial & error"-"Bastler".

 

[tplus]

Die Kleincomputer (Raspis) sind nur im Zeronet weil ich auf Resourcen eben auf diesen Geräten (z. B. FHEM) zugreifen will und auf andere Kleingeräte im Netz (z. B. Shellys). Für das Netz selbst braucht man sie nicht. So ist für die Vernetzung von Windows PCs und Smartphones keine weitere Hardware erforderlich, nur Software-Clients auf den Geräten.

Auf das Zerotier Netz (und ähnliche) bin ich über einen Artikel in der c't (07/23) aufmerksam geworden, nur damals dachte ich "interessant, brauche ich aber nicht, bei mir läuft ja schon alles problemlos" ;( . Auch c't hatte die Netze für die empfohlen, die sich einfach nur problemlos um die vernetzten Geräte kümmern wollen, nicht um die Verbindung selbst.

Der AVM Support war übrigens auch überfragt. Die zu prüfenden Punkte habe ich alle abgehakt. Zuletzt empfahl man IPv6 auf beiden Seiten abzuschalten (jetzt nur in D aktiv). Vermutet wurde ein Problem mit dem CGNAT (problemlos genutzt seit 2018).

Als "Königsweg" habe ich Zerotier nicht empfohlen, nur eben für Leute mit ähnlichen Problemen die schon einige Stunden Arbeit fruchtlos investiert haben und die dann mal eben in 10 Min. ein funktionierendes Netz wollen. So laboriert hier im Forum Master1 seit zwei Wochen mit Selfhost auf der 7490 'rum (läuft bei mir problemlos). Könnte er sich - vermutlich - sparen. Dyndns braucht man für Zerotier nicht. Und: Der "Wireguard"-Thread ist 23 Seiten lang (bis jetzt)!

Zerotier bietet das Netz auch für "Service Providers" an: "For hardware and software companies interested in embedding or integrating the ZeroTier platform within their service offering, as well as enterprise-facing channels including Managed Service Providers (MSPs), Resellers, and Systems Integrators".

Nur hier bräuchte man ein "AVM-NETZ" gar nicht, nur den Client auf dem Router, mit dem die Nutzer - AGB konform - das Zerotier Netzwerk oder sogar ein selbst gehostetes Zerotier Netzwerk (Open Source) nutzen könnten. Es gibt schon Clients für OpenWRT, Microtik und Teltonika Router und verschiedene NAS. Warum nicht auch für die FB?

Ich bin sicher, dass in Zukunft diese Art der Vernetzung IPsec, Wireguard etc. verdrängen wird.

 

[frank_m24]

Nicht vergessen sollte man in dem Zusammenhang auch die Daten, die man Zerotier zwangsläufig preisgibt. Immer dran denken: Wenn etwas für dich umsonst ist, bist du das Produkt.

 

[tplus]

Welche Daten sind das denn? Das jemand mit dieser e-mail diese Geräte in diesen IP-Netzen betreibt. Und wie oft da Daten übertragen werden. Also ungefähr das, was jeder Netzbetreiber oder DynDNS Anbieter ("myfritz") mitbekommt. Kein Vergleich etwa zu dem, was ein e-mail Provider abgreifen könnte. Und von Google brauchen wir dann gar nicht erst zu reden. Wem das zu viel ist, der muss sich ganz abschalten.

Bei Paranoia könnte man den Zerotier Service als Open Source auch selbst hosten. Ist bei Github.

Das Geschäftsmodell ist wohl "Freemium" und auch solches auch unproblematisch denn laufende Kosten für den Netzbetrieb sind minimal. Die "Payload" wird ja nicht über deren Server übertragen.

 

[frank_m24]

Welche Daten sind das denn?

Die kompletten Meta Daten. Unter anderem, welche Geräte wann von wo wie lange miteinander kommuniziert haben. Es ist ein leichtes, daraus komplette Profile über berufliche Tätigkeiten, Freizeitaktivitäten, Hobbys, Freundeskreise usw. abzuleiten. Also erheblich mehr, als es ein reiner dyndns oder Mail Dienste könnte, da immer zahlreiche Heimgeräte involviert sind und u.a. auch die Dauer der Verbindung und Mobilität der Endgeräte erfasst werden. Nicht zuletzt haben die Betreiber prinzipiell Zugriff auf die Schlüssel. In der Open Source Software kann man sehen, dass die nicht benutzt werden, aber kommt die Open Source Software unverändert zum Einsatz?

Ich will nicht sagen, dass das ein Show-Stopper ist. Technisch funktionieren diese Dienste hervorragend. Aber wenn man Facebook, Google und co verteufelt aufgrund ihrer Daten-Kraken-Mentalität, dann sollte man diese Dienste mindestens auf gleicher Ebene vermerken, denn sie haben Zugriff auf mindestens die gleichen Daten - vermutlich auf mehr.

Bei Paranoia könnte man den Zerotier Service als Open Source auch selbst hosten. Ist bei Github.

Das würde ich jedem dringen empfehlen. Allerdings erfordert es einen erheblichen administrativen Aufwand und technische Voraussetzungen, sodass eine einfache Wireguard Installation weniger Aufwand erzeugt.

 

[tplus]

Ich bezweifle, dass es ein leichtes ist, aus den IP und Metadaten "komplette Profile über berufliche Tätigkeiten, Freizeitaktivitäten, Hobbys, Freundeskreise usw. abzuleiten":

Das Android Smartphone von "e-mail" war in Nordhessen und hat 5 MB Daten mit einem Linux Gerät im südlichen Niedersachsen übertragen.

Was sagt uns das über die "Hobbies und Freundeskreise" von "e-mail" (auch Trashmail)? Die zahlreichen Heimgeräte haben keinen Client sondern nutzen den Raspi als Gateway.

Wenn es stattdessen eine Wireguard Verbindung gewesen wäre, hätte mein Netzbetreiber dieselbe Information (ohne Linux). Und der wüsste sogar die genaue Adresse und meinen Namen.

Wie gesagt, bei solchen Bedenken sollte man Google absolut meiden. Messenger ("KOMPLETTER FREUNDESKREIS MIT TELEFONNUMMERN"!) sind no-go. In Foren sollte man glaube ich auch nicht posten. Und natürlich immer alles über einen selbst gehosteten VPN Server (wo?) laufen lassen.

Wenn meine Privatsphäre durch Internet zu 80% kompromittiert ist, ist sie das nach Nutzung von Zerotier zu 80,1%.

 

[frank_m24]

Das Android Smartphone von "e-mail" war in Nordhessen und hat 5 MB Daten mit einem Linux Gerät im südlichen Niedersachsen übertragen.

Ja, und all deine anderen Geräte kennen sie auch. Sie wissen, wo sie stehen, wenn sie online sind, und aus dem Aktivitätsprofil lässt sich ableiten, was es ist. Eine Kamera verhält sich anders, als ein smartes Thermometer oder ein Staubsauger. Sie wissen sogar, welchen Staubsauger du benutzt.

Aber folgendes Szenario: Deine mobilen Endgeräte gehen via Zerotier online. Das machen sie von einer spezifischen IP Adresse aus. Morgens nach dem Aufstehen kommt sie von dir zu Hause. Dann eine Zeitlang aus dem Mobilfunknetz (Weg zur Arbeit. Aus Zeit und Strecke lässt sich ableiten: Auto, Zug, Fahrrad). Dann von deinem Arbeitsplatz (=Arbeitgeber). Mittags aus dem Hotspot des angrenzenden Restaurants. Abends dann wieder Mobilfunk (Weg nach Hause). Dann noch Squash Center, Kneipe und wieder zu Hause. Am nächsten Abend mal Freunde besucht (ggf. deren IP benutzt über ein Gastnetz) ... usw. Am Wochenende Einkaufen in der Shopping Mall und Fahrradtour. Urlaub, Dienstreisen, Autohändler, Möbelhäuser, Supermärkte, der Hofladen um die Ecke ... lass ihnen einige Monate, und sie kennen deinen Alltag besser, als dein Tagebuch. Und dafür brauchst du ÜBERHAUPT NICHTS zu tun, als nur ab und an Zerotier zu benutzen.

Und deshalb läuft bei mir ein VPN auf MEINEM Server. Das weiß ich, was mit den IPs passiert, die geloggt werden.

Wie gesagt, bei solchen Bedenken sollte man Google absolut meiden.

Stimmt. Schreib ich ja auch. Aber viele nutzen solche Dienste, mit der Begründung, dass sie den Providern oder Diensten wie Google nicht trauen, und deshalb lieber über die Fritzbox zu Hause online gehen. Da das VPN an sich sie überfordert, nutzen sie dann Zerotier. Tja ...