7490 VPN mit WebIf eingerichtet - klappt alles nur nicht das Internetrouting ..

[sidney2008]

Hallo,

habe auf einer Fritzbox 7490 mit dem Webinterface einen Fritzbox-User angelegt, der VPN Zugriff haben soll und die generierten Zugangsdaten auf einem IPad mit iOS 8.4 eingetragen.

Die VPN-Verbindung wird auch hergestellt und mit Status grünes Lämpchen in der Fritzbox 7490 angezeigt.
Ich kann dann auch die dem VPN-Client zugewiesene interne IP aus dem Netzwerk anpingen bzw. vom IPad bspw. einen IIS-Webserver im LAN aufrufen.

Was aber nicht geht: Wenn ich dann SAFARI starte und eine Webseite auf dem IPad bei aktivierter VPN aufrufen will, kommt keine Verbindung zustande. da angbelich das "IPad nicht mit dem Internet verbunden sei". Ist es aber, sonst hätte es die VPN nicht aufmachen können.

Ein Supporter von AVM meinte, dass defaultmäßig bei der Einrichtung über das WebIF der FB 7490 die VPN SO eingerichtet würde, dass der Internetzugang bei aktiver VPN über die FB 7490 gehandelt würde und nicht über die Client-Maschine (Hier das IPad). Es funktioniert aber wie o.a. nicht!

Noch ein Kuriosum:

Rufe ich den o.a. IIS von außen ohne VPN mittels DDNS-Adresse und eingerichtetem Portforwarding auf, erscheint ein Loginfenster SO wie es sein soll. MIT VPN erscheint das gleiche Loginfenster, aber der SUBMIT-Button bleibt ausgegraut und es wird eine Meldung ausgegeben, dass wohl kein JavaScript aktiviert sei. Ist es aber, sonst würde das Loginfenster ja auch nicht MIT Submitbutton erscheinen, wenn ich den IIS von außen OHNE VPN aufrufe. Es sieht fast so aus, als ob die VPN JavaScript-Probleme bereitet.

Hat von Euch jd. eine Idee, worauf die vorstehend beschriebenen zwei Probleme zurückzuführen sein könnten?

Danke und viele Grüße
sidney2008

 

[PeterPawn]

Hat von Euch jd. eine Idee, worauf die vorstehend beschriebenen zwei Probleme zurückzuführen sein könnten?

Zumindest bei einem Problem hätte ich eine Idee ... die Aussage des Supports

dass defaultmäßig bei der Einrichtung über das WebIF der FB 7490 die VPN SO eingerichtet würde, dass der Internetzugang bei aktiver VPN über die FB 7490 gehandelt würde und nicht über die Client-Maschine (Hier das IPad).

einfach mal auf ihren wahrscheinlichen Wahrheitsgehalt abklopfen ... durch eigenes Überlegen.

Mit welchen mystischen Kräften sollte denn eine FRITZ!Box einen VPN-Client (hier eben das iPad) zwingen, den kompletten Internet-Verkehr über den VPN-Tunnel abzuwickeln? Das kann sie max. durch das Übermitteln entsprechender IP-Konfigurationen für das IPSec auf dem Client ... ob der diese angebotenen Einstellungen dann annimmt (und seinerseits den Tunnel als Standard-Gateway benutzt), entscheidet er aber immer noch selbst. Bei iOS war das (zumindest früher) ganz simpel ein Schalter "für alle Daten", den man eben ein- oder ausschalten konnte.

Das zweite Problem habe ich auch nach mehrmaligem Lesen noch nicht richtig verstanden - insb. nicht den Zusammenhang mit dem ersten - ... wieso sich eine VPN-Verbindung auf JavaScript auswirken sollte (solange da keine "Antivirus"-Lösung irgendwelche Blockaden auslöst oder gar der IIS(???) selbst, weil es unterschiedliche Sichten auf die Netzwerke sind (einmal öffentlich, einmal privat - Du hast nicht zufällig auch unterschiedliche "access lists" im IIS für diese Netze?), die da zum Tragen kommen) erschließt sich mir auch nicht (wenn das der Kern des zweiten Problems sein sollte, ich werde ja nicht so richtig schlau aus der Beschreibung).

 

[sidney2008]

Zumindest bei einem Problem hätte ich eine Idee ... die Aussage des Supports

einfach mal auf ihren wahrscheinlichen Wahrheitsgehalt abklopfen ... durch eigenes Überlegen.

