[Frage] VPN zwischen 2 Fritzboxen tunneln, alle Daten über VPN.. möglich?

[PeterPawn]

Schau mal in die erzeugten VPN-Konfigurationen. Wenn ich das richtig sehe, hat der VPN-Assistent dahingehend einen Bug, daß er für Phase2 als lokale ID ebenfalls das entfernte Netz konfiguriert anstelle des lokalen.

Um den Unterschied deutlich zu sehen, exportiere einmal die Einstellungen mit LAN-Port und einmal ohne und vergleiche die dort enthaltenen vpn.cfg-Files.

Ich habe das gerade mal auf einer 7390 mit dem Assi getestet ... wenn das bei Deiner 7490 auch so sein sollte, mußt Du halt zum Texteditor greifen (und ggf. den Fehler an AVM melden). Das war mir vorher nie aufgefallen, da ich grundsätzlich den GUI-Assistenten eigentlich nicht verwende.

Wenn Du dann schon die Sicherungsdatei hast, kannst Du auch noch den "ipsecbridge"-Abschnitt der ar7.cfg (aus der 7490) und die VPN-Konfiguration für die Verbindung zwischen den FRITZ!Boxen anhängen. Die Arbeit des "Maskierens" der Werte, die mit "$$$$" beginnen, kannst Du Dir dabei zwar machen, genauso gut kannst Du sie Dir aber auch schenken, da es sicherer als in der schon verschlüsselten Form ohnehin nicht geht. Es würde also reichen, wenn Du "remotehostname" (und event. noch "name") ersetzt, die verwendeten LAN-Netze kennen wir ja ohnehin schon und Dein PSK ist - wie erwähnt - so sicher verschlüsselt, daß den ohne zusätzliche Angaben nicht mal AVM dechiffrieren kann. Die Konfigurationsdatei der 7390 wird nicht unbedingt benötigt, wenn sie bei beiden Varianten (mit und ohne LAN-Port-Zuweisung in der 7490) identisch ist und ohne Portreservierung klaglos funktioniert.

 

[superfun]

nur eine Frage, wie kann ich die VPN-Einstellungen aus der GUI in eine cfg exportieren oder reicht hier ein Fritzbox-Backup, welches die Daten enthält?

 

[PeterPawn]

Sicherungsdatei exportieren ... in der Textdatei findest Du dann die einzelnen Konfigurationsdateien. Alternative ist der Telnet-Zugriff ...

 

[superfun]

ich seh da in der export leider nicht durch, was da zum VPN gehört und was nicht, ich werde mal mit dem fernzugang versuchen je 2 configs zu basteln, nur wie füge ich dort den ausgewählten LAN-Anschluss ein? das kann man ja nicht angeben

 

[PeterPawn]

FRITZ!Fernzugang hilft da gar nichts, da Du dann den "ipsecbridge"-Abschnitt von Hand konfigurieren müßtest und der befindet sich - wie schon mal erwähnt - an vollkommen anderer Stelle als die VPN-Konfiguration und wird von "FRITZ!Fernzugang konfigurieren" auch nicht unterstützt (schon deshalb, weil das nur auf ausgewählten Modellen funktioniert).

Das mit "nicht durchsehen" ist nun mal keine Entschuldigung. Erstens ist das alles Klartext (das Stichwort "ipsecbridge" sucht Dir jeder Texteditor in so einer Datei) und zweitens wirst Du ja wohl in der Lage sein, nach dem Namen Deiner VPN-Verbindung in dieser Sicherungsdatei zu suchen. Der findet sich dann irgendwann auch innerhalb einer Datei "vpn.cfg" in dieser Sicherungsdatei. Beim prinzipiellen Verständnis des Aufbaus der Export-Datei helfen Dir viele Internet-Quellen, nur lesen mußt Du halt selbst.

Wenn Du tatsächlich mit diesen Grundlagen nicht klarkommen solltest, würde ich mich an Deiner Stelle erst gar nicht an den Versuch mit VPN und dediziertem Port wagen ...

PS: Oben habe ich es eigentlich schon ganz deutlich geschrieben: Stelle einmal eine VPN-Verbindung ohne LAN-Port-Reservierung ein und exportiere die Einstellungen der FRITZ!Box. Anschließend eine mit LAN-Port-Reservierung und wieder exportieren. Dann diese beiden Files vergleichen. Zeilen mit "$$$$"-Werten sind immer unterschiedlich bei zwei Exporten, alle anderen Unterschiede resultieren (die Uhrzeit des Exports ignorieren wir mal, die ist natürlich auch unterschiedlich) aus der Änderung der Einstellungen zwischen den beiden Exporten. Das ist ja nun nicht so schwer, oder?

 

