[Gelöst] LAN-LAN-Koppelung mit nur 1 öffentlichen IP

frz

Neuer User
Mitglied seit
23 Jan 2015
Beiträge
9
Punkte für Reaktionen
0
Punkte
0
Hallo zusammen,

ich möchte 2 Fritzboxen (7362 SL, OS 6.20) per VPN koppeln. Dafür bin ich nach dieser Anleitung vorgegangen: VPN-Verbindung zwischen zwei FRITZ!Box-Netzwerken einrichten.

Problem: nur Fritzbox A hat eine öffentliche IP, Fritzbox B sitzt hinter einem NAT, Portweiterleitung unmöglich.
In der verlinkten Anleitung steht "•Mindestens eine der beiden FRITZ!Boxen muss vom Internetanbieter eine IPv4-Adresse aus dem öffentlichen Adressbereich erhalten.". Jedoch soll ich in beiden Boxen als Internetadresse die MyFritz-Adresse der jeweils anderen eintragen, was durch die private IP von Box B nicht geht.

Wenn ich in Box B die Myfritz-Adresse von Box A eintrage und in Box A die private IP von Box B, ist der einzige Effekt, dass ich Box B nicht mehr über den Fernzugriff erreiche.
Was muss ich nun als VPN-Adresse in Box A eintragen? Geht das überhaupt? Sobald sich Box B mit A verbindet, müsste diese ja auch trotz NAT mit ihr kommunizieren können.

Btw: Box A hat IP 192.168.178.1, Box B 192.168.10.1, ich hoffe die IP-Netze sind unterschiedlich genug.
 
Zuletzt bearbeitet:
Wenn ich das mit "Fritz-Fernzugang einrichten" mache, bekomme ich eine Meldung, dass VPN mit 192.168.178.0/24 nicht möglich ist. Wundert mich, dass die Einrichtung so geklappt hat. Wichtig ist, dass die Verbindung von der Box aus aufgebaut wird, die hinter dem NAT sitzt. Funktioniert bei mir einwandfrei von LTE mit CGNAT, zu VDSL ohne NAT.

jo
 
Heißt das, ich muss Fritzbox A auf 192.168.20.1 einstellen?
Dann und Box B auf A per LAN-LAN verbinden lassen, was trage ich dann bei Box B als LAN-LAN Internetadresse ein? 192.168.10.1?
 
@frz:
Mit dem eingebauten Assistenten der Firmware wird das nichts werden (oder nur zufällig funktionieren, wenn tatsächlich mal Box B mit Box A Kontakt aufnimmt, während Box A "schweigt"), da dort die Adresse/der DNS-Name der Gegenstelle an mehreren Stellen mit unterschiedlicher Bedeutung verwendet wird. Du brauchst ein per "FRITZ!Fernzugang einrichten" oder anhand eines Templates erstelltes Konfiguration-Datei-Paar für beide Seiten, dann kannst Du auch problemlos Änderungen an den Dateien vornehmen und diese anschließend auf beiden Boxen importieren, natürlich jeweils nur die eine für diese Seite erzeugte VPN-Datei.

Die externe Adresse der FRITZ!Box wird an zwei Stellen verwendet ... einmal zur Identifikation des passenden Schlüssels (bzw. beim AVM-IKE der passenden Konfiguration) anhand von "localid"/"remoteid" und zum zweiten zur Angabe der Adresse/des Namens der Gegenstelle (remotehostname). Da die Box mit der öffentlichen IP die andere ohnehin nicht erreichen kann, bleibt der "remotehostname" bei der Konfiguration für diese Box einfach leer (das kann der eingebaute Assi eben nicht). Als MyFRITZ!-Adresse gibst Du einfach den MyFRITZ!-Namen an, da braucht es keine Unterscheidung in öffentliche und private IP.

Nach dem Import der beiden Konfigurationen (am besten die "passive" Box zuerst abfertigen) ist dann die Box mit der öffentlichen IP immer der Responder beim Verbindungsaufbau und die Box mit der privaten IP immer der Initiator. Am besten dort noch eine "keepalive_ip" von Hand eintragen (das ist das, was aus dem Haken "automatisch aufbauen" im Assistenten wird) und das Ganze sollte laufen.

Der Assi hat nur da seine Stärken, wo er bei passenden Boxen gleich noch die Bridge konfiguriert, um die VPN-Verbindung nur auf einzelne LAN-Ports zu beschränken. Da "FRITZ!Fernzugang einrichten" die dazu notwendigen Änderungen an der ar7.cfg nicht kann, ist das von Hand etwas mühsam.