Mit welchen mystischen Kräften sollte denn eine FRITZ!Box einen VPN-Client (hier eben das iPad) zwingen, den kompletten Internet-Verkehr über den VPN-Tunnel abzuwickeln? Das kann sie max. durch das Übermitteln entsprechender IP-Konfigurationen für das IPSec auf dem Client ... ob der diese angebotenen Einstellungen dann annimmt (und seinerseits den Tunnel als Standard-Gateway benutzt), entscheidet er aber immer noch selbst. Bei iOS war das (zumindest früher) ganz simpel ein Schalter "für alle Daten", den man eben ein- oder ausschalten konnte.

Hallo,

vorab vielen Dank für Deinen Beitrag!

Letztlich ist es doch so, dass ENTWEDER der Tunnel als Gateway genutzt und über diesen der Internet-Zugang ablaufen müsste oder anderenfalls halt eben direkt über das IPad. Es funktioniert aber nach Aktivieren der VPN KEINE der beiden in Frage kommenden Möglichkeiten. Welchen Schalter Du mit "für alle Daten" meinst, kann ich derzeit leider nicht nachvollziehen.

Das zweite Problem habe ich auch nach mehrmaligem Lesen noch nicht richtig verstanden - insb. nicht den Zusammenhang mit dem ersten - ... wieso sich eine VPN-Verbindung auf JavaScript auswirken sollte (solange da keine "Antivirus"-Lösung irgendwelche Blockaden auslöst oder gar der IIS(???) selbst, weil es unterschiedliche Sichten auf die Netzwerke sind (einmal öffentlich, einmal privat - Du hast nicht zufällig auch unterschiedliche "access lists" im IIS für diese Netze?), die da zum Tragen kommen) erschließt sich mir auch nicht (wenn das der Kern des zweiten Problems sein sollte, ich werde ja nicht so richtig schlau aus der Beschreibung).

Es ist genau SO: Mit VPN-Tunnel kann ich den lokalen IIS und ein Loginscript aufrufen, aber dort nur Username/PW eingeben, ohne submitten zu können. Es erscheint ein Hinweis, dass JavaScript eingeschaltet werden müsse, was aber bereits der Fall ist. Im ISS sind aktuelle die Authentifizierungen deaktiviert, bis die VPN hoffentlich mal korrekt funktioniert.

Viele Grüße
sidney2008

 

[PeterPawn]

Der Schalter befindet sich beim iOS bei der VPN-Verbindung.

Beim IIS mußt Du dann eben mal testen, ob der an das per VPN angebundene iPad (oder ist das dann ein anderer VPN-Client) überhaupt die JS-Files (so die gesondert sind) ausliefert.

 

[HabNeFritzbox]

Problem ist nicht Internet oder Routing sondern DNS.

Daher klappt Zugriff per IP.

In FB den NetBios Filter deaktivieren, übernehmen und wieder aktivieren.

Thema ist nicht neu...

 

[PeterPawn]

@HabNeFritzbox:
Nur mal so aus Spaß ... welches der beiden Probleme würdest Du denn mit einer nicht funktionierenden DNS-Auflösung in Zusammenhang bringen?

• ( ) VPN-Verbindung ist Standard-Gateway für das iOS-Gerät (iPad), dafür gibt es einen Switch beim Einrichten der VPN-Verbindung auf einem iOS-Gerät
• ( ) IIS liefert nur eine Seite aus und (vermutlich) keine JS-Files, die in irgendeiner "responsive"-Seite (welche das ist, steht allerdings wirklich nicht da) erst die Funktionalität sicherstellen

Wenn das ein Problem der Namensauflösung wäre, dann sollte ja schon das "Login-Fenster" (wie der TE es beschreibt) nicht geladen werden können ... ich habe dort nichts davon gelesen, daß er diese Seite nur über eine direkte Eingabe der IP-Adresse (im LAN) des IIS aufrufen kann.

Wo ist da also der Zusammenhang? Wo liest Du da (oder durch welche Überlegung bei dem beschriebenen Fehler gelangst Du zu dieser Vermutung), daß

Problem ist nicht Internet oder Routing sondern DNS.

Daher klappt Zugriff per IP.

sein könnte? Vielleicht bist Du nur im Thread verrutscht?

EDIT: Ich habe in diesem Thread die - für mich neue und überraschende - Erkenntnis gewonnen, daß der IPSec-Client des iOS kein Split-Routing bei aktivierter VPN-Verbindung unterstützt. Man lernt eben nie aus ...

 

[sidney2008]

Nein, HabNeFritzbox ist keineswegs im Thread verrutscht!

