Die beiden anderen VPN-Verbindungen sind der Beschreibung nach zu urteilen aber Client2LAN-Verbindungen (conn_type = conntype_user
und da funktioniert das anders (Proxy-ARP für eine lokale IP-Adresse, die dem entfernten Client fest zugeordnet wurde). Das ist mit der LAN-LAN-Kopplung netzwerktechnisch schwer zu vergleichen ... einiges ist identisch, anderes vollkommen anders.
Deine Aussage, daß es nicht an der Firewall liegen kann/sollte, ist bei genauerer Betrachtung doch unsinnig ... ich habe ja ausdrücklich geschrieben (und im verlinkten AVM-Artikel steht es unter 3. ebenfalls noch einmal), daß eben die Windows-Firewall es nicht mag, wenn ein Request von einer
nicht-lokalen Adresse eingeht. Bei der Client2LAN-Verbindung hat das MacBook bzw. das Smartphone aber genau diese lokale IP-Adresse und ist damit für einen Windows-Server gar nicht von einem lokalen Client zu unterscheiden. Bei einer LAN-LAN-Kopplung erfolgt aber kein NAT für das entfernte Netz, damit sieht der Host die originale Adresse des entfernten Clients und die gehört eben per Definition nicht zu seinem lokalen Segment. Das muß - nebenbei bemerkt - nicht nur für Windows-Systeme mit der dort eingebauten Firewall gelten, das kann - je nach Konfiguration - auch andere Plattformen betreffen, weil natürlich die nicht-lokale Adresse auch für diese gilt und so eine Regel "lokaler Verkehr ist zulässig" meist zum Grundbestand eines (automatisch erzeugten) Regelsatzes gehört.
Aber ehrlich ... wenn Du meine Ideen so weit anzweifelst, daß Du am Ende nicht einmal in Erwägung ziehst, sie wenigstens mal testweise umzusetzen, dann wird das eine ziemlich fruchtlose Veranstaltung, in der ich meine Zeit nur mit dem Schreiben ausführlicher Antworten (samt Begründungen, warum ich das wissen will/muß) vergeude, während Du recht lapidar erklärst, daß es ja "vermutlich etwas anderes sein sollte" und Du es damit eigentlich besser wissen willst.
Wenn Du das wenigstens noch
schlüssig begründest, dann ist so ein Widerspruch auch gar kein Problem, aber wenn dabei Äpfel mit Birnen verglichen werden (wir haben diese Diskussion hier auch immer wieder im Zusammenhang mit irgendwelcher AV-Software, wo die Leute auch bis aufs Messer streiten, daß es ja wohl kaum sein könne und dabei aber die Zusammenhänge einfach nicht überblicken und sich auch mit Argumenten nur sehr schwer davon überzeugen lassen, einfach mal die (falschen) gewohnten Antworten zu vergessen und es zu probieren), dann kostet das am Ende (den Antwortenden) mehr Zeit, die Leute von ihren falschen vorgefaßten Meinungen abzubringen, als es für einen kurzen Test oder eine wirklich passende und plausible Begründung, warum das nicht sein kann, gebraucht hätte (dann aber auf der Seite, die das Problem wirklich hat und dementsprechend auch das überwiegende Interesse an seiner Beseitigung zeigen sollte).
Gibt es irgendeinen Grund, warum Du partout nicht damit herausrücken willst, von welchem System auf welches System/welchen Dienst dort Du nun eigentlich zugreifen willst? Ich rede hier von dem System an 192.168.178.22 und ich komme mir irgendwie verarscht vor, weil ich das nun schon zweimal gefragt habe und immer noch keine belastbare Antwort erhalten habe. Jetzt klappt auf einmal der Zugriff von einem Gerät in 192.168.10.0/24 auf die FRITZ!Box selbst am anderen Ende schon nicht. Weitere Ausführungen zu den Fragen in Absatz 3 in #6 kann ich auch nicht wirklich erkennen.
Wenn Dein letzter Satz in #7 tatsächlich zum Ausdruck bringen soll, daß Du trotz aufgebauter VPN-Verbindung zwischen den Boxen (das steht eben im VPN-Protokoll und die Anzeige einer entfernten und einer lokalen IP-Adresse bei "VPN-Verbindungen" sagt nun mal noch gar nichts darüber aus, ob da P2 wirklich erfolgreich beendet wurde) von einem Gerät im Netz 192.168.10.0/24 nicht einmal auf das GUI der FRITZ!Box zugreifen kannst und diese auch per
ping nicht erreichbar ist, dann stimmt eben etwas Grundlegendes nicht an der Konfiguration und wie diese bei Dir jetzt aussieht bzw. ob da P2 wirklich erfolgreich war, muß man raten (auch wenn die Nachricht im Eventlog dafür spräche) ... obwohl Dir diese detaillierten Informationen zugänglich wären (und zwar in Form der konkreten Daten und nicht als mehr oder weniger genaue Um-/Beschreibung), willst Du sie offenbar nicht mit uns hier im IPPF teilen. Nicht einmal für die (mehr oder weniger verschlüsselt) erbetene Ausgabe von "traceroute" hat es bisher gereicht, die Ansage
n0m3k schrieb:
Traceroute läuft ewig und bringt keine Antwort.
kann kaum stimmen (wenigstens das lokale Gateway müßte ja noch antworten) oder es ist generell etwas falsch.
Das hätte dann tatsächlich nichts mit einer Windows-Firewall zu tun, wenn da nicht noch irgendeine AV-Suite auf dem Client in 192.168.10.0/24 die Antworten aus dem "fremden Netz" blockiert, weil irgendwann mal eine lokale FRITZ!Box mit der Adresse 192.168.178.1 existierte und nun die MAC-Adresse eine andere ist (wobei das ggf. nicht einmal zu erkennen ist). Auch da wäre es einfach wirklich wirklich hilfreich, wenn da mal konkrete Informationen kämen ... wenn aus dem anderen Netz versucht wird, den Telnet-Dienst auf einer FRITZ!Box zu benutzen und diese hat eine aktuelle originale Firmware, liegt das Problem mit einiger Wahrscheinlichkeit gar nicht in der VPN-Verbindung ... es gäbe schlicht diesen Dienst nicht.
Ich wüßte beim besten Willen auch nicht, was daran nun so geheim sein sollte, auf welchen Dienst konkret Du versuchst zuzugreifen und nicht einmal die Information, welcher Client dazu verwendet wird, kann ich so richtig als "schutzwürdig" ansehen. Am Ende sind das beim genaueren Hinschauen alles nur "Wischi-Waschi"-Aussagen, daß da etwas nicht wie erwartet funktioniert und kein Mensch weiß, was das am Ende wirklich ist und wie das konkrete Ergebnis aussieht ("geht nicht" ist kein konkreter Fehler). Wenn ich Dir die "Diagnose" meinerseits mitteile, daß mein Auto nicht anspringt (einfach mal angenommen, Du wärst jetzt dafür der richtige Ansprechpartner), ist es nun einmal ein gewaltiger Unterschied, ob das am fehlenden Kraftstoff oder an der Wegfahrsperre wegen des fehlenden Zündschlüssels liegt.
Nimm's mir übel oder nicht (ich habe versucht, die Grundlagen für die "Mitarbeit" schon in #2 zu beschreiben) ... aber wenn am Ende der Hilfewillige einen größeren Aufwand hat und mehr Energie in eine Lösung stecken muß als derjenige mit dem Problem, dann stimmt da irgendetwas an der Konstellation nicht. Es wäre also nett, wenn Du entweder wirklich mitmachst oder auch ganz klar erklärst, daß Du auf meine Hilfe lieber verzichten würdest, weil ich Dir zu komplizierte Rückfragen stelle und Du ohnehin nicht daran glaubst, daß ich Dir bei Deinem Problem helfen könnte. Beides spart Zeit ... und wenn Du das in #7 als "etwas ausholen" siehst (und das auch noch mit dem eher gequälten "Ok ok" einleitest - meine Güte, warum ist der bloß so neugierig, will der auch noch meine Schuhgröße wissen?), dann werden wir wohl noch recht lange brauchen und ob das dann wirklich Sinn macht, müßte man in Zweifel ziehen (auch wenn ich den Smiley gesehen habe).