EDIT: Ich habe mir gerade mal die AVM-Anleitung durchgelesen und verstehe ehrlich gesagt nicht, wie damit eine sicher aufzubauende Verbindung zustande kommen soll, wenn eine der beiden Boxen (nehmen wir mal B) keine öffentliche IP-Adresse hat. Wenn Box A von sich aus die Verbindung startet und auf eine passende Antwort von Box B wartet, während Box B ihrerseits die Verbindung aufbaut, trifft das erste Paket von Box B in Box A immer auf einen Zustand, wo der "gemeinsame Schlüssel" (die SA) durch ein Timeout für den versuchten Verbindungsaufbau von A nach B irgendwann wieder invalidiert wird. Das Timeout für Box A ist ja auch unvermeidlich, da Box B von dem Verbindungsversuch logischerweise nichts bemerkt und damit weder positiv noch negativ antworten kann. Daher klappt das vermutlich dann ziemlich gut, wenn die beiden Boxen in einigem zeitlichen Abstand gestartet werden und so niemals gleichzeitig den VPN-Tunnel aufbauen wollen. Ansonsten geht das - nur meine eigenen Beobachtungen - schief und dann hilft es ungemein, wenn Box A gar nicht erst versucht, mit Box B von selbst Kontakt aufzunehmen und einfach wartet, bis Box B sich meldet. Dann können die beschriebenen Effekte (TO invalidiert bestehende SA) gar nicht erst auftreten, da das TO auf Box A ja ausbleibt. Ich konnte das bei mir in der Vergangenheit desöfteren beobachten, da ich - wenn Daten zur Übertragung anstehen - auf beiden Seiten einer VPN-Verbindung in den FRITZ!Boxen diese VPN-Verbindung erst einmal per HTTPS-Zugriff aktivieren lasse. Wenn dann beide aktiv versuchen, eine Verbindung herzustellen, geht das mal gut und mal eben nicht. Kann nur eine Box Initiator sein, klappt es immer zuverlässig.
Das ist in etwa dasselbe wie die Bemerkung von rollo, daß die Box hinter dem NAT die Verbindung aufbauen muß.
 
Zuletzt bearbeitet:
PeterPawn, vielen Dank für die ausführliche Antwort, das bringt mich meinem Ziel schon wesentlich näher!

Da die Box mit der öffentlichen IP die andere ohnehin nicht erreichen kann, bleibt der "remotehostname" bei der Konfiguration für diese Box einfach leer.
Habe in der öffentlichen Box nun 'remotehostname = "";'

Am besten dort noch eine "keepalive_ip" von Hand eintragen
Wenn ich unter "vpncfg { connections {" 'keepalive_ip = "Fritzbox B.myfritz.net";' eintrage verweigert mir Box A den Import der cfg. Muss ich hier die lokale IP von Box B (192.168.20.1) eintragen? Diese ist ja erst nach Aufbau erreichbar.

Ich habe mir gerade mal die AVM-Anleitung durchgelesen und verstehe ehrlich gesagt nicht, wie damit eine sicher aufzubauende Verbindung zustande kommen soll, wenn eine der beiden Boxen (nehmen wir mal B) keine öffentliche IP-Adresse hat [...] Das ist in etwa dasselbe wie die Bemerkung von rollo, daß die Box hinter dem NAT die Verbindung aufbauen muß.
Genau das dachte ich mir auch beim Durchlesen der Anleitung, und funktionierte auch wie erwartet nicht ;) Zum Glück gibt es euch!
 
Früher habe ich für den einseitigen Start des VPNs immer ein Dummy-IP-Nummer empfohlen, die sich bei Bedarf im Subnetz der Box mit der öffentlichen IP re-registriert, wofür es auch schon länger die Option "VPN-Verbindung dauerhaft halten" gibt.

Bei übersichtlichen VPNs genügt aber völlig das Erstellen per WebIF "Ihr Heimnetzwerk mit einem anderen FRITZ!Box-Netzwerk verbinden (LAN-LAN-Kopplung)".
Nur bei der Box ohne öffentliche IP sollte die Option "VPN-Verbindung dauerhaft halten" setzen.
Der WebIF-VPN-Assistent erzeugte tatsächlich bei mir eine identische Konfiguration - bis auf o.g. Option und natürlich das selbst zu wählende VPN-Kennwort (Preshared Key). Also 2 klare Vorteile gegenüber dem AVM-Tool: Die elegante Option zum ".. dauerhaft halten" existiert und es geht auch mal mit einem 178er Subnetz, und alles ohne zusätzliche Fummelei.

Vonm 178er Subnetz wird i.A. nur dringend abgeraten und vom "Fritz-Fernzugang einrichten" verhindert, da man beim "Fernzugang für einen Benutzer" dann jedes Mal im Regen steht, wenn man seinen VPN-Client in einem anderen FritzBox-Netzwerk mit unverändertem 178er Subnetz betreiben will.
 