Ich habe genau das getan, was er geschrieben hat und nun funktioniert es! Auch das Öffnen anderer "normaler" Webseites über den VPN-Tunnel. Sagenhaft!
Euch beiden nochmals herzlichen Dank, dass Ihr Euch die Zeit genommen habt, Euch mit meinem Problem auseinanderzusetzen.

@HabNeFritzbox:

Könntes Du vielleicht kurz schildern, was da genau abläuft, wenn man nach Deiner Anleitung vorgeht?
Wieso muss man den Haken erst entfernen und anschließend wieder setzen? Und wieso wirkt sich das auf JS aus?

Viele Grüße
testit

 

[PeterPawn]

und nun funktioniert es! Sagenhaft!

Ok, nur damit ich das jetzt noch mal richtig verstehe/zusammenfasse und es später nicht falsch wiedergebe:

Nachdem Du den Haken bei der NetBIOS-Filterung entfernt und neu gesetzt hattest (das bewirkt eine Neueinrichtung der Filter generell und als Nebeneffekt dann das richtige Setzen von Einstellungen), routet jetzt Dein iPad nicht mehr seinen gesamten Internet-Verkehr über die aufgebaute VPN-Verbindung, sondern nutzt den direkten Weg für Internet-Verbindungen, solange die Daten nicht aus dem per VPN angebundenen Netz kommen sollen? Und das auch, ohne daß Du Änderungen auf dem iPad vorgenommen hast ...

Das würde ich tatsächlich so bemerkenswert finden, daß ich trotzdem noch einmal nachfrage, wie denn bei der VPN-Verbindung der Schalter "Für alle Daten" nun eingestellt ist.

Und die (unbekannte) Login-Seite des IIS funktioniert jetzt ebenfalls reibungslos?

Dann ziehe ich die Frage aus der vorherigen Antwort zurück (die nach dem "Verrutschen") und schließe mich Deiner Frage nach der Erklärung an. Dann wäre es nett, wenn Du mal die Bestandteile der vorher nicht funktionierenden Anmeldeseite zusammenstellen würdest (z.B. mit einem Firefox auf einem PC, damit man die verschiedenen Requests mal sieht) ... denn wie dadurch das "JavaScript"-Problem gelöst wurde (solange das nicht ein Nachladen von JS-Files über NetBIOS war, dann hätte aber der direkte Zugriff über die Portfreigabe und den DDNS-Namen auch nicht funktioniert), würde ich zu gerne ergründen, einfach nur um den Mechanismus zu verstehen - da kann ich dann einfach nicht anders.

Wenn jetzt das Routen des kompletten Internetverkehrs über die VPN-Verbindung funktioniert, ist das etwas anderes (wenn Du das als alternative Lösung akzeptierst) ... dann hatte ich Dein Anliegen aus #1 falsch interpretiert, wenn Du dort schreibst:

Was aber nicht geht: Wenn ich dann SAFARI starte und eine Webseite auf dem IPad bei aktivierter VPN aufrufen will, kommt keine Verbindung zustande.

Wie soll(te) das denn nun nach Deinem Wunsch am ehesten laufen bzw. wie läuft es jetzt? Mit einem simplem Paketmitschnitt kann man das ja problemlos klären.

Am Ende habe ich Dich in #1 so verstanden, daß Du dem AVM-Support die Aussage: "Bei aktivierter VPN-Verbindung geht immer alles über die FRITZ!Box." bedingungslos 1:1 geglaubt hast - hast Du denn den Button inzwischen gefunden (bzw. hast Du ihn überhaupt gesucht) und mal mit und mal ohne diese aktivierte Einstellung probiert? Auch beim Aufruf einer "Wie ist meine IP-Adresse?"-Seite solltest Du je nach Schalterstellung (zwischendrin die Verbindung neu zu starten nicht vergessen, keine Ahnung, ob 8.4 das automatisch hinbekommt) entweder Deine iPad-Adresse (bzw. die vom Mobilfunk-Provider) oder die der heimischen FRITZ!Box sehen, je nachdem, ob der Request über die VPN-Verbindung erfolgte oder nicht.

Wäre nett, wenn Du beim Ergründen des Phänomens noch helfen könntest ... danke vorab.

 

[HabNeFritzbox]

Ist ein hier bekannter Bug mit dem DNS. Durch den Trick ist das DNS Problem weg.

Früher gab es Problem auch, brauchte anderen Trick, und würde irgendwann nach was nerven per Ticket auch gefixt.

 