[superfun]

habe jetzt mal gesucht, also bei der vpn.cfg mit aktiviertem Port ist die phase2localid IP 192.168.179.0
bei der vpn.cfg mit deaktiviertem Port, so wie die VPN Verbindung also ohne Probleme läuft, ist diese IP jedoch 192.168.180.0

ich denke mal, das es an diesem Wert liegt, oder? RemoteID ist beide male 192.168.179.0, was ja stimmt, da es die entfernte 7390 betrifft

sollte es also ausreichend sein, diesen Wert zu ändern und die editierte export-datei wiederherzustellen?

 

[PeterPawn]

Das ist genau die Einstellung, die ich meinte ... also ist der Fehler bei der 7490 auch vorhanden.

Das Editieren der vpn.cfg in der exportierten Datei ist nicht so einfach. Wenn Du es schaffst, eine Telnet-Session auf der 7490 zu starten, ist das Editieren der Datei direkt auf der FRITZ!Box (mit nvi) die bessere Lösung. Ansonsten kannst Du das natürlich auch extern editieren, dann brauchst Du aber ein Programm, was für den Import die richtige Prüfsumme in der Datei berechnet. Das ginge mit einem aktuellen FBEditor.

Wie auch immer Du diese vpn.cfg nun ändern willst, die abweichende "ipnet"-Angabe in "phase2localid" ist die Ursache des 0x1c-Fehlers beim Herstellen der VPN-Verbindung. Entstanden ist dieses Problem durch einen Bug im VPN-Assistenten der 7490.

 

[superfun]

neues Problem, ich bekomme auf der 7490 Telnet nicht aktiviert, habe es per Telefon als auch per Wählhilfe in der GUI versucht

 

[PeterPawn]

Firmware-Version?

Ich habe ähnliches vor kurzem schon mal hier irgendwo gelesen ... aber meines Wissens ist das selbst in der neuesten 7490-Labor-Version (die vom 01.04.) noch niemandem so direkt aufgefallen, daß sich der Telnet-Daemon nicht mehr (de)aktivieren ließe. Ich komme im Moment aber auch nicht dazu, das zu überprüfen ... aber es ist notiert und ich werde irgendwann in der nächsten Woche mal nachsehen.

Ausschließen würde ich es aber auch nicht, daß AVM nun tatsächlich auch den Telnet-Daemon aus der originalen Firmware entfernt.

Dabei schlagen dann zwei Herzen in meiner Brust ... einerseits finde ich es für die allgemeine Sicherheit des FRITZ!OS sogar begrüßenswert, andererseits werde auch ich alles daran setzen, einen neuen Weg der Aktivierung eines Kommandozeilenzugangs zu den DSL-Modellen zu finden (oder zumindest dabei zu helfen).

Bliebe noch die Möglichkeit, den Telnet-Daemon über das Flag in der "fx_conf" zu aktivieren (habe ich irgendwann hier im IPPF auch mal beschrieben). Das klappt aber natürlich auch nur dann, wenn tatsächlich aus dem "telefon"-Daemon nur die Behandlung der Tastencodes entfernt wurde und nicht auch noch der Start des Telnet-Daemons, der erfolgt ja bisher auch dort.

 

[superfun]

hmm.. dann wird es problematisch.. Telnet geht nicht und mit dem FBEditor bekomme ich es auch nicht hin, die geänderte expoert-Datei ist nach wie vor ungültig und wird nicht wiederhergestellt

FRITZ!OS 06.25-30219 PHONE

 

[PeterPawn]

Ok, also die neueste Labor-Version. Jetzt müßtest Du eigentlich testen, ob das Telnet-Problem an dieser Version liegt oder nicht ...

Den Hinweis auf das Telnet-Flag in der "fx_conf" hatten wir schon, wenn Du die Änderung an Text-Daten mit dem FBEditor nicht hinbekommst (auch hier wäre es wieder spannend, ob das an der Firmware-Version liegt oder nicht), wirst Du Dich mit dieser Änderung aber garantiert übernehmen und ob das am Ende von Erfolg gekrönt wäre, weiß ich auch nicht. Wenn AVM auch den Import geändert hat bei der 06.25, dann wäre das eine mögliche Erklärung. Ansonsten bliebe auch noch ein Fehler im Umgang mit dem FBEditor? Ich habe ja keine Ahnung, wie fit Du damit bist ...

Mal sehen, ob sich jemand auf meine Frage zum Telnet in der Labor-Version im entsprechenden Thread meldet ... zumindest wird dann wohl klarer werden, ob AVM da etwas ausgebaut hat oder ob Du einen Bedienfehler machst.