@frz:
keepalive_ip ist eine interne IP-Adresse im entfernten Netz. Das muß auch nicht zwingend das VPN-Gateway auf der anderen Seite sein.

@andilao:
andilao schrieb:
Früher habe ich für den einseitigen Start des VPNs immer ein Dummy-IP-Nummer empfohlen
Mit einem zusätzlichen "S" ist das eindeutiger. ;)

Das Erstellen mit dem Assistenten mag ja auch seine Vorteile haben, aber da es einen echten Export zum Nachbearbeiten nicht gibt (beim Komplett-Export sind dann die Credentials verschlüsselt und lassen sich so auch nicht einzeln importieren, was ja bei VPN-Verbindungen inzwischen auch einzeln und ohne Box-Neustart funktioniert), hat man dann bei späteren Anpassungen in meinen Augen "Huddelei", wenn man das nicht direkt auf der Box per Editor und mit "msgsend dsld vpnreload" macht. Solche Anpassungen können von anderen Proposals bis zu Änderungen von "accesslist"-Einträgen gehen, alles was jenseits der "Standardkonfiguration" liegt.
Das Erstellen eines Templates für die "erste VPN-Verbindung" kann man ja getrost auch dem externen Windows-Programm oder dem Assistenten in der Box selbst überlassen. Aber dann eben einfach die verschlüsselten Daten wieder durch Klartext ersetzen und die so entstehende Datei neu importieren (und beiseite legen für die nächsten Änderungen).
 
Zuletzt bearbeitet:
Vielen Dank, die Fritzboxen sind verbunden, VPN-Status in beiden Boxen leuchtet grün :)
nun fehlt noch eins: ich erreiche aus dem 192.168.20.0-Netz nicht meinen PC im .10.0-Netz, pingen ergibt nur Zeitüberschreitung. Was fehlt noch?

edit: entfernte Fritzbox anpingen funktioniert (40 ms)
edit2: Die Firewall war Schuld ;) Pingen funktioniert. Gibt es eine Möglichkeit, dass ich die Geräte im remote Netzwerk im Explorer unter "Netzwerk" finde? Ganz zusammengeführt scheinen die Netzwerke doch nicht zu sein :(
 
Zuletzt bearbeitet:
@frz:
Du hast aber schon auch das komplette Netz auf der anderen Seite von 192.168.178.0/24 auf 192.168.10.0/24 geändert und nicht nur die Einstellungen in der VPN-Konfiguration, oder?

Hat der PC auf der anderen Seite diese Änderung auch schon "geschluckt" und tatsächlich eine Adresse aus 192.168.10.0/24 bezogen? Bei Windows-PCs mit aktivierter Firewall ist das entfernte Netz u.U. auch "public", da kein(e) NAT auf eine lokale Adresse stattfindet. Das könnte eine weitere Ursache sein, denn so unterscheiden sich ja die beiden Subnetze und eine Verbindung wird eben nicht als "lokal" klassifiziert.
 
@PeterPawn
IP der lokalen (öffentlichen) Fritzbox selbst ist natürlich auf 192.168.20.1 umgestellt, nicht nur das VPN ;)
fritz-vpn.PNG
auf der anderen Fritzbox sind lokal und entfernt vertauscht, wie es sein sollte.

Habe den Remote PC eben neu gestartet, bekommt immer noch eine .10.xx IP. Firewall ist gerade komplett deaktiviert. Woher soll eigentlich der remote pc (oder die remote fritzbox) wissen, dass sie .20.xx IPs verteilt und nicht die .20er Fritzbox .10.xx IPs? Außerdem soll ja der remote PC seine eigene Internetverbindung benutzen und nicht erst tunneln. Nur lokal hätte ich gerne 1 Netz.

Edit: Falls ich nicht IPs aus dem gleichen Subnetz bekomme, lässt sich das irgendwie über die statischen IPv4-Routen in der Fritzbox lösen? Habe damit leider absolut keine Erfahrung.
 
Zuletzt bearbeitet:
Habe den Remote PC eben neu gestartet, bekommt immer noch eine .10.xx IP.
Das wird jetzt alles etwas unübersichtlich:

FRITZ!Box A
LAN-Segment 192.168.20.0/24
IP 192.168.20.1
öffentliche IP mit DynDNS-Name BoxA.myfritz.net

FRITZ!Box B
LAN-Segment 192.168.10.0/24
IP 192.168.10.1
nicht-öffentliche WAN-IP, DynDNS-Name (eigentlich egal, nur für localid/remoteid interessant) BoxB.myfritz.net

