Mini-Howto: Kompletten Internetverkehr über AVM VPN routen

Darüber habe ich mich auch schon gewundert, aber das ganz normale Fernzugang-Einrichtungs-Tool macht das nun mal so.
Wenn du da den Haken für "Alles über VPN" setzt, wird genau diese 2. Regel dazugeschrieben.

Frag lieber, was sich der Programmierer dabei gedacht hat. ;)
 
Es scheint noch etwas anderes nicht zu funktionieren:

Der Webserver zuhause ist über seinen dyndns-Namen (DDNS-HOSTNAME) aus dem Internet erreichbar. Im LAN ist dieser unter a.b.c.200 erreichbar (aber auch natürlich mit dem DDNS-Hostname). Die VPN-Client-IP lautet: a.b.c.191

* Greife ich nackig über den Hotspot mit diesem Hostname drauf zu, sagt mir mein Webserver das ich mit der IP "hot.spo.t.telekom" (nur um nicht mit zahlen zu verwirren! ist natürlich keine IP ;) ) zugreife. Das stimmt natürlich.

* Wenn ich jetzt das VPN aktiviere und auf den Webserver zugreife (wieder mit besagten Hostname), steht da weiterhin "hot.spo.t.telekom" ... das darf ja nicht. Wenn ich via VPN auf wieistmeineip-Dienste zugreife, wird mir hingegen "meine.aktuelle-ip.von.zuhause" angezeigt - was ja richtig ist.

* Wenn ich via VPN auf die LAN-IP des webserver zugreife, bekomme ich die VPN-IP (a.b.c.191) angezeigt. Richtig.

* Wenn ich mit "meine.aktuelle-ip.von.zuhause" via VPN zugreife, bekomme ich als zugreifenden Host wieder "hot.spo.t.telekom".

Meine Erwartungshaltung wäre doch:

* Nackig via Internet: "hot.spo.t.telekom" als Host-IP die zugreift - klappt
* Via VPN und DDNS-HOSTNAME: a.b.c.191 die zugreift ... ich bin doch via VPN ein Teil des LANs und habe ja auch eine LAN-IP
* Via VPN und der IP: a.b.c.191
* Via VPN und "meine.aktuelle-ip.von.zuhause": a.b.c.191

Hab ich hier ein verständnisproblem?

Was läuft hier also schief?
 
Wenn der Zugriff auf den Anschluß mit der FRITZ!Box bereits über VPN erfolgen würde ... auf welchem Weg sollten denn dann die Pakete, die den VPN-Inhalt transportieren, an ihr Ziel gelangen?

Es ist nun mal die Entscheidung des VPN-Clients, auf welchem Weg er welche Pakete versendet - wie sollte die FRITZ!Box das iPhone jetzt "dazu zwingen", bestimmten Verkehr über das VPN zu leiten? Durch Luftanhalten bis das iPhone das macht, was die FRITZ!Box ihm vorschreibt?

Wenn das iPhone entsprechende Regeln für sich aufstellt, daß nicht nur der Verkehr auf den VPN-Ports (UDP/500 + ESP oder UDP/4500) über das "öffentliche Netz" geht, sondern der gesamte Verkehr, der die FRITZ!Box am anderen Ende als Ziel hat (das ist logischerweise auch jeder Zugriff über die DynDNS-Adresse auf irgendeinen Dienst dort), dann kann die FRITZ!Box da so gar nichts gegen machen ... höchstens den Kontakt verweigern (vielleicht wegen "Migräne"?) und dazu müßte sie auch erst einmal abgleichen, daß es sich tatsächlich um den VPN-Client handelt und sich hinter derselben Remote-IP-Adresse nicht doch mehrere Clients versammelt haben.
 
Wenn der Zugriff auf den Anschluß mit der FRITZ!Box bereits über VPN erfolgen würde ... auf welchem Weg sollten denn dann die Pakete, die den VPN-Inhalt transportieren, an ihr Ziel gelangen?

Es ist nun mal die Entscheidung des VPN-Clients, auf welchem Weg er welche Pakete versendet - wie sollte die FRITZ!Box das iPhone jetzt "dazu zwingen", bestimmten Verkehr über das VPN zu leiten? Durch Luftanhalten bis das iPhone das macht, was die FRITZ!Box ihm vorschreibt?

versteh nicht so ganz was du mir damit sagen willst ... über eine mobileconfig gebe ich dem iPhone die Anweisung bei aktiven VPN den DNS-Server meiner Wahl zu nutzen. Und hier scheint irgendwo was nicht zu stimmen - diese Konfigzeile klappt bei manchen (wie in dem Nachbar-Thread zu sehen), bei manchen wiederum nicht (bei mir). Sinn macht das nicht ... ausser das iPhone würfelt was wo her geht. Parallel klappen bestimmte Kombis über das VPN nicht. Warum ....

Ich kann mit der mobileconfig, soweit ich das verstanden habe, auch Apps dazu bringen NICHT über das VPN zu laufen ... per se sollte aber mit dem Standardbrowser und mit Standardfunktionen, wenn Adresse a über das VPN geht, doch auch Adresse b über das VPN gehen. Da frag ich mich ob die Konfig der Box das irgendwo ausklammert das bestimmter Traffic (also der Lokale Webserver, der DNS-Server) nicht übers VPN geht. Ansonsten wäre die Frage: was muß ich an der mobileconfig ändern - vermutlich ist hier eher der Fall - nur hab ich die mittlerweile so angepasst, das sie aussieht sie bei Leuten wo DNS klappt. Daher hab ich im Nachbar-Thread mal nach der Box-Konfig gefragt vielleicht ist da ein Unterschied? Accesslist?

Was für ein Datenaustausch findet überhaupt im VPN statt - also "verwaltungstechnisch"? Hab ich keine Ahnung ... eigentlich würde es ja sinn machen wenn der Client von der Gegenstelle erfahren würde (die "vertrauen" sich ja gegenseitig; also könnte man auch mit einander "reden"): xyz ist nicht erlaubt - brauchst du garnicht erst hin schicken.