Im Moment kann und will ich das nicht selbst prüfen ... also ist bis zu einer Auskunft zur 06.25 hier erst einmal Schicht im Schacht für mich.

Solltest Du weiter suchen wollen, würde ich an Deiner Stelle mal einen Downgrade auf die 06.24 (oder sogar die 06.23) in Erwägung ziehen ... bei der 06.23 geht jedenfalls der Telnet-Daemon noch problemlos.

 

[superfun]

Problem gelöst, habe eine andere Version vom FBEditor versucht und es ging, also die 7330 hinter der 7490 bekommt nun eine IP von der 7390 (192.168.179.2), jedoch baut sie keine Internetverbindung auf, obwohl einmal die 7390 als DNS und die 8.8.8.8 (Google-DNS) eingetragen ist.. VoIP und Webseiten bekommen keine Antwort vom DNS..

Wo liegt der Fehler? Mehr als den DNS eintragen kann ich doch nicht, oder muss der DNS etwa wiederum die 7490 sein?

 

[PeterPawn]

Das kann ja nun verschiedene Ursachen haben ... für heute habe ich keine Lust mehr.

Woher weißt Du, daß es an der DNS-Antwort scheitert und nicht an irgendwas anderem? Kriegst Du denn auf der 7330 eine Telnet-Session hin und kannst da mit den Netzwerk-Diagnose-Kommandos (ping, nslookup, traceroute, usw.) noch etwas mehr an "Fleisch" zum aktuellen Problem sammeln? Wenn es nur an der Namensauflösung scheitert, müßte ja ein Zugriff mit Adresse funktionieren.

Auch ist "die 7330 hinter der 7490 bekommt nun eine IP von der 7390" schon wieder etwas dubios. Hast Du den DHCP-Server der 7390 auf die Range ab .2 eingestellt (AVM-Standard ist ab .20, deshalb staune ich) und das "bekommt" heißt, die Adresse wird vom DHCP-Server auf der 7390 bereitgestellt? Oder ist die Adresse statisch konfiguriert und es müßte "hat bekommen" heißen?

Die 7330 erbt natürlich wieder alle potentiellen Probleme eines kaskadierten Routers, da es dabei vollkommen egal ist, ob der Border-Router nun lokal oder hinter dem FRITZ!Box-VPN zu finden ist.

 

[superfun]

Also, dass es am DNS liegt habe ich erkannt, da bei der VoIP Registrierung es am DNS-Server scheitert (Log)..
Warum die 7330 die .2 erhalten hat und nicht die .20 wundert mich aber auch, da der DHCP auf Standardeinstellung läuft.

naja mir reicht heute erstmal, ich seh mir das morgen auf der 7330 mal mit Telnet an und Poster das hier.

 

[PeterPawn]

Auch hier fehlt die Information, von welchem Provider Du denn auf welchen Provider zugreifen willst. Je nach verwendeter Kombination könnte da eine DNS-Abfrage für einen SIP-Servernamen über die entfernte 7390 erfolgen, der nur im Netz des Providers für die 7490 gültig ist.

Also bleibt es bei der Diagnose mit Kommandozeilen-Tools ... es wäre schon merkwürdig (aber auch nicht ausgeschlossen, da kommt dann aber auch die FW-Version der 7390 mit ins Spiel und ein (potentieller) weiterer Bug in der Firmware - einen haben wir ja schon im Portfolio bei Deinem Problem), wenn an diesem LAN-Port keine DNS-Abfragen funktionieren würden, aber ICMP-Pakete übertragen werden. Daher erst einmal den Fehler genau eingrenzen und dann kann man weiter überlegen, was die möglichen Ursachen sein könnten. Alles andere ist wildes Raten mit viel Schreibarbeit ...

 

[superfun]

Ich versuche gerade per Telnet was zu erfahren, aber wie es aussieht liegt es wirklich am DNS oder gar Gateway..
egal ob ich z. B. ping facebook oder ping 173.252.120.6 eingebe, es erfolgt keine Ausgabe.
Bei ping 192.168.179.1 sind 2 von 4 pings gescheitert.
Ich vermute langsam, das die localid 192.168.179.0 an der Stelle der VPN.cfg richtig war??

 

[PeterPawn]

Ich vermute langsam, das die localid 192.168.179.0 an der Stelle der VPN.cfg richtig war??

Sicherlich ... deshalb klappt jetzt auch die VPN-Verbindung, nachdem Du diese Einstellung auf einen falschen Wert geändert hast.