Wo steht denn nun der PC und wen oder was kann er nicht erreichen? Wenn er eine 192.168.10.0/24-Adresse per DHCP bezieht, steht er ja offenbar auf der Seite der VPN-Verbindung, wo sich Box B befindet. Wenn er jetzt Pakete zur 192.168.20.1 (also FRITZ!Box A) schickt, gehen die an sein Standard-Gateway (FRITZ!Box B) und dort wird dann - anhand der Kenntnisse aus der VPN-Konfiguration - knallhart erkannt, daß die 192.168.20.0/24 irgendwo jenseits einer VPN-Verbindung zu suchen ist und sogar welche das sein muß. Also werden die Daten über den Tunnel dorthin geschickt und auf der anderen Seite (Zieladresse 192.168.20.1, Quelladresse 192.168.10.?? (der PC)) auf die Reise geschickt. Antwortet jetzt jemand auf diese Pakete, gehen die dort wieder an die FRITZ!Box A und die macht dasselbe wie die Box B vorher, eben nur für die andere Richtung. Deshalb müssen auch die Angaben für Phase2 und die "accesslist"-Einträge entsprechend gespiegelt sein. Wenn die Verbindung nicht nur zur FRITZ!Box A, sondern zu einem weiter "hinten liegenden" Ziel in 192.168.20.0/24 gehen soll, dann leitet eben FRITZ!Box A den Verkehr tatsächlich ins LAN (bei .1 als Ziel bleibt das in der FRITZ!Box) und nimmt von dort die Antworten entgegen.

BTW: Firewall aktivieren nicht vergessen.

Und die Frage, wo da Pakete ankommen und wo nicht, läßt sich immer noch am ehesten mit einem Packetdump (gestartet über http://fritz.box/capture.lua) beantworten. Auch kann die Veröffentlichung der beiden VPN-Konfigurationsdateien nicht wirklich schaden, selbst die verschlüsselten Daten (wenn Du die aus dem Export oder direkt aus der Box holst) kann man dabei stehen lassen (wenn man nicht noch die MAC-Adresse und den WLAN-Key im Auslieferungszustand dazu schreibt) und sollte nur die lesbaren Angaben (in Maßen, damit man noch sieht, was da wirklich steht, zumindest das Format) irgendwie verändern.

Den Rest Deiner Fragen (Woher weiß der remote PC ... und das Thema "tunneln oder nicht") verstehe ich nicht so richtig. Das bitte noch einmal in vollständigen Sätzen formulieren, wenn die Erläuterung oben nicht ausreichend ist.
 
Hab hier mal ein schönes Bild gemalt, um die Situation zu veranschaulichen:
plan.PNG

Mit Tunneln meinte ich, dass PC B nicht den Gateway A benutzen soll, da er sonst unnötige Umwege ins Internet nimmt. Nur im LAN hätte ich ihn gerne im gleichen Subnetz.
 
Heißt das rote "Ping möglich" jetzt, daß Du pingen kannst oder daß Du pingen willst?

Wenn Du kannst, ist alles in Butter ... Deinen Wunsch nach der Sichtbarkeit im Netzwerk-Explorer von Windows kannst Du (ohne weitere Konfigurationsorgien) beruhigt ad acta legen. NetBEUI bleibt innerhalb der Broadcast-Domain, das ist hier das Subnetz. Damit werden sich diese beiden Computer ohne die Hilfe eines Vermittlers (i.d.R. ein WINS-Server) nicht direkt sehen. Du kannst aber natürlich auch im Windows-Netzwerk (wenn die Firewall nichts dagegen hat, denn es sind immerhin keine lokalen Zugriffe) mit einer Adresse der Form
Code:
\\192.168.20.23\[I]freigabename[/I]
auf den entfernten PC zugreifen.
 
Ping möglich heißt Ping ist möglich, die Farbe war nur, um alles auseinanderzuhalten :)

Das Problem sind jetzt nur Programme, die selbst im Netzwerk suchen und sich nicht mit IPs füttern lassen (z.b. Steam in-home-Streaming), aber das lässt sich dann wohl nicht so leicht lösen :(

In der Firewall ist alles von 192.168.20[10].0/24 freigegeben.

Vielen Dank für deine Hilfe! Immerhin kann ich jetzt MS RDP über LAN statt Teamviewer benutzen ;)
 