[sidney2008]

Ist ein hier bekannter Bug mit dem DNS. Durch den Trick ist das DNS Problem weg.

Früher gab es Problem auch, brauchte anderen Trick, und würde irgendwann nach was nerven per Ticket auch gefixt.

Vorab: Natürlich ist für mich am wichtigsten, DASS es nun geht!
Aber es wäre natürlich schon interessant zu wissen, WARUM es nun geht. Vor allem ist mir nicht klar, dass nun die JavaScript-Problematik ebenfalls gelöst ist.

@PeterPawn:
Es scheint schon SO zu sein, wie der AVM-Mitarbeiter es mir dargelegt hat. Defaultmäßig wird nun der Internetzugang über die FB7490 gemanaged. Ich habe einfach eben mal mit aktiviertem VPN eine Webseite von mir aufgerufen und dabei das Log-File des Apache Webservers mittels "tail -f access.log" mitverfolgt. Der Zugriff vom IPad wird ausgewiesen mit der in der Übersicht der FB7490 ausgewiesenen IP, die dynamisch zugewiesen wurde. Die IP des Mobilfunkanbieters, dessen SIM-Card im IPad steckt, tritt nicht in Erscheinung. Ich habe auch tatsächlich am IPad selbst nichts geändet, sonder nur genau DAS gemacht, was HabNeFritzbox geschrieben hat.

Diesen Schalter für alle Daten kann ich bei mir auf dem IPad mit iOS 8.4 leider nicht finden.


Viele Grüße
sidney2008

 

[HabNeFritzbox]

Bei IPsec ist im iOS kein Schalter für alle Daten, nur bei anderen beiden VPN Typen.

Es liegt nicht am Endgerät.

Wieso die FB die DNS verschlingt kann ich nicht sagen. Ich weiß dass Internet trotzdem geht per IP.

Nur wenn DNS die Hostnamen nicht auflöst heißt es immer gleich Internet nicht geht, was nicht so ganz stimmt.

Früher war der Trick, VPN Verbindungen deaktivieren und dann wieder aktivieren.

Denke da ist bei Einrichtung in Konfig nen Fehler welcher durch die Tricks neu und korrekt geschrieben wird in Konfig.

Also liegt Fehler auch nicht in VPN Konfig für das Endgerät.

Mit Webserver oder JavaScript hat ganze nix zutun, da gab es wohl bloß auch Teilproblem mit DNS.

 

[PeterPawn]

Ich würde gerne verstehen, warum ein Aufruf der "Login-Seite" des IIS per Servername, also mit DNS-Auflösung, wie ich mal unterstelle (ansonsten verstehe ich nicht, wie man das erraten konnte, daß die (noch richtig geladene) IIS-Seite per IP-Adresse aufgerufen wurde, das steht dort nirgendwo), funktioniert hat und dann - vermutlich, daher ja die Bitte um die verschiedenen Requests beim Laden der kompletten Seite - das Nachladen von Komponenten (hier wahrscheinlich JS-Dateien für die Aktivierung des Submit-Buttons) nicht mehr funktioniert.