Das ist alles weder Fisch noch Fleisch, was Du als Ergebnis von Tests hier anbietest. Ein "ping ohne Ausgabe" ist schon mal sehr unwahrscheinlich, da bei einem Paketverlust nach entsprechendem Timeout auch eine Ausgabe erfolgen müßte und sei es nur die Information, daß da etwas nicht funktioniert. Wenn Du schreibst, "sind 2 von 4 pings gescheitert", bezieht sich das dann auf einzelne ICMP-Pakete oder auf komplette "ping"-Kommandos und was heißt denn "gescheitert"? Keine Antwort, keine Route, usw. - da gibt es zig Ursachen und dazu passende Fehlermeldungen.

War die VPN-Verbindung beim Start des "ping"-Kommandos aktiv oder nicht? Wenn nicht, sind Paketverluste während des Aufbaus der VPN-Verbindung vollkommen normal.

Also bitte systematisch testen und die Ergebnisse so anschaulich und detailliert darstellen, daß man damit etwas anfangen kann. Auch ein traceroute zu irgendeiner Webpräsenz kann schon aufzeigen, ob da etwas mit dem Routing oder irgendwelchen Gateways nicht stimmt. Aber das ist am Ende Netzwerk-Basiswissen und hat mit der Eingangsfrage nur noch peripher zu tun. Wenn AVM keine weiteren Fehler in der Frmware hat, ist die 7330 nunmehr Bestandteil des Netzes an der 7390 und kann über diese Box ins Internet gehen.

Funktioniert das nicht, muß man den Fehler suchen und finden ... jetzt plötzlich die (erfolgreiche) Änderung an der vpn.cfg anzuzweifeln, ist da - in meinen Augen - wenig hilfreich oder zielführend.

Den Rest des Tages bin ich jetzt anderweitig beschäftigt. Solltest Du hier weiter machen wollen, lese ich das gerne später ... aber ich bin - angesichts der oben aufgezeigten Verständnisprobleme, die mich immer wieder plagen, wenn ich Deine Texte lese - eher geneigt festzustellen, daß ich Dir wohl nicht werde helfen können. Trotzdem viel Erfolg, ich drücke die Daumen ...

 

[superfun]

beigefügt mal ein Screenshot mehrerer Telnet-Sitzungen mit verschiedenen Tests und den Resultaten, die nicht wirklich viel sagen, da jetzt nicht mal mehr der ping zur 7390 funktioniert, obwohl VPN die ganze Zeit verbunden war und noch ist, einmal kommt eine Rückmeldung von der 7390, danach ist Funkstille.
beim traceroute sieht man auch deutlich, das die Anfrage zwar zur 7390 geht, aber diese nicht verlässt, oder irre ich mich da?

Problem könnte sein, dass die 7330 keine IP aus dem DHCP-Bereich erhält und damit ein grundlegender Fehler in der IP-Config entsteht, oder?

 

[superfun]

soo.. nun klappt alles und der LAN2 ist per VPN mit der 7330 verbunden, sollte so also auch mit der 7330 und der 7390 klappen.

wir hatten bei der IP-Vergabe für den ausgewählten LAN-Anschluss einen Fehler, bei Netz-Präfix muss das Netz der 2ten Box (7330) stehen, lediglich beim DNS muss der Eintrag der 1ten Box (7490) stehen, habe aber zur Sicherheit beide DNS eingetragen. Ein Test auf wieistmeineip.de zeigte dann den Erfolg, Internet funktioniert und IP der 7490 wurde beim surfen übermittelt

nicht wundern, hatte zum leichteren Überblick die IP-Adressen geändert, läuft aber mit den alten IPs (179 und 180er Netz) genauso

 

[superfun]

neues Problem..

VPN läuft, Telefonie aktiv und registriert.. ABER es wird bei ausgehenden Telefonaten kein Ton übertragen, Freizeichen ist aber hörbar UND bei eingehenden Telefonaten hört der Anrufer kein Freizeichen unter der gewählten Rufnummer.
Was kann da falsch laufen?

unternommene Lösungsversuche:
1. VPN an 7330 deaktiviert (Telefonie an 7330 funktioniert, wenn auch nur 5 sek wegen der UMTS-Sperre), angeschlossene 7390 zeigt die oben genannten Symptome bei der Telefonie
2. VPN an 7330 aktiviert, oben genannte Symptomatik
3. 7330 neu verbunden, ohne Erfolg
4. 7390 neu verbunden, ohne Erfolg
5. beide Boxen neugestartet, ohne Erfolg

Da die fehlerhafte Telefonie an der 7390 auftritt sowohl mit aktiven als auch deaktivierten VPN zu entfernten 7490, schließe ich den VPN mal aus - Funktion wurde vor einigen Tagen erst mehrfach in Verbindung 7330 <-> 7490 über UMTS erfolgreich getestet!
was könnte an der 7390 da noch eine mögliche Fehlerursache sein?