beim Komplett-Export sind dann die Credentials verschlüsselt und lassen sich so auch nicht einzeln importieren
Per Editor lässt sich auch das lösen und den Teil für die Credentials hattest du selbst schon im nächsten Absatz:
Das Erstellen ... kann man ja getrost auch ... dem Assistenten in der Box selbst überlassen. Aber dann eben einfach die verschlüsselten Daten wieder durch Klartext ersetzen und die so entstehende Datei neu importieren (und beiseite legen für die nächsten Änderungen).
Das alles ändert aber nichts daran, dass frz per WebIF schneller zu seinem Ziel gekommen wäre und die Konfigurationen einstellbar bleiben - was natürlich auch nachträglich geht per "editable = yes;"



Das Problem sind jetzt nur Programme, die .. sich nicht mit IPs füttern lassen
Eine HOSTS-Datei ist da recht hilfreich, wo dann u.a. steht:
192.168.10.23 PC-B
192.168.20.23 PC-A
und schon kann man auf Freigaben zugreifen per \\PC-B\Freigabe, aber das ist leider (fast) nur Kosmetik und setzt aber auch voraus, dass die PCs feste IPs haben oder pro PC die Option "Diesem Netzwerkgerät immer die gleiche IPv4-Adresse zuweisen." aktiviert ist
Bei mir habe ich dann noch zusätzlich eine primitive Lösung, wo ich die HOSTS-Dateien aller PCs im VPN-Verbund an nur einer Stelle pflegen muss.
 