Tja und so hänge ich hier nach über 4 Jahre immer noch am DNS-Thema - was bei manchen geht, bei manchen nicht ... und irgendwie glaub ich das wird bei mir nie klappen und warum - weiß auch keiner :( Ein VPN ohne DNS bringt ja nicht wirklich was ... zumindest in bestimmten Ländern ... und auch hier halte ich das für nicht ungefährlich - da will man verhindern das andere "mitlesen" - schickt alles über das VPN, aber bei DNS vertraut man der öffentlichkeit. DNS-Manipulieren, andere IPs liefern und schwupp loggt man nicht mehr bei facebook ein sondern in irgendeinem der Login-Daten abgreifen will. Daher wäre mir DNS halt auch wichtig ...
 
Das war der Versuch einer Erklärung, warum Deine Erwartunghaltung bei Punkt 2 Deiner Liste (Zugriff auf den Host über den DynDNS-Namen bei aktivierter VPN-Verbindung) nicht unbedingt mit der Realität übereinstimmen muß.

Das könnte man sicherlich so konfigurieren, aber das ist eben kein Problem der "AVM-Software" (der dieses Forum "gewidmet" ist), weil der VPN-Client für sich selbst entscheidet, welchen DNS-Server er befragt und ebenso, welchen Traffic er über den Tunnel zum IPSec-Peer sendet und welchen nicht. Wenn dieser Client alles mit der Zieladresse der FRITZ!Box eben nicht durch den Tunnel schickt (so ein IP-Paket enthält nun einmal die Adresse des finalen Ziels und nicht die des nächsten Hops), dann kommt so eine Verbindung am VPN-Peer eben auch nicht durch den Tunnel an.

Mit der Konfiguration des iOS-IPSec-Clients über das IPCU kenne ich mich nicht gut genug aus, um dazu definitive Erklärungen abgeben zu können, was da wie eingestellt werden kann und muß. Lediglich die Feststellung, daß es eben die Entscheidung des Clients ist (und die FRITZ!Box - mithin auch die AVM-Software - darauf keinen wirklichen Einfluß hat), wollte ich Dir nahebringen ... vielleicht führt das ja auch zu der Erkenntnis, daß es in gewisser Hinsicht das falsche Forum für diese Fragestellung ist.

Selbst wenn man den Ehrgeiz entwickeln wollte, Dir bei diesem Problem zu helfen ... es fehlen viele wichtige Informationen (angefangen bei der iOS-Version des iPhones bis zur Information, ob und wenn ja wie die "mobileconfig" signiert ist u.v.m.), die den entscheidenden Unterschied zwischen Deiner Konfiguration und der (funktionierenden) aus irgendwelchen anderen Threads ausmachen können. Aber diesen Ehrgeiz habe ich in diesem Falle ohnehin nicht ... ich wollte Dir nur den Hinweis geben, daß Du vermutlich (jedenfalls nach meiner Meinung) am falschen Ende der VPN-Verbindung suchst.

Aber das ist ja auch ganz einfach zu ermitteln ... wenn Du mit einem anderen Client/einem anderen Gerät und genau dieser VPN-Verbindung eine erfolgreiche DNS-Abfrage durh den Tunnel starten kannst, dann funktioniert diese VPN-Verbindung einwandfrei und es liegt am Peer. Ist das nicht der Fall (schon die "Basisfragen" zum DHCP-Server und den Gründen Deiner Verwendung der .200 als DNS-Server sind vollkommen unbeantwortet), ist es wohl doch die FRITZ!Box - aber die gesamte hinter dem Problem liegende Topologie des LAN an der FRITZ!Box muß man sich hier ja auch "denken" ... da habe ich schon Zweifel, ob am Ende nicht nur Deine Überlegungen zu den verwendeten IP-Adressen an der Realität vorbeigehen.

Diese Unklarheiten haben mich jedenfalls davon abgehalten, mich hier überhaupt "einzumischen" in die Problemlösung und ich wollte Dir nur den Umstand näherbringen, daß eben ein VPN-Peer dem anderen nicht "vorschreiben" kann, wie der seinen eigenen Traffic routet - auch das nur deshalb, weil Du wissen wolltest, wo Dein Denkfehler liegen könnte.
 
Du meinst wohl wenn Unterforum oder Themenbereich? Oder möchtest ihm wirklich ein externes ganz anderes Forum nahelegen?

Mit der Konfiggeschichte habe ich mich auch nicht wirklich beschäftigt, ich kenne und nutze nur die Funktion in iOS entweder alles oder nur Heimnetz über Tunnel routen zulassen, was man mit einem Schalter festlegen kann.
 
Du meinst wohl wenn Unterforum oder Themenbereich? Oder möchtest ihm wirklich ein externes ganz anderes Forum nahelegen?
Wenn es tatsächlich ein Problem mit der "mobileconfig" ist, würde ich das sogar für besser halten ... es gibt definitiv Foren, die sich mit dieser Einbindung von iOS-Devices in BYOD-Umgebungen (darauf basiert das ja letzten Endes) besser auskennen (notfalls sogar die Apple-Supportforen, meinetwegen auch noch die "Genius Bar").

Aber das klärt ein "Kreuztest" ja ziemlich schnell ... wie so etwas funktionieren kann (also so ein Test), habe ich versucht zu beschreiben.
 
Das könnte man sicherlich so konfigurieren, aber das ist eben kein Problem der "AVM-Software" (der dieses Forum "gewidmet" ist), weil der VPN-Client für sich selbst entscheidet, welchen DNS-Server er befragt und ebenso, welchen Traffic er über den Tunnel zum IPSec-Peer sendet und welchen nicht.
da fritz!box und die ganzen auf der fritz!box gespeicherten hosts über den VPN-Tunnel aufgelöst werden, geht zumindest ein Teil der DNS-Abfragen durch den Tunnel. Ich hab schon versucht auf der Fritz!Box in den Internet-Einstellungen den DNS-Server auf a.b.c.200 zu setzen - aber das wird ignoriert. Leider fehlt mir die möglichkeit genau zu prüfen was alles durch den Tunnel durch geht ... schickt der client nur Abfragen mit fritz.box und ohne TLD durch den Tunnel? Aber warum schickt er fritz.box durch den Tunnel - das iPhone kennt ja erstmal keine fritz.box ... also gehe ich davon aus das ALLES durch den Tunnel gejagt wird - die Fritz!Box aber den DNS-Server der eingetragen ignoriert und nur ein lokales "DNS" funktioniert - wo nur das aufgelöst wird, was der box bekannt ist (sich selbst und die paar hosts dich ich zur Übersicht eingetragen habe). Somit sehe ich das Problem doch bei der Fritz!Box ... warum ignoriert diese auf der Box eingetragene DNS-Server?


es fehlen viele wichtige Informationen (angefangen bei der iOS-Version des iPhones bis zur Information, ob und wenn ja wie die "mobileconfig" signiert ist u.v.m.), die den entscheidenden Unterschied zwischen Deiner Konfiguration und der (funktionierenden) aus irgendwelchen anderen Threads ausmachen können. Aber diesen Ehrgeiz habe ich in diesem Falle ohnehin nicht ... ich wollte Dir nur den Hinweis geben, daß Du vermutlich (jedenfalls nach meiner Meinung) am falschen Ende der VPN-Verbindung suchst.
ich sagte das ich das bereits seit Jahren versuchen ... seit dem iPhone4 bis zum iPhone6 - mit sämtlichen iOS-Versionen (aktuell 9.3; bis gestern 9.2.1), mit vielen Versionen der Fritz!Box 7390 (aktuelle Beta drauf)

Die mobileconfig ist nicht signiert - wie in dem anderen Thread auch nicht. Da ist auch die Mobileconfig zu sehen - da unterscheidet sich nichts wesentliches.

Aber das ist ja auch ganz einfach zu ermitteln ... wenn Du mit einem anderen Client/einem anderen Gerät und genau dieser VPN-Verbindung eine erfolgreiche DNS-Abfrage durh den Tunnel starten kannst,
kann ich das? hab kein anderes Gerät zum testen ...

Ist das nicht der Fall (schon die "Basisfragen" zum DHCP-Server und den Gründen Deiner Verwendung der .200 als DNS-Server sind vollkommen unbeantwortet),
du hast was zum DHCP-Server gefragt oder warum der DNS-Server auf der .200 liegt? Sehe ich nicht. Tut das was zur sache? DHCP und DNS laufen auf einem Windows Homeserver 2011.

ist es wohl doch die FRITZ!Box - aber die gesamte hinter dem Problem liegende Topologie des LAN an der FRITZ!Box muß man sich hier ja auch "denken" ... da habe ich schon Zweifel, ob am Ende nicht nur Deine Überlegungen zu den verwendeten IP-Adressen an der Realität vorbeigehen.
warum soll ich nicht IP-Adressen nutzen die ich gerne möchte? Ich hab mir schon was bei der IP-Planung zu hause gedacht. Sie liegen alle natürlich im Privaten bereich. 1- LAN-Clients [noch mal unterteilt nach Art], 51- WLAN-Clients, 200-Server, 220-aktive Netzkomponenten, 250 Router usw. So weiß ich beim "rumspielen" wenn mir eine IP unterkommt, direkt wo die hingehört ... ich hab über 20 IP-Devices zu hause. 1,2,3,4,5,6,7 ist nicht gerade übersichtlich ;)