Wenn das allerdings von einer externen Quelle nachzuladende Dateien waren (z.B. von Google oder irgendwo anders eine "jquery.js" oder auch irgendwelche Dateien von Node.js), dann ist das auch wieder erklärlich ... aber auch hier sehe ich nicht, wie man das wissen/schlußfolgern/ahnen konnte, daß damit dann das DNS-Problem das Nachladen von externen Skript-Ressourcen verhindert hat, wenn die andere Seite von einem IIS im LAN kam (und das steht nun wirklich in #1, daß es einen solchen IIS gibt und der über DDNS und Portfreigabe einwandfrei arbeitet).

So verstehe ich auch Frage in #7 "Und wieso wirkt sich das auf JS aus?" von sidney2008 ... die einzige plausible Erklärung wäre das o.a. Nachladen von extern. Wenn das so ist, wäre eine Bestätigung nett ... einfach um mein Weltbild wieder geradezurücken. In meiner Welt macht ein Computer das (und nur das, ggf. eben auch das Falsche), was man ihm aufträgt.

Ich habe die Lösung von HabNeFritzbox verstanden. Auch das Problem der falschen Forwarding-Einstellungen, das durch die Deaktivierung des NetBIOS-Filters und das damit verbundene Neuschreiben der Einstellungen zu beheben ist, ist schon klar und bekannt, das ist nicht der Punkt (eigentlich müßte sogar schon das Deaktivieren des Filters ausreichen, das anschließende Aktivieren dient eigentlich nur noch dem Wiederherstellen des vorherigen (sicheren) Standes).

Ich habe auch akzeptiert, daß das am Ende geholfen hat. Punkt. Also nicht falsch verstehen, wenn ich der Sache jetzt zu gerne auf den Grund gehen würde ... ich kann einfach nicht anders und an den "deus ex machina", der solche Abläufe nach Belieben gelingen oder fehlschlagen läßt, will ich nicht glauben. Also möchte ich die Ursache dahinter einfach nur verstehen ...

Ich sehe eben nicht, wie diese Änderung sich auch das Laden der Login-Seite des IIS auswirken kann und schon gar nicht, warum das die Einstellung des iOS, wohin der "Internetverkehr" zu routen ist, ändern sollte. Wenn es diese gar nicht geändert hat und mit der aktuellen Einstellung aller Verkehr über die FRITZ!Box geht, ist dieser Teil ebenfalls schon für mich gegessen ... dann bleibt nur noch die JS-Frage von weiter oben.

 

[sidney2008]

Hallo PeterPawn,

ich habe mir nun mal die Sources des Login-Scriptes angeschaut und Du liegst völlig richtig:
code.jquery.com/jquery-1.8.3.min.js wird u.a. eingebunden.
Das erklärt schon mal, warum dann der Login-Button nicht kam!

Viele Grüße
sidney2008

 

[PeterPawn]

Diesen Schalter für alle Daten kann ich bei mir auf dem IPad mit iOS 8.4 leider nicht finden.

Verstanden ... ich habe gerade mal selbst jemanden auf einem iPad mit neuerer Firmware nachsehen lassen, diesen Schalter gibt es tatsächlich nur bei PPTP- und L2TP-Verbindungen. Ob das jetzt heißt, daß ein iPhone grundsätzlich allen Verkehr über eine aktivierte IPSec-Verbindung schickt, war auf die Schnelle nicht zu ermitteln.

Die Aussage des Supports kann trotzdem nur die halbe Wahrheit sein (jedenfalls wenn sie tatsächlich lautete, daß dann immer aller Traffic über die Box geht und nicht nur in direkter Verbindung mit dem IPSec-Client des iOS von Apple) ... das kann jeder mit einem Shrewsoft-Client auf seinem Windows-PC sofort ausprobieren. Auch AVM zeigt das in der eigenen Anleitung im letzten Punkt der VPN-Konfiguration, daß man entweder selektiv entsprechende Policies einstellen kann oder global alles über den Tunnel schicken kann (wie es das iOS dann wahrscheinlich macht - das weiß ich ja eben nicht).

Dort kann ja genau derselbe Account in der FRITZ!Box verwendet werden wie für die Verbindung des iPad/iPhone und dort kann man definitiv am Client einstellen, ob der Traffic in den Tunnel geht oder nicht. Da hat also die FRITZ!Box definitiv nicht alleine "das Sagen". Ich habe mich (meine iOS-Zeiten, auch die der Konfiguration für andere mit dem IPCU, liegen schon etwas zurück) von diversen Abbildungen im Internet irritieren lassen, diese zeigen aber tatsächlich auch immer nur L2TP-basierende Verbindungen und da gibt es den Schalter "Send all traffic" / "Für alle Daten" ... das hat mich zu der falschen Annahme verleitet, der existiert auch für den IPSec-Client.

Warum es den dort nicht gibt, verstehe ich nicht, aber das hat bestimmt seine Gründe. Daß es nicht anders geht wegen des IPSec-Protokolls, kann man (auch wg. des funktionierenden Shrewsoft-Clients) ausschließen ... also könnte es noch an der Architektur des IPSec-Stacks im iOS liegen, denn auch bei anderen IPSec-basierten Verbindungen (mit dem IPCU kann man da noch weitere Typen konfigurieren, ggf. auch eine "Custom SSL"-Verbindung) wird keine Option zum Routing des sonstigen Verkehrs angeboten (gerade nachgesehen, auch bei einer älteren Version des IPCU, die ich noch installiert hatte, eine solche Option ist also auch nicht bei irgendeinem Update verschwunden).

Wenn Du jetzt noch klarstellst, daß die fehlenden JS-Dateien tatsächlich von extern nachgeladen werden müssen, ziehe ich nur noch den Hut vor den kombinatorischen Fähigkeiten von HabNeFritzbox (und merke mir, daß das iOS gar kein Split-Routing bei IPSec beherrscht) und das Thema ist für mich auch hinsichtlich des JS-Phänomens erklärt.
Ok, das ist inzwischen auch geklärt ... danke.

 

[HabNeFritzbox]

Bei dem IPsec wird es ja in der Accesslist in VPN Konfig geregelt ob nur bestimmte IPs aus dem LAN oder alles.

Bei den beiden anderen VPN Typen, was die FB nicht frisst, kann man es am Gerät beeinflussen.

 

[PeterPawn]

Bei dem IPsec wird es ja in der Accesslist in VPn Konfig geregelt ob nur LAN bestimmte IPs oder alles.

Schon, aber eben nur für die FRITZ!Box selbst. Wenn der Client auf der anderen Seite der VPN-Verbindung seinen "normalen Internet-Verkehr" (also das, was nicht für eine Adresse im VPN-LAN bestimmt ist) gar nicht in den Tunnel steckt, kann die FRITZ!Box sich Kopf stellen ... das entscheidet tatsächlich er selbst. Die Box kann ihm nur die Antwort auf Pakete verweigern, die er an sie über den Tunnel geschickt hat.

Bei den beiden anderen VPN Typen, was die FB nicht frisst, kann man es am Gerät beeinflussen.

Ja, das habe ich dank Deines früheren Hinweises jetzt auch richtig gelesen (und begriffen). Da die beiden anderen Protokolle an anderen Stellen im IP-Stack angreifen, ist dort offenbar noch eine "routing decision" für den Traffic machbar. Das muß eine Besonderheit der IPSec-Implementierung des iOS sein ... es gibt - wie oben geschrieben - im IPCU bei gar keiner IPSec-basierten Verbindung eine Routing-Einstellung.

Bei jedem "normalen Linux" (vermutlich auch bei AVM, dort aber als CS und auch nicht in den OSS-Teilen so richtig zu finden, das muß irgendwo im dsld/kdsld sein) wird eben der Traffic für die IPSec-Encapsulation entsprechend selektiert ... wenn diese Selektoren (normalerweise mit "ip xfrm" anzuzeigen) dann auf "allen Verkehr" passen, geht alles in den Tunnel (was nicht durch speziellere Entscheidungen einen anderen Weg nimmt). Ist das nicht der Fall, geht nur genau der "selektierte Traffic" (auch hier durch Quell- und Zieladressen/-ports spezifiziert) durch die IPSec-Transformationen. Unter diesen Systemen ist also auch ein Split-Routing beim IPSec möglich.

 

[sidney2008]

Wenn man die VPN-Konfigs für die FB mit der Software von AVM "Fritz-Fernzugang einrichten" erzeugt, kann man die Checkbox "ALLE DATEN ÜBER VPN-TUNNEL SENDEN" aktivieren. Defaultmäßig ist dieser Punkt in der o.a. Einrichtungssoftware DEaktiviert.

Lt. AVM-Support ist das beim Einrichten eines VPN-Users über die relativ neue WebIF-Funktion genau umgekehrt.

Viele Grüße
sidney2008

 

[PeterPawn]

Lt. AVM-Support ist das beim Einrichten eines VPN-Users über die relativ neue WebIF-Funktion genau umgekehrt.

Das ist dann beim Einrichten mit "FRITZ!Fernzugang konfigurieren" aber auch die Konfiguration für den Client (i.d.R. das AVM-Programm "FRITZ!Fernzugang"), auf die sich diese Option auswirkt.

Dort werden ja zwei Konfigurationsdateien erzeugt, eine für die FRITZ!Box und eine weitere ... wahlweise für das Programm (Client2LAN) oder eine andere FRITZ!Box (LAN2LAN).

Hast Du mal probiert, wie sich diese Einstellung bei einer LAN2LAN-Verbindung auswirkt (d.h. welche Einstellung davon betroffen ist, kann eigentlich nur "accesslist" sein) bzw. ob die bei LAN2LAN überhaupt auftaucht und vorhanden ist (ist halt etwas komplizierter zu konfigurieren und das war bisher eigentlich immer Handarbeit)?

Die dritte Möglichkeit wäre die Konfiguration der FRITZ!Box als Client für einen anderen Access-Server, da macht so eine Einstellung dann auch noch Sinn ... einfach weil sie der FRITZ!Box sagen könnte, ob sie als Client allen Verkehr über den Access-Server schicken soll oder nur den für das dort befindliche IP-Netz (was in der Konfiguration ja auch festgelegt wird, wenn die Box "Client" ist).