Das Problem sind jetzt nur Programme, die selbst im Netzwerk suchen und sich nicht mit IPs füttern lassen (z.b. Steam in-home-Streaming), aber das lässt sich dann wohl nicht so leicht lösen :(

Er meinst Broadcast/UPnP
 
Sollte aber auch bekannt sein, Zugriff per IP möglich, über Hostname nicht da der eine DNS nicht Geräte vom anderen kennt. Und auf jedem Gerät extra ne HOSTS Datei ist auch nervig. Ein WINS Server steht wohl auch meistens nicht zur Wahl.

UPnP/DLNA/Multicast/Broadcast ect. bleibt alles im eigenen Subnet, also nicht per VPN. Müsste man schon wenn gezielt alles ins Fremde Netz weiterleiten lassen.
 
In der VPN-Datei gibt es doch aber folgenden Parameter:
Code:
dont_filter_netbios = yes;
Da könnte man ja glatt denken, daß Netbios doch durchgelassen wird.
 
Per Editor lässt sich auch das lösen
Bitte erkläre (mir und auch späteren Lesern) doch, was Du damit meinst. Welcher Editor und wie ist das konkret zu lösen?

Das alles ändert aber nichts daran, dass frz per WebIF schneller zu seinem Ziel gekommen wäre
Das mag sein, ich will darüber nicht richten ... denn ich kenne die konkreten Voraussetzungen nicht gut genug.

Wenn frz erst "FRITZ!Fernzugang konfigurieren" installieren mußte (das weiß ich nicht, Du ?), dann kann das tatsächlich so sein. Wenn er Template-Files verwenden konnte oder das Programm bereits installiert war, ist das längst nicht mehr so eindeutig, da selbst bei "FRITZ!Fernzugang konfigurieren" einem einzelnen Aufruf des Programms zwei Aufrufe per GUI (einer auf jeder Box) gegenüber stehen. Natürlich muß man auch eigene Dateien erst mit zwei GUI-Aufrufen installieren, aber es sind keine weiteren Einstellungen vorzunehmen und die Fehlerwahrscheinlichkeit sinkt, eben weil die beiden Konfigurationsdateien von "FRITZ!Fernzugang konfigurieren" gleich für beide Seiten passend erstellt werden und damit abweichende Angaben für Netzwerkadressen und/oder PSK usw. direkt vermieden werden.

Gerne genommen ist nämlich der Fehler (aus Unaufmerksamkeit), das entfernte Gateway anstelle der Netzwerk-Adresse anzugeben, da das nicht geprüft wird - das ist mir selbst schon passiert, obwohl ich in dem Glauben lebe, mich mit VPNs an sich und dem AVM-IPSec-VPN im Speziellen ziemlich gut auszukennen. Da eine Angabe des Gateway samt Maske eigentlich in das Segment umgerechnet werden könnte und sich daraus dann gleich noch eine funktionierende keepalive_ip ableiten ließe, liest man manchmal eben nicht so genau (aber das war selbstverständlich (m)ein Fehler, den man nicht direkt dem Assi anlasten muß, den er aber als "Assistent" problemlos aufzeigen könnte); das mit dem ungenauen Lesen soll aber dem Vernehmen nach nicht nur mir passieren.

Da man den Preshared-Key (vollkommen zurecht, nicht daß ich das kritisiere, ich konstatiere es nur) bei jedem Editieren von Eigenschaften der VPN-Verbindung erneut eingeben muß, bleibt auch das eine potentielle Fehlerquelle und die Sicherheit wird durch die - bei ausreichend kompliziertem PSK unumgängliche - Speicherung (und sei es in Form eines Notizzettels) des PSK im Klartext an irgendeiner anderen Stelle auch ggü. der Klartext-Speicherung in einer für den Import geeigneten Datei nicht verbessert.

Meine Aussage ("Nimm Dateien und einen Editor.") bezog sich auch auf einen konkreten Kritikpunkt ("dual use" für die Adresse/den Namen der Gegenstelle), der existiert objektiv und führt jenseits der Standardkonfiguration zu Problemen - eine Seite mit nicht-öffentlicher IP-Adresse ist ein solcher Spezialfall. Auch die immer wieder auftauchende Anforderung, die VPN-Verbindung nur für bestimmte Clients zuzulassen (was eine Anpassung der accesslist-Eintragungen erforderlich macht), erfordert ein nachträgliches Editieren der VPN-Konfiguration und das ist nun einmal nur auf zwei Wegen möglich ... entweder direkt über Telnet auf der Box (was dann bei DOCSIS-Boxen nicht mehr funktioniert) oder den Export der gesamten FRITZ!Box-Konfiguration.

Bei den Änderungen an der Export-Datei besteht dann seit 06.20 wieder die Schwierigkeit, daß der Import nur noch mit korrekter Prüfsumme möglich ist und damit ist es mit einem "einfachen Editor" schon mal vorbei ... auch der nach einem solchem Import unumgängliche Neustart der Box führt - gerade dann, wenn man etwas mit VPN-Einstellungen experimentieren muß, bis es klappt - zu einem unnötig großen Aufwand (und Wartezeiten, die man leicht vermeiden kann).

Bei der Alternative, die einzelne VPN-Verbindung aus dem gesamten Export auszuschneiden für den einzelnen Import, sind wir wieder beim Ersetzen der verschlüsselten Daten durch Klartext beim Import (auch die Einstellung "editable = yes;" sollte man dann dringend in "editable = no;" ändern, wenn sie vorhanden ist) und damit letztlich wieder bei meinem ursprünglichen Vorschlag.

Wenn man diesen Aufwand irgendwann ohnehin treiben muß (weil man schon vorher weiß, daß man manuelle Änderungen vornehmen will/muß), dann kann man es auch gleich von Beginn an so machen und erspart sich spätere Kopfstände, um an die zu editierende Vorlage zu gelangen.

Ich bleibe dabei, daß mein Vorschlag - mit "FRITZ!Fernzugang konfigurieren" für Templates, wobei man diese Templates auch von woanders beziehen kann, und manuelle Anpassung der Dateien mit einem passenden Text-Editor - mit jeder (mir bekannten) aktuellen FRITZ!Box funktioniert (Telnet eben nicht) und bei mehr als einer Änderung der Konfiguration am Ende den geringeren Gesamtaufwand erfordert.

Nebenbei ... auch ansonsten verschenkt der "Assistent im GUI" (er ist ja eigentlich keiner, das weiß ich auch - gerade bei so komplizierten Sachen wie VPN und den aus Konfigurationsfehlern resultierenden (Sicherheits-)Problemen sollte er aber einer sein) in meinen Augen viel zuviele Möglichkeiten, die ihn zu einem echten Assistenten machen würden.
So warnt er beispielsweise nicht bei Überlappungen von entfernten Netzen (nicht mal bei Identität) für mehrere Verbindungen und auch die klaglose Akzeptanz der simpelsten PSKs wie "1234" ist bei der Verwendung des "aggressive mode" eine schwere Verfehlung. Ich meine tatsächlich nur "warnen und erklären", nicht Bevormunden des Nutzers. Wenn er darauf aufmerksam gemacht wird, daß 1234 untauglich ist, reicht das vollkommen und wenn er es dann immer noch verwenden will, ist ihn nicht zu helfen ... wobei man da sogar noch rigoroser sagen könnte: "Wenn Du Deine Sicherheit gefährden willst, nimm gefälligst Dateien ..." und sich als "Assistent" vielleicht tatsächlich verweigern sollte.

Apropos Sicherheit: Wenigstens konfiguriert das GUI für Phase2 eine Proposal-Auswahl, die PFS zuläßt ... die Auswahl für Phase1 (all/all/all), wo dann ein Downgrade bis zu DES/MD5 denkbar wäre, ist aber auch eher ein Witz.

Aber zurück zum Thema ...

Dein Workaround mit dem Auslassen von "Verbindung dauerhaft halten" funktioniert eben auch nicht in jeder Situation, das muß man an diesem Vorschlag kritisieren ... selbst wenn die Wahrscheinlichkeit von Kollisionen natürlich geringer ist, sind sie doch nicht ausgeschlossen.

Wenn nämlich irgendein Client auf der Seite von FRITZ!Box A Verbindung mit einem Client hinter FRITZ!Box B (oder der Box selbst) Kontakt aufnehmen will, startet FRITZ!Box A immer noch eine VPN-Verbindung, wenn die zu diesem Zeitpunkt nicht besteht. Das läßt sich - meines Wissens, aber ich lerne auch gerne dazu, wenn Du die richtige Vorgehensweise beschreibst - nur dadurch vermeiden, daß die FRITZ!Box A durch Auslassen von "remotehostname" und "remoteip" keine Möglichkeit hat, ihrerseits Kontakt aufzunehmen, was ja ohnehin nicht funktionieren würde und ein ganz normaler Fall bei der Konfiguration einer VPN-Verbindung mit mindestens einem Teilnehmer mit dynamischer IP-Adresse ist (road warrior configuration).

Die früher beschriebene Kollision läßt sich zumindest mit 50%iger Wahrscheinlichkeit dann auch wieder erzielen, wenn man z.B. von einem Client hinter FRITZ!Box A über die VPN-Verbindung die FRITZ!Box B konfiguriert und dabei ein Neustart der FRITZ!Box B erforderlich wird. Die dann aufgerufene Seite "Box wird neu gestartet, sie werden verbunden, wenn sie wieder bereit ist." (sinngemäß, ich starte jetzt nichts neu, nur um den Wortlaut zu haben) versucht in regelmäßigem Abstand das GUI der FRITZ!Box erneut aufzurufen. Damit würde also FRITZ!Box A - genauso wie vorstehend beschrieben - selbst die, durch den Neustart unterbrochene, VPN-Verbindung versuchen aufzubauen und auch ein erster, zweiter, dritter Fehler (jeweils mit dem Verwerfen des Pakets, das den Verbindungsaufbau ausgelöst hat) würde keine Auswirkungen haben, da diese "Neustart"-Seite im Browser eben immer wieder auf's Neue versucht, die wieder gestartete Box zu finden. Das ist ja sicherlich kein an den Haaren herbeigezogenes Szenario des Einsatzes einer VPN-Verbindung.

"VPN-Verbindung dauerhaft halten" ändert ja offenbar nur "keepalive_ip" und auch da hat der Assistent der FRITZ!Box seine Schwächen bei der Konfiguration, denn die von ihm auserkorene IP-Adresse für dieses Keepalive-Paket ist ganz simpel immer die erste Adresse im entfernten Netz (das geht soweit, daß bei (falscher) Konfiguration von 192.168.10.1/24 tatsächlich 192.168.10.2 ge"ping"t wird) und das funktioniert dann u.U. auch wieder nicht, wenn da andere "accesslist"-Vorgaben vorhanden sind. Eigentlich ist es nur ein "Mißbrauch" einer beliebigen entfernten Adresse für den umgehenden Aufbau der VPN-Verbindung, die tatsächliche Antwort der Gegenseite interessiert überhaupt nicht beim Verbindungsaufbau. Ob das sauber ist und einem nicht irgendwann mal auf die Füße fällt, mag jeder für sich selbst entscheiden. An die dort angegebene Adresse (das keepalive_ip hat nicht das geringste mit "dead peer detection" (DPD) von IPSec zu tun, eher noch mit einem "Offenhalten" von NAT-Verbindungen) wird ganz simpel ein ICMP-Echo-Request mit 25x "PING" als Payload gesendet, die Antwort kann ruhig auch ausbleiben, da der eigentliche Zweck (NAT offenhalten und Verbindung aufbauen) ja erfüllt ist. Wie das ggf. der Admin des entfernten Netzes sieht (das muß ja nicht zwingend auch eine FRITZ!Box sein), wenn da irgendjemand wild in seinem Netzwerk Adressen aufruft, die es u.U. gar nicht gibt, hängt auch von dessen Ansichten ab (ein anschlagendes IDS, das in einem solchen Ping den Versuch einer Kartographie des LAN von einer externen Adresse sieht, ist bestimmt auch nicht so spaßig). Ist sicherlich auch ein Spezialfall ... aber auch ein weiteres Beispiel für nicht immer sinnvolle Standardannahmen/-vorgaben des Assistenten. Da steht eben einfache Konfigurierbarkeit für häufige Szenarien gegen universelle Verwendung auch für etwas kompliziertere Konfigurationen.

und die Konfigurationen einstellbar bleiben - was natürlich auch nachträglich geht per "editable = yes;"
Das Ansinnen verstehe ich nicht ... wenn das heißen soll, daß man die Konfiguration dann einfacher per GUI editieren kann, dann will man das i.d.R. in dem hier vorliegenden Szenario gar nicht, warum habe ich schon geschrieben.

Da der eingebaute Assistent (ich bleibe dabei, um eine Abgrenzung zum Begriff "Editor" zu haben) auch alle Optionen/Einstellungen, die er nicht kennt, konsequent auf seine eigenen Vorstellungen zurücksetzt (von accesslist bis remotehostname), macht das für mich auch nur wenig Sinn.

Da hat ein kluger Programmierer/Designer erkannt, daß der GUI-Editor (vielleicht ist der Begriff besser) bei weitem nicht alle Szenarien abdeckt (das will er ja auch gar nicht) und es wurde Vorsorge getroffen, daß selbst erstellte VPN-Konfigurationen nicht ohne weiteres vom GUI-Editor "zerstört" werden können, indem für "editable" eben "no" als Standard angenommen wird. Wer das absichtlich mit "yes" ersetzt, kann dann auch gleich den GUI-Editor mit den aufgeführten "Unzulänglichkeiten" verwenden.

Auch die Tatsache, daß der GUI-Editor grundsätzlich jede mit ihm bearbeitete Konfiguration auch sofort wieder aktiviert (unabhängig davon, ob die Checkbox vor dem Bearbeiten aktiv war oder nicht), finde ich persönlich extrem unglücklich, denn so kann man eben nicht "mal nebenbei" eine deaktivierte Konfiguration bearbeiten und speichern. Bei dem dann offenbar zwingend erfolgenden "vpnreload" werden leider auch bestehende Verbindungen erst einmal getrennt und dann neu aufgebaut, was einem in einer parallel aufgebauten Verbindung laufenden Datentransfer auch nur in den seltensten Fällen gut tut. Das ist zwar auch beim Import einer VPN-Verbindung so, aber da sehe ich das sogar noch als Notwendigkeit ein ... beim GUI-Editor, der den aktuellen Zustand genau kennt, aber eher nicht. Auch der Abbruch und Neuaufbau der DSL-Verbindung beim Löschen einer VPN-Konfiguration ist sicherlich nur dann wirklich notwendig, wenn tatsächlich der dsld neu initialisiert werden muß, weil sich die Konfiguration z.B. von ipsecbrX-Bridges geändert hat. Das erfolgt aber nach meinem Verständnis/meinen Tests auch "ins Blaue" hinein.

Eine HOSTS-Datei ist da recht hilfreich
Das ist zweifellos auch vollkommen richtig (für Windows-Netzwerk-Clients gibt es dann mit der LMHOSTS-Datei sogar noch weitergehenden Möglichkeiten, die auch SMB-Besonderheiten konfigurierbar machen), allerdings hätte ich den Einwand von frz etwas anders interpretiert (angesichts des angeführten Beispiels Steam-InHome-Streaming). Und für das dort unbedingt erforderliche (und für die Sichtbarkeit im Windows-Netzwerk auch wünschenswerte) Layer2-Forwarding ist das AVM-IPSec-VPN einfach nicht geeignet.
Ich wollte das nur noch einmal festhalten, falls es jemand so verstehen sollte, daß man mit einer hosts-Datei auch die Steam-Problematik lösen könnte ... die besteht nicht darin, ob man IP-Adressen oder Namen verwendet, die hat andere Ursachen. Auch andere link-lokale Protokolle, wie mDNS (Bonjour, avahi) o.ä. zum Auffinden von Diensten im lokalen Netzwerk, funktionieren über eine VPN-Verbindung nicht ohne weitere Hilfsmittel.

Da könnte man ja glatt denken, daß Netbios doch durchgelassen wird.
Das ist auch tatsächlich so, betrifft aber nur die Unicast-Pakete, die direkt an das entsprechende Ziel gesendet werden.

Das wäre auch tatsächlich die notwendige Einstellung, wenn man über die VPN-Verbindung auf SMB-Server/-Clients zugreifen will, das habe ich vorher glatt noch vergessen zu erwähnen. Das war auch garantiert nicht das Problem beim Ping von frz, da das davon nicht beeinflußt wird.

Aber auch "dont_filter_netbios" ändert aber nichts an der Sichtbarkeit von entfernten Windows-Rechnern ... dafür braucht es das Layer2-Forwarding für Broadcasts oder einen WINS-Server.
 
Zuletzt bearbeitet:
betrifft aber nur die Unicast-Pakete, die direkt an das entsprechende Ziel gesendet werden.
Bedeutet das jetzt, wenn ich den Parameter auf "no" (ich hasse doppelte Verneinungen) stelle, dann geht auch folgende Freigabe nicht mehr?:

\\192.168.10.23\Freigabe
 
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.