Diese Unklarheiten haben mich jedenfalls davon abgehalten, mich hier überhaupt "einzumischen" in die Problemlösung und ich wollte Dir nur den Umstand näherbringen, daß eben ein VPN-Peer dem anderen nicht "vorschreiben" kann, wie der seinen eigenen Traffic routet - auch das nur deshalb, weil Du wissen wolltest, wo Dein Denkfehler liegen könnte.

nach der DNS-Analyse von oben scheint er aber sehr wohl alles durch zu jagen - wieso sonst wird fritz.box, fritz.nas, server, desktop1 aufgelöst - ich habe auf dem Iphone keine "host-datei" wo diese Hosts mit IPs hinterlegt sind - wo kommt die Auflösung also her? Von der Fritz!Box ... aber warum arbeitet die Fritz!Box nicht mit dem DNS-Server der (unter Interneteinstellungen) eingestellt ist? Da muß meiner Meinung nach eine Einstellung in der VPN-Config hin - was soll mit Port 53-Anfragen passieren?
 
kann ich das? hab kein anderes Gerät zum testen ...
Dann wird so ein Kreuztest tatsächlich schwierig ... vielleicht kann ja doch jemand im Familien-/Freundeskreis oder der Nachbarschaft aushelfen? Ich halte die Auswahl an möglichen Clients für das VPN jetzt nicht für soo exklusiv, daß man da mit etwas Anstrengung nicht noch ein passendes Gerät (zumindest für die 2 Minuten, die so ein Test braucht) organisieren kann.

du hast was zum DHCP-Server gefragt oder warum der DNS-Server auf der .200 liegt? Sehe ich nicht. Tut das was zur sache? DHCP und DNS laufen auf einem Windows Homeserver 2011.
1. Das schreibe ich auch nicht, da steht "Basisfragen" und das ist vielleicht eine etwas unglückliche Übersetzung für "basic questions" (Grundsatzfragen), aber wenn ich das tatsächlich als Frage stellen und nicht nur den Hinweis auf eine unvollständige Problembeschreibung damit quasi "durch die Blume" hätte geben wollen, wäre mir dafür vermutlich auch eine eindeutigere Formulierung eingefallen - ich bin da jedenfalls recht optimistisch.

2. Nein, das tut beim AVM-VPN nichts zur Sache, ich frage halt immer nur aus Neugierde und Langeweile - selbst wenn ich hier gar nicht gefragt habe.

3. Deine Überlegungen zur Organisation der Adressierung in Deinen LAN mögen ja beeindruckend sein (wenn auch - diese "Spitze" kann ich mir dann doch nicht verkneifen - aus Sicht eines Netzwerk-Admins grausig, zumindest unter dem Stichwort "Segmentierung" eines LAN), aber die kann hier niemand kennen.

4. Ja, selbst wenn Du es nicht glauben willst und den DHCP-Server in der FRITZ!Box abgeschaltet haben solltest, könnte (Konjunktiv, den könnte (schon wieder Konjunktiv) man bei Kenntnis der Topologie und der verwendeten Einstellungen vermeiden) es genau an dieser IP-Adresse liegen, die auf 200 endet. Je nach den Einstellungen für die DHCP-Range in der FRITZ!Box (selbst wenn deren Server gar nicht verwendet wird), würde ein zusätzlicher VPN-Client, der über das GUI konfiguriert wird (da reicht ja schon ein Haken beim Eintrag für den Benutzer), jetzt selbst diese .200 (aus Sicht der FRITZ!Box) erhalten und dann macht so eine Box zu allem Überfluß auch noch Proxy-ARP für so eine IP-Adresse.

Jetzt mag es sein, daß das bei Dir alles nicht der Fall ist (es gibt keine weiteren VPN-Clients in der vpn.cfg oder die Range beim DHCP ist - auch wenn der nicht verwendet wird - anders eingestellt, oder, oder, oder ..) - ich hatte deutlich geschrieben, daß mir der Antrieb fehlt, mich in Dein Problem zu vertiefen. Das zieht sich seit mehr als 14 Tagen hin, sogar die letzte Aktivität hier ist schon fast 2 Wochen her. Die Konfiguration muß man sich aus vier Beiträgen zusammenklauben und dann steht man immer noch vor der Frage, ob es denn aktuell nun immer noch die am 05.03. mal beschriebene sein mag oder ob Du Veränderungen vorgenommen hast und die derzeitige dann doch schon wieder eine andere ist.

Ich habe nur versucht, einen Teilaspekt Deiner Fragen in #422 aufzugreifen (warum beim Zugriff auf den DynDNS-Namen offenbar - so Deine Tests stimmig sind - nicht der VPN-Tunnel genutzt wird) und dafür eine mögliche Erklärung geliefert.

warum soll ich nicht IP-Adressen nutzen die ich gerne möchte? Ich hab mir schon was bei der IP-Planung zu hause gedacht.
Dieses Recht habe ich Dir nie streitig machen wollen, lege mir bitte keine Aussagen in den Mund, die ich nicht gemacht habe.

Es gibt halt bei der Verwaltung der IP-Adressen für VPN-Clients (conntype_user) im FRITZ!OS eine Besonderheit, die auch noch gerade mit der Adresse 200 im verwendeten LAN-Segment zusammenhängt. Weiß man um diese Besonderheit und vermeidet alle Aktionen, die an dieser Zuteilung etwas ändern könnten, kann man das auch passend handhaben. Ob/daß Du um diese Besonderheit weißt und bei jeder Aktion darauf Rücksicht nimmst, kann ich dem bisher von Dir Geschriebenen nicht entnehmen.

Deinen Überlegungen zum DNS kann ich auch nicht so richtig folgen ... insbesondere wird für mich nicht klar, wo Du nun genau andere DNS-Server in der FRITZ!Box konfiguriert hast (die FRITZ!Box arbeitet für Domains jenseits ihrer eigenen (fritz.box, ggf. noch andere, sieht man alles in den Support-Daten) als "DNS forwarder/proxy") und woran Du am Ende festmachst bzw. bemerkst, daß die FRITZ!Box ihrerseits DNS-Abfragen nicht ordentlich an das konfigurierte Ziel für rekursive Abfragen weiterleitet. Das steht aber auch alles wieder in den Support-Daten (sollte es da nicht auftauchen, kann man immer noch selbst mit "showshringbuf dnsd" nachsehen, was die letzten DNS-Abfragen waren) und es sollte ein Leichtes sein, an die Stelle der Deduktion aus der Tatsache, daß "fritz.box" und andere aufgelöst werden können, einfach gesicherte Erkenntnisse auf der Basis von Protokollen (notfalls sogar auf der Basis eines Packet-Dumps) zu setzen.

Aber noch einmal ... ich will hier gar nicht in die Details gehen und ich muß damit auch Deine Konfiguration nicht verstehen.

OT: Warum will ich das eigentlich nicht?

Mich hat zugegebenermaßen der Passus
Wulfman_CGN schrieb:
Ich hab hier aus dem Thread schon folgende änderung übernommen:
, gefolgt von einer "accesslist", die so überhaupt keinen Sinn macht im Kontext der darüber stehenden Angaben, davon abgeschreckt, mich da einzudenken. Ich stehe auf dem Standpunkt, daß man für solche Änderungen (gerade an sicherheitskritischen Einstellungen und VPN gehört dazu) eher auf "Wissen" setzen sollte und nicht auf "Probieren" (das ist auch nicht das erste Mal, daß ich das so explizit zum Ausdruck bringe) und dazu passen dann solche Änderungen "auf Verdacht" schon von der Herangehensweise eben nicht.

