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

sidney2008 schrieb:

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

Zum Vergrößern anklicken....

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).

Zum Vergrößern anklicken....

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).

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.

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...

@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ß

HabNeFritzbox schrieb:

Problem ist nicht Internet oder Routing sondern DNS.

Daher klappt Zugriff per IP.

Zum Vergrößern anklicken....

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 schrieb:

und nun funktioniert es! Sagenhaft!

Zum Vergrößern anklicken....

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:

sidney2008 schrieb:

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

Zum Vergrößern anklicken....

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.

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.

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.

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 schrieb:

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

Zum Vergrößern anklicken....

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.

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.

HabNeFritzbox schrieb:

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

Zum Vergrößern anklicken....

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.

Zum Vergrößern anklicken....

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 schrieb:

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

Zum Vergrößern anklicken....

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).