Wenn Du eine bestimmte Einstellung nicht verstehen solltest oder das Ergebnis eines systematischen Tests nicht alleine interpretieren kannst, helfe ich (im Rahmen meiner Möglichkeiten) gerne ... für Tipps der Art "stelle das und das da und dort ein", bin ich der falsche Ansprechpartner - daher halte ich mich raus, was konkrete Vorschläge für Einstellungen angeht und in den Testergebnissen, die man bisher hier lesen konnte (in erster Linie ja in #422), sind ja nun auch keine wirklichen Überraschungen enthalten. Daß Deine Erwartungshaltung eine andere ist, mag ja sein ... eine mögliche Erklärung (die man durch passende Tests verifizieren kann) und auch einen Vorschlag für weitere Tests habe ich abgegeben. Was sollte ich sonst noch tun?

Mit bleibt eigentlich nur noch das Werben um Verständnis ... während Dir Dein eigenes Problem ja ständig präsent sein mag und Du damit vielleicht automatisch auch weißt, was da wie konfiguriert ist, laufen hier ständig mehrere Leute durch, die entweder dasselbe oder doch zumindest sehr ähnliche Probleme haben. Da wird schon das "Erinnern" an bereits Gelesenes und das Auseinanderhalten verschiedener Threads zu einem Problem und wenn das sich dann noch über 14 Tage zieht, müßte man erst wieder hingehen und alle bisherigen Beiträge erneut lesen, um wieder auf dem richtigen Stand anzukommen ... das ist es hier (in meinen Augen) einfach nicht wert, diese Zeit (vermutlich ja auch noch mehrfach) erneut zu investieren. Wenn das Problem schon seit Jahren besteht, dann ist der jetzt erneut gestartete Versuch ja wohl auch nicht so wichtig ... und eher unter "nice to have" abzuhaken, wenn es doch noch klappen sollte.

Schon die Tatsache, daß Du seit Jahren probierst (mit iPhone 4 bis iPhone 6), aber keinen weiteren Client für einen Kreuztest auftreiben kannst, hält mich persönlich von jedem intensiveren Engagement bei dieser Frage ab und Du bist ja nicht der Einzige, der ein iPhone in Verbindung mit einer FRITZ!Box benutzt (schon gar nicht in den letzten 4 Jahren, wenn es seit iPhone 4 so ist). Von einem "generellen Problem" hätten wir hier sicherlich schon gelesen, also wird es wohl (Achtung, Deduktion meinerseits) an Deiner Konfiguration liegen und die kann nun mal niemand von uns für Dich systematisch testen.
 
vielleicht kann ja doch jemand im Familien-/Freundeskreis oder der Nachbarschaft aushelfen? Ich halte die Auswahl an möglichen Clients für das VPN jetzt nicht für soo exklusiv, daß man da mit etwas Anstrengung nicht noch ein passendes Gerät (zumindest für die 2 Minuten, die so ein Test braucht) organisieren kann.
selber hab ich als mobile geräte nur iphones/ipads - überall das gleiche Problem.
Freundeskreis: da sieht es eher mager aus ...
Familie ... ja 500km entfernt :( 1-2x im Jahr da und da denk ich nicht an sowas. Mir ist das Problem erst wieder wirklich bewusst geworden als ich in Indien probleme mit DNS-Auflösungen hatte und dann über mein VPN gehen wollte - ging nicht. Anderes iPhone aus der Gruppe mit Pay-VPN -> ging.



4. Ja, selbst wenn Du es nicht glauben willst und den DHCP-Server in der FRITZ!Box abgeschaltet haben solltest, könnte (Konjunktiv, den könnte (schon wieder Konjunktiv) man bei Kenntnis der Topologie und der verwendeten Einstellungen vermeiden) es genau an dieser IP-Adresse liegen, die auf 200 endet. Je nach den Einstellungen für die DHCP-Range in der FRITZ!Box (selbst wenn deren Server gar nicht verwendet wird), würde ein zusätzlicher VPN-Client, der über das GUI konfiguriert wird (da reicht ja schon ein Haken beim Eintrag für den Benutzer), jetzt selbst diese .200 (aus Sicht der FRITZ!Box) erhalten und dann macht so eine Box zu allem Überfluß auch noch Proxy-ARP für so eine IP-Adresse.

DHCP ist deaktiviert
DNS zeigt auf die .200 (172.20.5.200 um genau zu sein)
Hatte die 200 schon vor meiner ersten Fritzbox
Weitere VPN-Clients sind sind laut übersicht nicht konfiguriert. Bei dem Benutzer ist kein VPN-Kreuz gesetzt.

Jetzt mag es sein, daß das bei Dir alles nicht der Fall ist (es gibt keine weiteren VPN-Clients in der vpn.cfg oder die Range beim DHCP ist - auch wenn der nicht verwendet wird - anders eingestellt, oder, oder, oder ..)
.251-.254 ist eingestellt und deaktiviert.


Es gibt halt bei der Verwaltung der IP-Adressen für VPN-Clients (conntype_user) im FRITZ!OS eine Besonderheit, die auch noch gerade mit der Adresse 200 im verwendeten LAN-Segment zusammenhängt. Weiß man um diese Besonderheit und vermeidet alle Aktionen, die an dieser Zuteilung etwas ändern könnten, kann man das auch passend handhaben. Ob/daß Du um diese Besonderheit weißt und bei jeder Aktion darauf Rücksicht nimmst, kann ich dem bisher von Dir Geschriebenen nicht entnehmen.

Oh? Das 200 für die Fritz!Box was besonderes ist, wusste ich nicht.


Deinen Überlegungen zum DNS kann ich auch nicht so richtig folgen ... insbesondere wird für mich nicht klar, wo Du nun genau andere DNS-Server in der FRITZ!Box konfiguriert hast (die FRITZ!Box arbeitet für Domains jenseits ihrer eigenen (fritz.box, ggf. noch andere, sieht man alles in den Support-Daten) als "DNS forwarder/proxy")
Bei den Interneteinstellungen ... Internet -> Zugangsdaten -> DNS-Server
Da du den deaktivierten DHCP-Server erwähnt hast: da steht, deaktiviert, die .250 (also die FritzBox drin)


und woran Du am Ende festmachst bzw. bemerkst, daß die FRITZ!Box ihrerseits DNS-Abfragen nicht ordentlich an das konfigurierte Ziel für rekursive Abfragen weiterleitet.
es war die vermutung ...
fritz.box, fritz.nas
desktop
xbox
usw. werden über das VPN aufgelöst. Nur sind das nicht die Namen die nicht nutze ... die stehen in der Netzwerkumgebung der fritz!box.

, gefolgt von einer "accesslist", die so überhaupt keinen Sinn macht im Kontext der darüber stehenden Angaben, davon abgeschreckt, mich da einzudenken. Ich stehe auf dem Standpunkt, daß man für solche Änderungen (gerade an sicherheitskritischen Einstellungen und VPN gehört dazu) eher auf "Wissen" setzen sollte und nicht auf "Probieren" (das ist auch nicht das erste Mal, daß ich das so explizit zum Ausdruck bringe) und dazu passen dann solche Änderungen "auf Verdacht" schon von der Herangehensweise eben nicht.
Die Accesslist
accesslist = "permit ip a.b.c.0 255.255.255.0 a.b.c.191 255.255.255.255", "permit ip any a.b.c.191 255.255.255.255";
kommt aus dem Fritz!Fernzugangs-Tool wenn man "alles über das VPN" auswählt. Das hat Eisbaerin ja auch gesagt.

Die ganze Fritz-Box-VPN-Konfig ist so aus dem Tool ... unverändert (!). Ich hab mir gerade noch mal eine erstellt um das noch mal zu verifizieren ... da sind keine unterschiede! Aber die komplette Konfig (so wie sie das Fernzugangs-Tool erstellt), hat einen Fehler!? Ich wurde von T-Online drauf hingewiesen das ich einen offen DNS-Server habe ... ja - stimmt.

Der Server bleibt offen solang die VPN-Konfig aktiv ist (keine nutzung; nur ready to use)
Auflösen tut er aus dem Internet auch - er reicht aber nicht an den 200er DNS von mir weiter. Eine "gesperrte" Domain wird z.b. aufgelöst (passiert im LAN logischerweise nicht). Also löst das die Box auf - nicht der Server. fritz.box wird allerdings nicht aufgelöst - das könnte am DNS-Rebind-Schutz von der Box liegen?

Wenn ich eine Konfig ohne "alles übers VPN schicken" erstelle, sieht die Accesslist anders aus - das ist der einzige Unterschied in der Konfig. Selbst damit ist aber der DNS-Server offen ....

Wenn Du eine bestimmte Einstellung nicht verstehen solltest oder das Ergebnis eines systematischen Tests nicht alleine interpretieren kannst, helfe ich (im Rahmen meiner Möglichkeiten) gerne ...
wie gesagt die Konfig ist so aus dem offiziellen AVM-Tool :(
Und irgendwas scheint da fehlerhaft zu sein ... nicht weil kein DNS-Funktioniert, sondern weil DNS nach draußen offen ist.

Diese Support-Datei (support.lua) schau ich mir mal an.

- - - Aktualisiert - - -

Erste "Erkenntnise" aus der Support-Datei:

Code:
--- Configured Forwardings ---
vpn:internet:udp 0.0.0.0:53 0.0.0.0:53

da ist der DNS ... aber das steht ja nicht in der VPN-Konfig. Wo kommt das her? Wie bekomm ich das weg?

Code:
##### BEGIN SECTION resolve resolve.conf
resolv.conf:
nameserver 127.0.0.1
und hier kommt die Auflösung von Clients die der Box namentlich bekannt sind (dort in der Netzwerkumgebung drin stehend) her?

Code:
MAP  UDP [172.20.5.250]:53 [w.a.n.ip]:53, lifetime 120 secs, renew in 21 secs
    group "0/vpn"
da ist die direkte verknüpfung zum Fritz!Box-DNS. Aber unter Portforwardings steht die nicht drin

(die FRITZ!Box arbeitet für Domains jenseits ihrer eigenen (fritz.box, ggf. noch andere, sieht man alles in den Support-Daten) als "DNS forwarder/proxy")
unter DNS Forwarder oder nur forwarder find ich im File nichts - anders beschrieben?



showshringbuf dnsd
Google hilft hier zwar - aber für den Befehl muß ich ja auf die box ... telnet ist doch bei neuen Images nicht mehr aktivierbar?
 
Ich meinte nicht die "accesslist", die aus dem AVM-Tool erstellt wurde ... auch wenn die einen im Endeffekt unnützen Eintrag enthält (weil durch einen anderen Eintrag überstimmt), kann es ja sein, daß das Tool es so erstellt. Das war nur meine Frage, welches Tool das genau ist, weil es eben merkwürdig (damit unnötig und eher verwirrend) ist ... die eisbaerin hat diese Frage beantwortet, ich selbst habe das Tool zwar vor Jahren auch mal verwendet, aber das war in den seligen Zeiten, wo alle VPN-Verbindungen noch ein einer gemeinsamen Datei standen und bei jeder Änderung der Konfiguration auch wirklich immer alle auf einen Schlag eingelesen werden mußten. Seitdem das einzeln geht, ist da "Handarbeit" wesentlich effektiver.

Meine Aussage bezog sich jedenfalls auf die "accesslist" nach dem Satz und dort steht:
Code:
accesslist = "deny ip any a.b.c.200 255.255.255.255", "deny ip any a.b.c.200 255.255.255.255", "deny ip any a.b.c.0 255.255.255.0", "permit ip any any";
Das ist deshalb Unsinn, weil jeder Verkehr zur a.b.c.200/32 verboten wird, dabei befindet diese sich der Schilderung nach ja gar nicht "hinter" dem Tunnel. Zusätzlich sind die beiden ersten Einträge identisch und der dritte (der verbietet jetzt jeden Verkehr zu einer Adresse aus a.b.c.0/24 durch den Tunnel, damit logischerweise auch den zur .191, die nach Deiner Schilderung der Client ist) macht die beiden ersten auch noch obsolet. Da ist dann die Tatsache, daß mit dem letzten Eintrag wirklich jeder Verkehr in den (noch gar nicht aufgebauten) Tunnel gesteckt wird (womit dann wohl auch der bereits verschlüsselte Verkehr sein Ziel nicht mehr erreichen kann, wenn man die ansonsten vom AVM-Tool so erstellten "accesslist"-Beispiele analysiert), nur noch das Tüpfelchen auf dem Buchstaben.

Noch einmal, ich will mich hier gar nicht einmischen ... daher nur noch zwei Ungereimtheiten, die mir eben aufgefallen sind.

In der mobileconfig wird als DNS-Server die .200 festgelegt, diese Angabe für den DNS-Server wiederholst Du auch bei mehreren Gelegenheiten. Wenn das iPhone diese Einstellung tatsächlich übernehmen sollte, wie wird denn dann der ganze Rest, der im Moment funktioniert, aufgelöst?

BTW ... die Feststellung, daß überhaupt irgendwelche DNS-Auflösungen funktionieren, taucht auch erstmalig in #428 auf, wenn Du Deine eigenen Texte noch einmal richtig liest ... vorher hieß es immer, DNS ginge gar nicht und das sind schon zwei vollkommen verschiedene "Qualitäten".

Jedenfalls gibt es dann ohne eine passende Konfiguration des DNS-Servers unter der .200 (der müßte entweder wieder die FRITZ!Box als Forwarder verwenden oder sogar als SOA für die Domäne "fritz.box" auf die FRITZ!Box verweisen - das sind Besonderheiten in der Konfiguration, die Du nirgendwo erwähnst) keine sinnvolle Erklärung, wie eine Abfrage vom iPhone die Namen im Netz der FRITZ!Box richtig auflösen sollte, wenn dabei nicht gerade die FRITZ!Box als DNS-Server befragt wird ... das widerspricht aber in eklatanter Weise Deinen Festlegungen in der Konfiguration in #415, die Du in #417 noch einmal bestätigst - danach soll ja das iPhone eigentlich den DNS-Server unter .200 benutzen.

Vielleicht sollte man also erst einmal das abklären, was das iPhone da nun wirklich macht und genau das geht mit einem Packet-Dump auf der FRITZ!Box auf dem richtigen Interface problemlos, weil dort die Pakete nach der Decapsulation protokolliert werden. Das meinte ich u.a. mit "weniger Deduktion, mehr Aktion" ... und das kann Dir niemand abnehmen.

- - - Aktualisiert - - -

Wenn Du von Deinem Provider darauf hingewiesen wirst, daß Du einen "offenen DNS-Server" betreibst, sollte das (vorausgesetzt die MA des Providers wissen, wovon sie da reden) eigentlich darauf hinauslaufen, daß Dein DNS-Server externe Anfragen von beliebigen Clients für beliebige Domain-Namen akzeptiert und dann darauf antwortet.

Da DNS-Abfragen in aller Regel auf UDP-Paketen basieren und man die Absenderadresse so eines UDP-Paketes beliebig fälschen kann, ist das ein Verhalten, mit dem der DNS-Server DDoS-Attacken auf bestimmte Ziele unterstützt. Dazu sendet der Angreifer einfach eine Abfrage für irgendeine Domain (die eine recht lange Antwort erforderlich macht) unter Verwendung der Absenderadresse des anzugreifenden Ziels und Dein DNS-Server antwortet dann brav an den Falschen und müllt ihn mit einer (gar nicht erwünschten) Antwort zu.

Auf diesem Weg kann man den Traffic (nicht in Bezug auf die Anzahl der Pakete, aber in Bezug auf ihre Länge) potenzieren ... wird aus einer Anfrage von 80 Byte eine Antwort von 1400 Byte, ist das schon eine erhebliche "Verstärkung" und dann kommt noch hinzu, daß die Quelle der Abfrage (die unter Kontrolle des Angreifers steht) in der "gesparten Zeit" (denn sie muß ja nicht selbst die 1400 Byte senden und kann sich somit an einem weiteren Paket zu schaffen machen) weitere offene DNS-Server in diese Attacke einbeziehen kann. Antworten dann auf einmal 100 solcher offenen DNS-Server auf Anfragen, die das angegriffene Ziel niemals gestellt hat, verstopft das trotzdem die Internet-Verbindung und die eigentlichen Aufgaben können nicht mehr "in time" realisiert werden. Das ist das Grundprinzip eines DoS-Angriffs ... eben "denial of service" und dabei helfen eben u.a. solche "open relays", wie Du dann wohl eines betreibst.

Es hat niemand etwas dagegen, wenn Dein DNS-Server alle Anfragen von internen Clients oder auch aus Deinen VPN-Verbindungen beantwortet ... ja selbst die Antworten auf externe Abfragen sind kein Problem, solange sie sich auf die Domains beschränken, für die dieser Name-Server "authoritative" ist, wobei das für einen DNS-Server hinter einem DSL-Anschluß (davon gehe ich bei der Verwendung einer FRITZ!Box mal aus) schon extrem ungewöhnlich wäre, wenn der wirklich für irgendeine Domain beim betreffenden NIC als "authoritative" durchgegangen sein sollte.

Jedenfalls wird wg. des oben beschriebenen Szenarios (das geht u.a. auch für ältere Versionen der NTP-Server-Software von http://www.ntp.org/) so ein "open relay" eben auch zur Gefahr für andere Internet-Server und deshalb sollte man schon wissen, was man da eigentlich macht, wenn man sich an das Aufsetzen so eines Dienstes wagt. Inzwischen reagieren auch "abuse"-Kontakte der Provider bzw. ich komme (gerade bei der Telekom) immer mehr zu der Vermutung, daß die Leute inzwischen erkannt haben, daß sie "Mittäter" sind in so einem Angriff und ihrerseits aktiv ihre Netze (bzw. die Router/Server ihrer Kunden) auf solche Probleme prüfen und dann auch schon ihrerseits tätig werden, bevor das Kind in den Wald geschüttet wurde.
 
Zuletzt bearbeitet:
Hallo zusammen,
nach längerem Suchen und mehreren "zerstören" der Fritzboxen, muss ich mich hier auch mal einklinken.

Folgendes Szenario

Fritzbox 1
IP-Adresse intern 192.168.180.1
IP-Netz 192.168.180.0
IP-Adresse extern 93.232.x.x
Dyn-DNS eingerichtet und erreichbar


Fritzbox 2
steht hinter Speedport Router
IP-Adresse intern 192.168.188.1
IP-Netz 192.168.188.0
IP-Adresse des Routers 192.168.2.1
Dyn-DNS eingerichtet und erreichbar

VPN-Verbindung zwischen beiden Fritzboxen steht und ich kann die jeweils andere Seite pingen.

Jetzt soll der gesamte Traffic der Fritzbox 2 über die VPN-Verbindung zu Fritzbox 1 kommen und erst dann mit der externen IP der Fritzbox 1 "rausgehen".

Welche IP's bzw Netze müssen jetzt bei welcher Fritzbox in den Accesslisten eingetragen werden?
Hab bereits einige Versuche hinter mir, auf beiden Fritzboxen, mit anschließendem Internetzugriffausfall auf den jeweiligen Boxen.

Schonmal Danke im Voraus.
 
Zuletzt bearbeitet:
Keine Ahnung, wie es anderen geht ... ich kann solche Fragen merkwürdigerweise immer am besten beantworten, wenn ich eine Konfigurationsdatei sehe. Hier dann sicherlich einmal die derzeit funktionierenden Konfigurationen und die Änderungen, die zum gewünschten Ergebnis führen sollten, es aber dann doch nicht taten - zumindest mal eine Variante davon.

Neben der sichtbaren "Beweisführung", daß man tatsächlich gesucht und gefunden hat, was bei anderen funktionierte (selbst wenn es das bei einem selbst nicht auf Anhieb macht), kann man dann das Prinzip irgendwie besser verstehen. Auch kann man sich unter "verschiedene Versuche" besser etwas vorstellen, wenn man diese mal schriftlich vor sich hat.

Hier begreife ich zum Beispiel nicht, wie das in #432 Geschriebene für FRITZ!Box 2 funktionieren soll. Wenn die hinter einen Speedport-Router ist und trotzdem die externe IP-Adresse 91.10.irgendwas hat, ist das reichlich verwirrend (und sehr unüblich). Ein Router, der auf seinem internen Netz eine 91.10.x.x bereitstellt, ist schon etwas "gewöhnungsbedürftig", aber tatsächlich nicht unmöglich. Nun mag ja meine überbordende Skepsis fehl am Platze sein, aber hier würde ich doch zuerst auf einen Fehler in der Beschreibung tippen.
 
Hallo Peter,

das stimmt natürlich mit der IP-extern hinter dem Speedport. Mein Fehler beim tippen. Hab es bereits im Beitrag angepasst.


Hier die Config der Fritzbox2:

Code:
[I]vpncfg {
        connections {
                enabled = yes;
        editable = yes;
                conn_type = conntype_lan;
                name = "fritzbox1";
                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 = "fritzbox1";
                localid {
                        fqdn = "fritzbox2";
                }
                remoteid {
                        fqdn = "fritzbox1";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "xxxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.180.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "deny ip any 192.168.188.0 255.255.255.0", "permit ip any any";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF[/I]

Das war die letzte, mit der ich dann allerdings die fritzbox2 "abgeschossen" habe und erst wieder vor ort mich verbinden und die konfig rausnehmen muss.


Mit dieser hat es zuletzt funktioniert, dass sich beide Fritzboxen miteinander verbunden haben.

Code:
[I]vpncfg {
        connections {
                enabled = yes;
        editable = yes;
                conn_type = conntype_lan;
                name = "fritzbox1";
                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 = "fritzbox1";
                localid {
                        fqdn = "fritzbox2";
                }
                remoteid {
                        fqdn = "fritzbox1";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "xxxx";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.188.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.180.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "deny ip any 192.168.180.0 255.255.255.0";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}


// EOF[/I]
 
Zuletzt bearbeitet:
schorter schrieb:
Mit dieser hat es zuletzt funktioniert, dass sich beide Fritzboxen miteinander verbunden haben.
Das bezweifele ich stark.

Warum?

Der Eintrag
Code:
accesslist = "deny ip any 192.168.180.0 255.255.255.0";
verhindert, daß der Verkehr zur 192.168.180.0/24 durch den Tunnel gesendet wird.

In der ersten Konfiguration legt der Eintrag
Code:
accesslist = "deny ip any 192.168.188.0 255.255.255.0", "permit ip any any";
dann fest, daß kein Verkehr mit einer Zieladresse 192.168.188.0/24 durch den Tunnel gehen soll, alles andere dann aber schon.

Wie soll das denn gehen?

Erstens käme auf der FRITZ!Box 2 ohnehin der Verkehr für 192.168.188.0/24 niemals auf "dev dsl" an, wenn dort das LAN-Interface als 192.168.188.1/24 konfiguriert ist. Zweitens würde jetzt aller Verkehr (auch der bereits einmal verschlüsselte) immer wieder durch den Tunnel gesendet.

Ich weiß nicht so richtig, was Du da verstanden hast ... aber wenn man von einer "normalen" VPN-Verbindung ausgeht und sich diese bei AVM mal ansieht, verstehe ich beim besten Willen nicht, wie man auf die Idee kommen sollte, da mit irgendwelchen "deny"-Einträgen in "accesslist" zu arbeiten.

Die Beschreibung kann auch immer noch nicht richtig stimmen ... wenn die FRITZ!Box 2 jetzt die 192.168.2.1 als externe Adresse verwendet, was muß man sich dann unter
schorter schrieb:
Dyn-DNS eingerichtet und erreichbar
vorstellen? Die FRITZ!Box würde hier die Adresse (ohne weitere Vorkehrungen, die man da treffen könnte/müßte) ständig wieder aufs Neue auf 192.168.2.1 aktualisieren wollen ... selbst wenn der DynDNS-Anbieter das vielleicht auf der Basis der tatsächlich verwendeten externen IP-Adresse richtig einträgt, würde sich die Box damit nicht zufrieden geben, solange es nicht die erwartete 192.168.2.1 ist.

Solange die FRITZ!Box 2 sich hinter einem NAT-Router befindet, ist es am sinnvollsten, für eine (tatsächlich funktionierende) VPN-Verbindung die Rollen der Peers explizit festzuschreiben. Damit wird die eine Box zum "initiator" (das wäre hier FRITZ!Box2) und die andere reagiert nur passiv auf eingehende VPN-Verbindungen (responder). Was dazu in der Konfiguration notwendig ist, findet sich in anderen Threads hier im IPPF. Ob das in FRITZ!Box 1 vielleicht schon passend konfiguriert ist, kann man nicht wissen ... u.a. deshalb schrieb ich von "Konfigurationen" im Plural.

Wenn dann eine tatsächlich funktionierende VPN-Verbindung existiert, braucht es die passende "accesslist" in der zweiten FRITZ!Box (in der ersten sind gar keine Änderungen erforderlich), damit der Traffic aus dem LAN der FRITZ!Box 2 (das könnte dann z.B. aller Verkehr von einer Adresse 192.168.188.0/24 sein, denn der bereits in IPSec gekapselte Verkehr hat dann keine Absenderadresse aus 192.168.188.0/24 mehr, sondern verwendet die 192.168.2.1 als Source - EDIT: zumindest sollte er das, ggf. müßte man das checken) durch den Tunnel geleitet wird. Dazu muß man sich aber von jedem Gedanken verabschieden, daß mit einer "accesslist" irgendetwas genehmigt (permit) oder verboten (deny) würde ... die hier "genehmigten" Pakete werden in IPSec-Verpackung zum Peer geschickt, es handelt sich also um die Auswahl des zu verschlüsselnden Verkehrs und da kann nun mal ein
Code:
accesslist = "deny ip any 192.168.180.0 255.255.255.0";
nicht funktionieren, weil dann der Verkehr für 192.168.180.0/24 eben genau nicht in den Tunnel zur FRITZ!Box 1 gesteckt wird.

- - - Aktualisiert - - -

PS: Mit der klaren Rollenverteilung entfällt dann auch die Notwendigkeit, der FRITZ!Box 2 überhaupt einen DynDNS-Namen zu geben.
 
Zuletzt bearbeitet:
Hallo schorter,
Bitte nimm doch den DynDNS-Hostname "l......v.no-ip.biz" aus dem Listing in #434

LG
tuxedonet

- - - Aktualisiert - - -

damit der Traffic aus dem LAN der FRITZ!Box 2 (das könnte dann z.B. aller Verkehr von einer Adresse 192.168.188.0/24 sein

Hallo schorter,
die accesslist für FritzBox2 könnte demnach für "Catch-All"-Tunnelbetrieb wie folgt aussehen:

Code:
accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip 192.168.188.0 255.255.255.0 any";
Hinweis: habe DNS- und IPsec-Traffic explizit mittels reject-Anweisung vom VPN-Tunnel deselektiert;

die accesslist von FritzBox1 muß - wie PeterPawn schreibt - nicht verändert werden;

Bitte auch die PeterPawn angesprochene Initiator-Responder-Setup berücksichtigen und in die endgültige vpn.cfg einpflegen;

LG
Tuxedonet

- - - Aktualisiert - - -

Solange die FRITZ!Box 2 sich hinter einem NAT-Router befindet, ist es am sinnvollsten, für eine (tatsächlich funktionierende) VPN-Verbindung die Rollen der Peers explizit festzuschreiben. Damit wird die eine Box zum "initiator" (das wäre hier FRITZ!Box2) und die andere reagiert nur passiv auf eingehende VPN-Verbindungen (responder). Was dazu in der Konfiguration notwendig ist, findet sich in anderen Threads hier im IPPF.

Hallo Schorter,
die Suche nach Initiator und Responder lieferte folgenden Link: http://www.ip-phone-forum.de/showthread.php?t=283359&p=2138398&viewfull=1#post2138398

Bei Dir ist FritzBox_1 der Responder, d.h. die Zeilen aus Riverhoppers FB_ADSL Config verwenden.

Deine FritzBox_2 ist Initiator, die Zeilen aus Riverhoppers FB_LTE Config mit "keepalive_ip = 192.168.180.1" verwenden.

LG
Tuxedonet

EDIT: Text "FritzBox_2 ist Initiator" gemäß Hinweis von KunterBunter korrigiert
 
Zuletzt bearbeitet:
Hallo,

danke für die beiden Antworten. Ich glaube die Hitze im Büro, hat den Kopf beim denken beeinträchtigt.
Ich habe mir nochmal die Konfigs neu erstellt mit dem Tool von AVM. Hier dann wie beschrieben die Accesslist auf der Fritzbox2 angepasst, sowie die KeepAliveIP der Fritzbox1 eingetragen. Auf der Fritzbox1 habe ich den Remotehostname rausgenommen. Die beiden Konfigs kann ich allerdings erst heute Abend auf den Boxen einspielen.

Konfig Fritzbox1:


Code:
[I]vpncfg {[/I]
[I]        connections {[/I]
[I]                enabled = yes;[/I]
[I]                editable = yes;[/I]
[I]                conn_type = conntype_lan;[/I]
[I]                name = "fritzbox2";[/I]
[I]                always_renew = no;[/I]
[I]                reject_not_encrypted = no;[/I]
[I]                dont_filter_netbios = yes;[/I]
[I]                localip = 0.0.0.0;[/I]
[I]                local_virtualip = 0.0.0.0;[/I]
[I]                remoteip = 0.0.0.0;[/I]
[I]                remote_virtualip = 0.0.0.0;[/I]
[I]                remotehostname = "";[/I]
[I]                localid {[/I]
[I]                        fqdn = "fritzbox1";[/I]
[I]                }[/I]
[I]                remoteid {[/I]
[I]                        fqdn = "fritzbox2";[/I]
[I]                }[/I]
[I]                mode = phase1_mode_aggressive;[/I]
[I]                phase1ss = "all/all/all";[/I]
[I]                keytype = connkeytype_pre_shared;[/I]
[I]                key = "xxxx";[/I]
[I]                cert_do_server_auth = no;[/I]
[I]                use_nat_t = yes;[/I]
[I]                use_xauth = no;[/I]
[I]                use_cfgmode = no;[/I]
[I]                phase2localid {[/I]
[I]                        ipnet {[/I]
[I]                                ipaddr = 192.168.180.0;[/I]
[I]                                mask = 255.255.255.0;[/I]
[I]                        }[/I]
[I]                }[/I]
[I]                phase2remoteid {[/I]
[I]                        ipnet {[/I]
[I]                                ipaddr = 192.168.188.0;[/I]
[I]                                mask = 255.255.255.0;[/I]
[I]                        }[/I]
[I]                }[/I]
[I]                phase2ss = "esp-all-all/ah-none/comp-all/pfs";[/I]
[I]                accesslist = "permit ip any 192.168.188.0 255.255.255.0";[/I]
[I]        }[/I]
[I]        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", [/I]
[I]                            "udp 0.0.0.0:4500 0.0.0.0:4500";[/I]
[I]}[/I]


[I]// EOF[/I]



Konfig Fritzbox2:


Code:
[I]vpncfg {[/I]
[I]        connections {[/I]
[I]                enabled = yes;[/I]
[I]                editable = yes;[/I]
[I]                conn_type = conntype_lan;[/I]
[I]                name = "fritzbox2";[/I]
[I]                always_renew = no;[/I]
[I]                reject_not_encrypted = no;[/I]
[I]                dont_filter_netbios = yes;[/I]
[I]                localip = 0.0.0.0;[/I]
[I]                local_virtualip = 0.0.0.0;[/I]
[I]                remoteip = 0.0.0.0;[/I]
[I]                remote_virtualip = 0.0.0.0;[/I]
[I]                remotehostname = "fritzbox1";[/I]
[I]                keepalive_ip = 192.168.180.1;[/I]
[I]                localid {[/I]
[I]                        fqdn = "fritzbox2";[/I]
[I]                }[/I]
[I]                remoteid {[/I]
[I]                        fqdn = "fritzbox1";[/I]
[I]                }[/I]
[I]                mode = phase1_mode_aggressive;[/I]
[I]                phase1ss = "all/all/all";[/I]
[I]                keytype = connkeytype_pre_shared;[/I]
[I]                key = "xxxx";[/I]
[I]                cert_do_server_auth = no;[/I]
[I]                use_nat_t = yes;[/I]
[I]                use_xauth = no;[/I]
[I]                use_cfgmode = no;[/I]
[I]                phase2localid {[/I]
[I]                        ipnet {[/I]
[I]                                ipaddr = 192.168.188.0;[/I]
[I]                                mask = 255.255.255.0;[/I]
[I]                        }[/I]
[I]                }[/I]
[I]                phase2remoteid {[/I]
[I]                        ipnet {[/I]
[I]                                ipaddr = 192.168.180.0;[/I]
[I]                                mask = 255.255.255.0;[/I]
[I]                        }[/I]
[I]                }[/I]
[I]                phase2ss = "esp-all-all/ah-none/comp-all/pfs";[/I]
[I]                accesslist = "reject udp any any eq 53", "reject udp any any eq 500", "reject udp any any eq 4500", "permit ip 192.168.188.0 255.255.255.0 any";[/I]
[I]        }[/I]
[I]        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", [/I]
[I]                            "udp 0.0.0.0:4500 0.0.0.0:4500";[/I]
[I]}[/I]


[I]// EOF[/I]




Dies würde dann jetzt am Ende bedeuten, dass die Fritzbox2 und alle Geräte die dahinter hängen, ausschließlich über die Fritzbox1 aus dem Internet erreichbar sind?
 
Zuletzt bearbeitet von einem Moderator:
Dies würde dann jetzt am Ende bedeuten, dass die Fritzbox2 und alle Geräte die dahinter hängen, ausschließlich über die Fritzbox1 aus dem Internet erreichbar sind?
Das ist ggf. noch einmal eine vollkommen andere Baustelle ... in #432 ist von eingehenden Verbindungen nichts zu lesen.

Auch hier gilt, daß das gewünschte Szenario umfassend beschrieben werden sollte/muß ... es ist einfacher, gezielt eine einzelne Lösung zu erläutern als einen Berg von 100 möglichen Lösungen aufzutürmen, weil man einfach nicht genau weiß, was am Ende dabei herauskommen soll. Mit einzelnen hingeworfenen Brocken unter "weitgehender Wahrung der Geheimhaltungspflichten" kann man kaum etwas Sinnvolles anfangen.
 
Ok, ich versuch das endgültige Szenario mal zu erklären.

Standort1 -> Fritzbox1 <-> Internet <-> Speedport <- Fritzbox2 <- Standort2 <- angeschlossenes Gerät

Das angeschlossene Gerät am Standort2 soll sich im gleichen Netz wie die Geräte am Standort1 befinden bzw mit der gleichen externen IP im Internet sein.
Es wird regelmäßig eine IP-Abfrage gemacht, ob sich 2 Geräte im gleichen Netz befinden bzw mit der gleichen externen IP im Internet sind.
Diese Abfrage wird auf den Standort1 von ausserhalb geschickt. Am Standort1 steht das Hauptgerät und am Standort2 das Zweitgerät. Beide sollen sich aber nach aussen hin, am gleichen Standort befinden bei der IP-Abfrage.

Ich hoffe ich hab es einigermaßen auf den Punkt und verständlich gebracht.
 
Ich hoffe ich hab es einigermaßen auf den Punkt und verständlich gebracht.
Das sehe ich (etwas) anders. Schon die Frage, was denn eine "IP-Abfrage" sein soll und wie die "gemacht" wird, ist weiterhin offen, man hat also gar keine Vorstellung, welche Protokolle dabei zum Einsatz kommen, wie eine solche "Abfrage" "von ausserhalb" überhaupt gesendet wird, wie sie "das Hauptgerät" am Standort 1 finden soll, was das für ein "Zweitgerät" sein soll, usw. usf. ... ich könnte die Liste noch ziemlich beliebig fortsetzen.

Auch wenn jetzt der letzte Satz aus #437 ausführlicher formuliert wurde, ist es ja weiterhin mehr als nebulös, was das am Ende werden soll.

Keine Ahnung, wie andere das sehen ... ich komme mir (auch wenn ich Dir nicht unterstellen will, daß das das Ziel war - ok, 3x (gleichklingendes) "das(s)", gar nicht soo schlecht - ein "dieses" dazwischen wäre langweilig) irgendwie "veralbert" vor.

Das oben mehr Um- als Beschriebene kann genauso für einen "entfernt aufgestellten Media-Receiver" an einem T-Entertain-Anschluß gelten (oder generell für eine Umgehung von DRM-Lösungen auf Basis von IP-Adressen) wie für die Prüfung, ob das Equipment zur Verifikation der Abschußcodes der Kernwaffen den US-Stützpunkt nicht verlassen hat (die verwendeten Formulierungen lassen letzteres ja fast wahrscheinlicher erscheinen).
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.