bei localid/remoteid "user_fqdn" geht es um die eigene Identität bzw. fremde Identität für IKE-Phase 1
Hast Du schon mal
Code:
key_id = "Username"EDIT: PeterPawn war schneller und umfangreicher mit Antwort zu "user_fqdn".
7490 7.01 / VPN Probleme
- Ersteller sulihari
- Erstellt am
Hast Du schon mal
EDIT: PeterPawn war schneller und umfangreicher mit Antwort zu "user_fqdn".
Vielen Dank für die vielen Antworten. Sorry wegen der fehlenden Formatierung. Ich habe soeben nochmal den Punkt localid/remoteid "user_fqdn" vs. key_id = "Username" getestet. Mit einer 7490 mit 6.93 als Gegenstelle wird problemlos VPN aufgebaut, mit beiden Varianten und sowohl unter 7.01 als auch unter 6.93. Die Drayteks (verschiedene Modelle) werden ungeachtet dessen nicht verbunden. Mein aktuelles Fazit ist, es kommen wohl mehrere Punkte zusammen. Einerseits scheint der Import nicht wie bisher gewohnt zu arbeiten, und dann scheint sich bei der Aushandlung der Verbindung was geändert zu haben.
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Mir kommt es eben genau darauf an, den Namen in der VPN-Übersicht unabhängig vom Remote DNS zu haben - bei den kryptischen MyFritz-IDs weiss ich z.B. nie, welche FB es nun ist... Ich habe also jetzt eine CFG erstellt und in die FB7580 importiert, in der nur FQDN-IDs verwendet werden, die ich so auch in die be.IP eintragen kann:
Code:
:
name = "FB7580A25-beIPFe4-Imp2";
:
localid {
fqdn = "FB7580.A25.myvpn";
}
remoteid {
fqdn = "beIP.Fe4.myvpn";
}Gibt es irgendwo eine Beschreibung, wie die Einträge in der vpn.cfg aussehen können/müssen? Ich habe mich bisher via trial and error über die von der WIN-App "FRITZ!Fernzugang einrichten" erstellten Dateien bzw. die Einträge in den Settings bzw. Supportdaten der Lösung angenähert.
Wie kann man die /var/flash/vpn.cfg direkt (ohne Supportdaten) abziehen? Zugang via Telnet und SSH verweigert meine FB7580...
Könntest Du bitte Deine Local / Remote HW angeben, ich blicke grad nicht durch, wer bei Dir mit wem verbunden ist, danke.
-hg
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Der ist sowohl vom "remotehostname" als auch von der P1-ID unabhängig ... und steht einfach in "name". Allerdings muß(te) der eindeutig sein und ein Import einer weiteren Konfiguration dieses Namens ersetzt die erste - daß AVM hier die "Internet-Adresse" bei LAN-LAN-Kopplung gleich noch einmal verwurstet, macht "für den Laien" das Auseinanderhalten derselben Werte mit unterschiedlichen Bedeutungen nur noch schwerer.
Wie man zu einem Shell-Zugang kommt, ist auch oft genug thematisiert - selbst wenn sich das für eine 7490 und eine 7580 etwas unterschiedlich gestaltet. Ohne Änderung der Firmware muß man eben wirklich auf die Support-Daten (da hat man aber auch gleich noch das VPN-Log von AVM und das hat man dort ja (sicherlich nicht ohne Absicht bzw. Notwendigkeit) zur 07.0x massiv erweitert) oder die Export-Datei zurückgreifen ... es kommt ja auch immer darauf an, was man mit dieser Datei eigentlich anfangen will.
In den Support-Daten sollten die IDs für P1 durch "SECRET" ersetzt und damit nicht lesbar (und damit auch nicht kontrollierbar) sein ... in der Export-Datei könnte man das (genauso wie in einer Shell) auch einfach dekodieren lassen für die Anzeige im Klartext (und das ist dann die einzige, wirklich wirksame Kontrolle, was dort steht).
@drummer1154 7490 mit 6.93 und 7.01 = lokale Box verbindet sich per VPN erfolgreich mit 7490 6.93 remote.
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Alles klar, danke. Ich werde die Remote 7490 6.93 erst mal nicht updaten.
Ja, danke, habe ich auch so gesehen und die .cfg entsprechend benannt.
OK, verstanden, FW-Mod kommt hier nicht in Frage, der Umweg über Support-Daten ist akzeptabel.
Aha - wie geht das?
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Hmm ... ich würde zunächst mal die Daten exportieren (im GUI unter "System / Sicherung / Sichern") und die gespeicherte Datei dann dekodieren lassen.
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Na mit dem Kennwort, welches man beim Export angegeben hat ... ist doch eigentlich alles beschrieben und ich hatte etwas die Hoffnung, daß mein (offensichtlicher?) Versuch, die Frage absichtlich mißzuverstehen, für Dich der Anlaß zu einer eigenen Suche wäre. Das Internet ist groß ... trotzdem sind die Antworten auf die Frage, wie man eine Export-Datei einer FRITZ!Box entschlüsseln kann, durchaus noch überschaubar (nach meiner Erfahrung).
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Aha - sorry - wo? github? Kann leider nicht immer überall nach Allem suchen - das ist bei mehreren parallelen Baustellen (be.IP, FB, Kassen, WLAN-APs usw. und Netz-HW-Ausbau) zeitlich nicht zu schaffen
- v.a. wenn man die Infrastruktur nicht von Anfang an selbst gestaltet hat, sondern mit dem (teilweise leider Schrott) arbeiten muss, was sog. "Profis" für viel Geld abgeliefert haben und was die Telekom den Kunden als "Verbesserung" verkauft hat...
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Dann laß uns das einfach mal gemeinsam aufdröseln und zwar auf dem unwahrscheinlichsten Weg ... denn der wahrscheinlichste wäre vermutlich der Einsatz einer Suchmaschine für diese Zwecke.
Ist Dir mal der Link in meiner Signatur aufgefallen?
Klickt man da mit der "seriellen Zeigereinheit" drauf (was das ist, weiß vielleicht auch wieder das Internet und heutzutage ist das "serielle Interface" meist auch schon eher eine USB- oder - schon älter - PS/2-Schnittstelle), landet man bei einer Ansicht meiner Repositories und eines davon trägt den Namen "decoder" und den Titel
Und richtig ... in diesem Repository trifft man dann in der "Beschreibung" (die Datei "README.md" wird netterweise von GitHub auch noch direkt angezeigt als "Eingangsseite") auch auf die Feststellung, daß es einen IPPF-Thread gibt, der sich mit diesem Thema befaßt und der Link dorthin steht auch noch am Ende dieser Beschreibung.
Das wäre jetzt jedenfalls ein Weg, den man nehmen könnte (allerdings nicht der allerklügste, es sei denn, man will wirklich wissen, wie das Ganze funktioniert und es nicht nur benutzen) ... Suchmaschinen sind ja aber eher etwas für Weicheier.
Oder für "die Anderen", die einfach (ganz im Gegensatz zu Dir) zuviel freie Zeit haben und in dieser noch den Leuten helfen wollen, die tatsächlich neue Fragen haben und nicht einfach nur vom vielen Fragenstellen schon so erschöpft sind, daß sie gar nicht mehr zur Suche kommen.
Ist Dir mal der Link in meiner Signatur aufgefallen?
Klickt man da mit der "seriellen Zeigereinheit" drauf (was das ist, weiß vielleicht auch wieder das Internet und heutzutage ist das "serielle Interface" meist auch schon eher eine USB- oder - schon älter - PS/2-Schnittstelle), landet man bei einer Ansicht meiner Repositories und eines davon trägt den Namen "decoder" und den Titel
Das könnte man ja schon mal als "starken Hinweis" auffassen, daß eine Fortsetzung der Suche in dieser Richtung sich lohnen dürfte.
Und richtig ... in diesem Repository trifft man dann in der "Beschreibung" (die Datei "README.md" wird netterweise von GitHub auch noch direkt angezeigt als "Eingangsseite") auch auf die Feststellung, daß es einen IPPF-Thread gibt, der sich mit diesem Thema befaßt und der Link dorthin steht auch noch am Ende dieser Beschreibung.
Das wäre jetzt jedenfalls ein Weg, den man nehmen könnte (allerdings nicht der allerklügste, es sei denn, man will wirklich wissen, wie das Ganze funktioniert und es nicht nur benutzen) ... Suchmaschinen sind ja aber eher etwas für Weicheier.
Oder für "die Anderen", die einfach (ganz im Gegensatz zu Dir) zuviel freie Zeit haben und in dieser noch den Leuten helfen wollen, die tatsächlich neue Fragen haben und nicht einfach nur vom vielen Fragenstellen schon so erschöpft sind, daß sie gar nicht mehr zur Suche kommen.
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Hallo PeterPawn,
ich gebe gern zu, dass ich schnelle Resultate erst mal besser finde als sich tagelang in ein neues Thema reinwühlen zu müssen, insbesondere da ich unter (nur zum Teil von mir selbst verschuldeten) Zeitdruck stehe, weil die Telekom nächste Woche den ISDN-Anschluss abschaltet, über den das Fax und die Einspeisezählerabfrage der Bäckerei meines Schulfreunds laufen. Ich habe als Ersatz für die derzeit als MGW für 1 S0 laufende FB7390 eine Bintec be.IP gewählt, die 2 S0 für die Telefonanlage hat und von der "Papierlage" her (Manual, Technische Daten, Releasenotes) einen sehr professionellen Eindruck macht (inzwischen weiss ich auch, dass sie identisch ist zur "Digitalisierungsbox Standard" von der Telekom, von der ich bisher nichts wusste). Bei der Konfiguration stellte sich dann leider heraus, dass sie sehr zeitraubend ist und man Daten (MAC- und IP-Adressen) teilweise mehrfach eingeben muss. Die Konfig wird - entgegen der Angabe im Manual und der eingebauten Online-Hilfe) nur verschlüsselt abgespeichert. Tagelanges Suchen mit den üblichen Tools hat mich leider noch nicht zu einer Entschlüsselung geführt - worüber Du vermutlich mit Deiner Expertise nur lachen wirst. Mir ist allerdings zunächst nichts anderes übriggeblieben, als die in der GUI angezeigten Daten per CopyPaste in eine Excelliste zu schreiben, um die Übersicht behalten zu können.
Nun zum eigentlichen Problem VPN: Da für die Verbindung zu 2 Kassen in einer Filiale (dort FB7490) bisher ein VPN-Tunnel mittels MyFritz eingerichtet war (nicht von mir), musste ich herausfinden, wie die FB7490 mit der be.IP verbunden werden kann. Dazu habe ich ein YouTube-Video von Anfang 2018 gefunden. Mit der dort beschriebenen Anleitung hat es aber leider nicht funktioniert. Ich habe dann im Routerforum eine Anleitung gefunden; die be.IP-Konfig ist wie im Video und bei der FB-Konfiguration war mir nicht klar, dass es sich um eine VPN.cfg handelt, die man in die FB importieren kann (weil ich halt zur Verbindung 2er FBs - ja genau, nur als User, ohne mich mit der RFC zu beschäftigen - immer nur den Weg via GUI über MyFritz bzw. dann über DDNSS gegangen war und mit dem Punkt "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren" nichts anfangen konnte, da ich das Tool "Fernzugang einrichten" (das ich für ziemlichen Mist halte, läuft nur mit Admin-Rechten, und die VPN.cfg kann man genausogut auch mit einem Texteditor erstellen) noch nicht gekannt habe). Wie man die VPN.cfg aus den (mit Passwort gespeicherten) Settings extrahieren kann, war mir klar, nicht jedoch, wofür man überhaupt ein Passwort braucht, wenn doch die Daten alle im Klartext gespeichert werden. Danke daher für Deine ausführlichen Erläuterungen hier im Forum (ganz so blöd wie Du denkst bin ich allerdings nicht, ein einfaches "JA" auf meine Nachfrage
Ich habe in der VPN.cfg anstelle von
jetzt
stehen und konnte es auch in die FB7580 importieren und rücklesen; be.IP und Test stehen noch aus. Warum OS07.x das E-Mail-Format nicht mehr unterstützt, ist mir allerdings schleierhaft - m.E. dürften vorher so problemlos konfigurierte VPNs zu nicht-AVM-Geräten dann urplötzlich nicht mehr laufen, ohne dass davon etwas in der RelNote stünde...
Viele Grüsse und nichts für Ungut!!!
-hg
ich gebe gern zu, dass ich schnelle Resultate erst mal besser finde als sich tagelang in ein neues Thema reinwühlen zu müssen, insbesondere da ich unter (nur zum Teil von mir selbst verschuldeten) Zeitdruck stehe, weil die Telekom nächste Woche den ISDN-Anschluss abschaltet, über den das Fax und die Einspeisezählerabfrage der Bäckerei meines Schulfreunds laufen. Ich habe als Ersatz für die derzeit als MGW für 1 S0 laufende FB7390 eine Bintec be.IP gewählt, die 2 S0 für die Telefonanlage hat und von der "Papierlage" her (Manual, Technische Daten, Releasenotes) einen sehr professionellen Eindruck macht (inzwischen weiss ich auch, dass sie identisch ist zur "Digitalisierungsbox Standard" von der Telekom, von der ich bisher nichts wusste). Bei der Konfiguration stellte sich dann leider heraus, dass sie sehr zeitraubend ist und man Daten (MAC- und IP-Adressen) teilweise mehrfach eingeben muss. Die Konfig wird - entgegen der Angabe im Manual und der eingebauten Online-Hilfe) nur verschlüsselt abgespeichert. Tagelanges Suchen mit den üblichen Tools hat mich leider noch nicht zu einer Entschlüsselung geführt - worüber Du vermutlich mit Deiner Expertise nur lachen wirst. Mir ist allerdings zunächst nichts anderes übriggeblieben, als die in der GUI angezeigten Daten per CopyPaste in eine Excelliste zu schreiben, um die Übersicht behalten zu können.
Nun zum eigentlichen Problem VPN: Da für die Verbindung zu 2 Kassen in einer Filiale (dort FB7490) bisher ein VPN-Tunnel mittels MyFritz eingerichtet war (nicht von mir), musste ich herausfinden, wie die FB7490 mit der be.IP verbunden werden kann. Dazu habe ich ein YouTube-Video von Anfang 2018 gefunden. Mit der dort beschriebenen Anleitung hat es aber leider nicht funktioniert. Ich habe dann im Routerforum eine Anleitung gefunden; die be.IP-Konfig ist wie im Video und bei der FB-Konfiguration war mir nicht klar, dass es sich um eine VPN.cfg handelt, die man in die FB importieren kann (weil ich halt zur Verbindung 2er FBs - ja genau, nur als User, ohne mich mit der RFC zu beschäftigen - immer nur den Weg via GUI über MyFritz bzw. dann über DDNSS gegangen war und mit dem Punkt "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren" nichts anfangen konnte, da ich das Tool "Fernzugang einrichten" (das ich für ziemlichen Mist halte, läuft nur mit Admin-Rechten, und die VPN.cfg kann man genausogut auch mit einem Texteditor erstellen) noch nicht gekannt habe). Wie man die VPN.cfg aus den (mit Passwort gespeicherten) Settings extrahieren kann, war mir klar, nicht jedoch, wofür man überhaupt ein Passwort braucht, wenn doch die Daten alle im Klartext gespeichert werden. Danke daher für Deine ausführlichen Erläuterungen hier im Forum (ganz so blöd wie Du denkst bin ich allerdings nicht, ein einfaches "JA" auf meine Nachfrage
hätte eigentlich genügt).
Ich habe in der VPN.cfg anstelle von
Code:
user_fqdn = "[email protected]";
Code:
fqdn = "FB7580.A25.myvpn";Viele Grüsse und nichts für Ungut!!!
-hg
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Die Frage ist halt, ob AVM selbst beim Konfigurieren einer Verbindung (entweder über das Windows-Programm oder das GUI im FRITZ!OS) jemals etwas anderes als "keyid" und "fqdn" verwendet hat - ich weiß es schlicht nicht. Solange das aber nicht der Fall ist, kann sich eigentlich niemand "beklagen", wenn zuvor undokumentierte Features auf einmal nicht mehr funktionieren. Es gibt auch noch Reste vom alten AVM-Access-Server in den VPN-Konfigurationen (die "use_cert"-Geschichten) - auch die sind nirgendwo so dokumentiert, daß sie "gesicherte Funktionalität" sind und wer es sich zutraut, sich abseits der "üblichen Pfade" bei solchen Konfigurationen zu bewegen, der darf sich eben auch nicht vom ersten Problem ins Bockshorn jagen lassen und gleich wieder nach der nächsten Alternative suchen.
----------------------------------------------------------------------------------------------------------------------------------------
Ich kenne solche "Kannst Du nicht mal schnell ..., Du kennst Dich doch da aus."-Gefallen nur zu gut ... aber wenn man da zustimmt und sich darauf einläßt, muß man sich eben auch reinhängen (und die Ressourcen dafür - in erster Linie ja die eigene Zeit - frei haben) - daher nehme ich solche "Versuche" auch nicht wirklich krumm. Aber das liest man eben auch so oft, daß man es schon "mitsingen" kann - und so richtig nachvollziehbar ist es halt auch irgendwie nicht, warum Du bei einer bisher funktionierenden VPN-Verbindung zwischen 7390 und 7490 hingehst und beide Seiten der VPN-Verbindung ändern willst; denn die bisher vorhandene Verbindung zwischen diesen beiden Boxen nutzte mit ziemlicher Sicherheit eben keine VPN-Verbindung, bei der eine Seite per "user_fqdn" identifiziert wurde oder schon diese Verbindung wäre "von Hand" konfiguriert gewesen.
----------------------------------------------------------------------------------------------------------------------------------------
Auch kommt man halt nicht darum herum, sich ab und an mal ein paar Grundlagen anzulesen ... hier gilt das vielleicht mehr für IPSec-VPN mit IKEv1 als für die Boxen selbst. Ich verstehe nämlich gar nicht so richtig, wieso Du hier ein "Lehrvideo" für die Konfiguration der Digitalisierungbox herangezogen hast (so verstehe ich den letzten Text oben, daß Du das bei bei routerforum.de verlinkte Video "nachgespielt" hast - und das unabhängig von der (sehr richtigen) Feststellung im zweiten Beitrag dort, daß das alles nicht wirklich immer "nach Rezept" funktionieren würde), bei dem es sich gar nicht um eine LAN-LAN-Kopplung handelt ... denn dort agiert die FRITZ!Box ja quasi als VPN-Client, so wie es z.B. ein Smartphone oder ein Tablet oder ein PC mit dem Shrewsoft-VPN-Client wäre.
Ich mag mich irren, aber ich vermute hier (einfach aus dem Verlauf des Threads geschlossen und aus der Lektüre der Beiträge im anderen Board), daß die Boxen eigentlich sogar miteinander klarkommen (das Protokoll weiter vorne, welches inzwischen in einem Code-Block steht, sagt nämlich eigentlich genau das auch aus - für 54 Minuten (bzw. eine Stunde) existierte ein Tunnel zwischen den Peers) und daß hier nur der falsche Modus bzw. die falsche Konfiguration gewählt wurde und dann aus der Tatsache, daß die jeweiligen Netzwerk-Clients über diese VPN-Verbindung nicht "miteinander können", gleich die Schlußfolgerung erwächst, das VPN an sich würde nicht funktionieren.
Ich würde mich hier erst noch einmal "settlen", die notwendigen Zugriffe zwischen den Standorten systematisch erfassen und dann darüber nachdenken, wie man das am besten mit einer VPN-Verbindung lösen kann. Denn der "Modus" so einer Verbindung spielt auch eine Rolle, wenn es darum geht, welche Zugriffe von welcher Seite erfolgreich sein können und welche nicht - und auch eine FRITZ!Box könnte nur einen dedizierten lokalen Port - quasi als "Verlängerung" des LAN vom anderen Standort - per VPN mit einem Peer(-Netz) verbinden.
----------------------------------------------------------------------------------------------------------------------------------------
Zumal der "Durchblick" durch die geplante Konfiguration und deren Probleme jetzt auch immer komplizierter wird ... erst ist es eine FB7580 mit 07.01, dann eine 7490 mit 06.93, die "gegen" eine Digitalisierungsbox oder eine 7390 arbeiten sollen. Das hast Du zwar im Routerforum ganz nett versucht zu beschreiben, aber hier ist von der "Entwicklung", die mit zwei ISDN-Anschlüssen begann und bei zwei All-IP-Anschlüssen endet, nichts zu lesen. Dafür steht im Routerforum dann wieder, das VPN würde bereits funktionieren ... ich verstehe (in Maßen) ja auch, wenn man verzweifelt ist und hektisch, weil das alles schnell, schnell gehen muß - aber dabei vergißt man zu häufig die Hälfte der eigenen Beschreibungen bzw. schreibt Sachen, die keinen rechten Sinn ergeben wollen (siehe die Frage, warum Du auf der be.IP-Seite ein Video heranziehen willst für die Konfiguration, wo offensichtlich eine Einwahlverbindung konfiguriert wird, wenn die FRITZ!Box in diesem Video als "Mit einem Firmennetzwerk verbinden" konfiguriert werden soll).
Wobei man sich unwillkürlich auch die Frage stellt, warum es in einer Woche schon "zappenduster" wird - das ist ein Verhalten seitens der Telekom, wie ich es eigentlich eher nicht kenne. Üblicherweise hat man doch um die drei Monate Zeit, sich auf die geänderte Situation vorzubereiten - warum gibt ihm die Telekom denn hier nur so wenig Zeit für den Umstieg?
----------------------------------------------------------------------------------------------------------------------------------------
Ich kenne solche "Kannst Du nicht mal schnell ..., Du kennst Dich doch da aus."-Gefallen nur zu gut ... aber wenn man da zustimmt und sich darauf einläßt, muß man sich eben auch reinhängen (und die Ressourcen dafür - in erster Linie ja die eigene Zeit - frei haben) - daher nehme ich solche "Versuche" auch nicht wirklich krumm. Aber das liest man eben auch so oft, daß man es schon "mitsingen" kann - und so richtig nachvollziehbar ist es halt auch irgendwie nicht, warum Du bei einer bisher funktionierenden VPN-Verbindung zwischen 7390 und 7490 hingehst und beide Seiten der VPN-Verbindung ändern willst; denn die bisher vorhandene Verbindung zwischen diesen beiden Boxen nutzte mit ziemlicher Sicherheit eben keine VPN-Verbindung, bei der eine Seite per "user_fqdn" identifiziert wurde oder schon diese Verbindung wäre "von Hand" konfiguriert gewesen.
----------------------------------------------------------------------------------------------------------------------------------------
Auch kommt man halt nicht darum herum, sich ab und an mal ein paar Grundlagen anzulesen ... hier gilt das vielleicht mehr für IPSec-VPN mit IKEv1 als für die Boxen selbst. Ich verstehe nämlich gar nicht so richtig, wieso Du hier ein "Lehrvideo" für die Konfiguration der Digitalisierungbox herangezogen hast (so verstehe ich den letzten Text oben, daß Du das bei bei routerforum.de verlinkte Video "nachgespielt" hast - und das unabhängig von der (sehr richtigen) Feststellung im zweiten Beitrag dort, daß das alles nicht wirklich immer "nach Rezept" funktionieren würde), bei dem es sich gar nicht um eine LAN-LAN-Kopplung handelt ... denn dort agiert die FRITZ!Box ja quasi als VPN-Client, so wie es z.B. ein Smartphone oder ein Tablet oder ein PC mit dem Shrewsoft-VPN-Client wäre.
Ich mag mich irren, aber ich vermute hier (einfach aus dem Verlauf des Threads geschlossen und aus der Lektüre der Beiträge im anderen Board), daß die Boxen eigentlich sogar miteinander klarkommen (das Protokoll weiter vorne, welches inzwischen in einem Code-Block steht, sagt nämlich eigentlich genau das auch aus - für 54 Minuten (bzw. eine Stunde) existierte ein Tunnel zwischen den Peers) und daß hier nur der falsche Modus bzw. die falsche Konfiguration gewählt wurde und dann aus der Tatsache, daß die jeweiligen Netzwerk-Clients über diese VPN-Verbindung nicht "miteinander können", gleich die Schlußfolgerung erwächst, das VPN an sich würde nicht funktionieren.
Ich würde mich hier erst noch einmal "settlen", die notwendigen Zugriffe zwischen den Standorten systematisch erfassen und dann darüber nachdenken, wie man das am besten mit einer VPN-Verbindung lösen kann. Denn der "Modus" so einer Verbindung spielt auch eine Rolle, wenn es darum geht, welche Zugriffe von welcher Seite erfolgreich sein können und welche nicht - und auch eine FRITZ!Box könnte nur einen dedizierten lokalen Port - quasi als "Verlängerung" des LAN vom anderen Standort - per VPN mit einem Peer(-Netz) verbinden.
----------------------------------------------------------------------------------------------------------------------------------------
Zumal der "Durchblick" durch die geplante Konfiguration und deren Probleme jetzt auch immer komplizierter wird ... erst ist es eine FB7580 mit 07.01, dann eine 7490 mit 06.93, die "gegen" eine Digitalisierungsbox oder eine 7390 arbeiten sollen. Das hast Du zwar im Routerforum ganz nett versucht zu beschreiben, aber hier ist von der "Entwicklung", die mit zwei ISDN-Anschlüssen begann und bei zwei All-IP-Anschlüssen endet, nichts zu lesen. Dafür steht im Routerforum dann wieder, das VPN würde bereits funktionieren ... ich verstehe (in Maßen) ja auch, wenn man verzweifelt ist und hektisch, weil das alles schnell, schnell gehen muß - aber dabei vergißt man zu häufig die Hälfte der eigenen Beschreibungen bzw. schreibt Sachen, die keinen rechten Sinn ergeben wollen (siehe die Frage, warum Du auf der be.IP-Seite ein Video heranziehen willst für die Konfiguration, wo offensichtlich eine Einwahlverbindung konfiguriert wird, wenn die FRITZ!Box in diesem Video als "Mit einem Firmennetzwerk verbinden" konfiguriert werden soll).
Wobei man sich unwillkürlich auch die Frage stellt, warum es in einer Woche schon "zappenduster" wird - das ist ein Verhalten seitens der Telekom, wie ich es eigentlich eher nicht kenne. Üblicherweise hat man doch um die drei Monate Zeit, sich auf die geänderte Situation vorzubereiten - warum gibt ihm die Telekom denn hier nur so wenig Zeit für den Umstieg?
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Nochmal zum HW-Setup (ISDN lasse ich weg, weil nur VPN Probleme macht): Bisher:
Alle 3 VPNs gehen via MyFritz, VPN1 wurde eingerichtet vom Kassenfachbetrieb. Mein Versuch, VPN2 und 3 zusätzlich einzurichten war zunächst fehlgeschlagen, weil die FBs nur eine MyFritz-User-Anmeldung zulassen - alles unnötiger Zeitverbrauch, bis man das herausfindet. Ich habe dann VPN1 auf meinen MyFritz-User umgestellt und VPN2 und 3 neu eingerichtet => funktioniert.
Wegen der All-IP-Zwangsumstellung und der Anforderung, 2 S0-Schnittstellen für die Hicom118 an einem DSL-Anschluss zur Verfügung zu haben, sowie 3 WLAN-APs einzubinden, muss die FB7390 ersetzt werden, die Wahl fiel auf be.IP. Da die natürlich kein MyFritz kennt, war als nächstes ein passender DynDns-Provider zu suchen - auch keine Task für wenige Stunden. Die Wahl fiel auf ddnss.de, eingerichtet in den 3 FBs und in der be.IP => funktioniert.
Dann die Einrichtung VPN zwischen FB und be.IP - YouTube "Digitalisierungsbox Tutorial - Site-to-Site VPN zwischen Fritzbox und Digitalisierungsbox" gefunden - als Szenario wird mehrfach explizit "Lan zu LAN-Verbindung, also Site-to-Site" genannt. Nach der Einrichtung in der "Digitalisierungsbox" (mit genau diesem Szenario) wird in der FB dann mit "Diese FRITZ!Box mit einem Firmen-VPN verbinden" gearbeitet, was offenbar aber zur Einwahl eines einzelnen Users in ein Firmennetz gedacht ist und daher mit ID_USER_FQDN arbeitet - wusste ich zu diesem Zeitpunkt noch nicht. Eine LAN-LAN-VPN-Verbindung mit einem nicht-AVM-Produkt wird in der FB-GUI offenbar nicht unterstützt und funktioniert nur via "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren" - habe ich bisher nirgends gelesen. Erst die weitere Suche nach fehlgeschlagenen Tests führte zu der Anleitung im Routerforum, die aber für die FB sowohl bei localid als auch bei remoteid mit ID_USER_FQDN arbeitet, was von der FB7490 mit OS06.93 offenbar noch akzeptiert wird und zu einem funktionsfähigen VPN-Tunnel mit der be.IP führt, wenn man bei der auch die identischen Parameter einstellt. Bei meiner FB7580 hatte ich am 09.09.2018 die 07.00-FW installiert, was dazu führte, dass ich keine VPN.cfg importieren konnte (das blöde Tastendrücken bei jedem Datenexport hatte ich schon lange abgestellt). Also wieder recherchieren - die 07.01 wurde nicht in der GUI angezeigt - und neue FW auf FB7580 bringen, alles zeitaufwendig, weil ich den Verlust der Eventlogs durch Abzug der Supportdaten vermeide. Dann VPN.cfg importieren - nachdem es in der FB7490 zum funktionierenden VPN geführt hat, habe ich es versäumt, die aktuelle VPN.cfg zurückzulesen. Der Test ging schief, ist auch kein Wunder, wenn auf der einen Seite ID_FQDN versandt wird und die andere Seite ID_USER_FQDN erwartet.
Zu der Erkenntnis
Ich habe jetzt also für meine FB7580 und für die Filial-FB7490 je ein neues VPN.cfg erstellt mit ID_FQDN (siehe #23) und die Werte in der be.IP darauf umgestellt. Test heute Abend.
Zum Thema "Suche im Internet": Ich bin - wie gesagt - zunächst auf das Video und dann auf das Routerforum gekommen (und dort dokumentiert, dass es so, wie es dort beschrieben ist, nicht funktioniert); im IPPF habe ich nichts passendes gefunden und erst als ich wegen des fehlschlagenden VPN.cfg-Imports weiter gesucht habe, bin ich auf den aktuellen Thread gestossen, in dem ich - zunächst - nur dokumentieren wollte, dass ich Probleme auch mit der OS07.01 habe. Beiträge in 2 Foren synchron korrekt zu halten ist m.E. fast unmöglich, weshalb ich jetzt nur noch hier ausführlich poste und im Routerforum hierher verlinke, wenn denn alles funktioniert.
Und nein, die Telekom hat uns nicht nur 3 Wochen Zeit gegeben. Wie die HW-Lösung aussehen wird, war relativ bald klar. Inhouse musste ein Cat-Kabel vom HVT ins Büro verlegt werden, da die FB bisher im Büro stationiert ist und ein S0 über die existierende Fernmeldeverkabelung realisierbar war (aber nicht 2). Als WLAN-APs wollte ich ürsprünglich die neuen Bintec W2022ac-ext einsetzen, deren Lieferbarkeit sich aber von Monat zu Monat verzögerte, sodass ich jetzt W2003ac-ext einsetze, was den Beschaffungsprozess unnötig verzögert hat. Aufgrund weiterer Umstände (leider hat sich meine Frau auf dem Nachhauseweg von der Arbeit einen Mittelfussknochen gebrochen und war 6 Wochen ausser Gefecht mit entsprechenden Auswirkungen auf meine (häusliche) Arbeitsbelastung) und der Tatsache, dass die Telekom den ISDN-Anschluss nicht wie angekündigt zu Ende November, sondern bereits zu Ende September gekündigt hat, hat zu dem besagten Zeitdruck geführt. Die Telekom agiert allerdings manchmal extrem unkooperativ - bei der Umstellung des Haupt-ISDN-Anschlusses im März 2017 hat man der Bäckerei vor der Beauftragung gesagt, "dass sich nichts ändert", weshalb ich über die Umstellung nicht informiert wurde - da war dann die Not gross, als am Umstellungstag kein Telefon mehr ging, gelöst durch provisorische "fliegende" Verlegung eines S0-Kabels vom Büro zum HVT...
Morgen habe ich ein Treffen mit dem Spezialisten vom Kassenfachbetrieb zwecks Sicherstellung der Datenverbindung für die Kassen - hoffentlich erlebe ich da nicht weitere böse Überraschungen - konkrete technische Angaben waren von diesem Betrieb bis jetzt nicht zu erhalten.
Cheers
-hg
Code:
Bäckerei FB7390 - Internet - FB7490 Filiale
- FB7580 bei mir zuhause zwecks Fernadministration
VPN1: FB7390 - FB7490 Datenaustausch Vectron Kassen untereinander und mit PC-SW "Commander"
VPN2: FB7390 - FB7580 Fernadministration
VPN3: FB7490 - FB7580 FernadministrationWegen der All-IP-Zwangsumstellung und der Anforderung, 2 S0-Schnittstellen für die Hicom118 an einem DSL-Anschluss zur Verfügung zu haben, sowie 3 WLAN-APs einzubinden, muss die FB7390 ersetzt werden, die Wahl fiel auf be.IP. Da die natürlich kein MyFritz kennt, war als nächstes ein passender DynDns-Provider zu suchen - auch keine Task für wenige Stunden. Die Wahl fiel auf ddnss.de, eingerichtet in den 3 FBs und in der be.IP => funktioniert.
Dann die Einrichtung VPN zwischen FB und be.IP - YouTube "Digitalisierungsbox Tutorial - Site-to-Site VPN zwischen Fritzbox und Digitalisierungsbox" gefunden - als Szenario wird mehrfach explizit "Lan zu LAN-Verbindung, also Site-to-Site" genannt. Nach der Einrichtung in der "Digitalisierungsbox" (mit genau diesem Szenario) wird in der FB dann mit "Diese FRITZ!Box mit einem Firmen-VPN verbinden" gearbeitet, was offenbar aber zur Einwahl eines einzelnen Users in ein Firmennetz gedacht ist und daher mit ID_USER_FQDN arbeitet - wusste ich zu diesem Zeitpunkt noch nicht. Eine LAN-LAN-VPN-Verbindung mit einem nicht-AVM-Produkt wird in der FB-GUI offenbar nicht unterstützt und funktioniert nur via "Eine VPN-Konfiguration aus einer vorhandenen VPN-Einstellungsdatei importieren" - habe ich bisher nirgends gelesen. Erst die weitere Suche nach fehlgeschlagenen Tests führte zu der Anleitung im Routerforum, die aber für die FB sowohl bei localid als auch bei remoteid mit ID_USER_FQDN arbeitet, was von der FB7490 mit OS06.93 offenbar noch akzeptiert wird und zu einem funktionsfähigen VPN-Tunnel mit der be.IP führt, wenn man bei der auch die identischen Parameter einstellt. Bei meiner FB7580 hatte ich am 09.09.2018 die 07.00-FW installiert, was dazu führte, dass ich keine VPN.cfg importieren konnte (das blöde Tastendrücken bei jedem Datenexport hatte ich schon lange abgestellt). Also wieder recherchieren - die 07.01 wurde nicht in der GUI angezeigt - und neue FW auf FB7580 bringen, alles zeitaufwendig, weil ich den Verlust der Eventlogs durch Abzug der Supportdaten vermeide. Dann VPN.cfg importieren - nachdem es in der FB7490 zum funktionierenden VPN geführt hat, habe ich es versäumt, die aktuelle VPN.cfg zurückzulesen. Der Test ging schief, ist auch kein Wunder, wenn auf der einen Seite ID_FQDN versandt wird und die andere Seite ID_USER_FQDN erwartet.
Zu der Erkenntnis
kann ich nur sagen, dass zu dem Zeitpunkt, an dem ich (zuhause) die (wegen ID_USER_FQDN ungeeignete) VPN.cfg in meine FB7580 importiert habe (wobei die FB7580 ID_FQDN daraus gemacht hat), die be.IP gar nicht am Netz war, sondern die FB7390 (in der Bäckerei), die natürlich über dieselbe DDNSS-DyDns-Adresse erreichbar ist wie die be.IP, wenn sie (in der Bäckerei) am Netz ist. Der besagte Tunnel kann also nur zwischen den 2 FBs bestanden haben. Wie das funktionieren soll, verstehe ich eigentlich nicht, denn die FB7390 in der Bäckerei hat nur 2 MyFritz-VPN-Profile, bei denen als remotehostname die MyFritz-DNS-Adresse (meiner FB7580 und der Filial-FB7490) steht. Vermutlich werden sowohl die DDNSS- als auch die MyFritz-Adresse zur selben IP-Adresse aufgelöst, aber die FQDNs können nicht übereinstimmen und der PSK schon erst recht nicht...
Ich habe jetzt also für meine FB7580 und für die Filial-FB7490 je ein neues VPN.cfg erstellt mit ID_FQDN (siehe #23) und die Werte in der be.IP darauf umgestellt. Test heute Abend.
Zum Thema "Suche im Internet": Ich bin - wie gesagt - zunächst auf das Video und dann auf das Routerforum gekommen (und dort dokumentiert, dass es so, wie es dort beschrieben ist, nicht funktioniert); im IPPF habe ich nichts passendes gefunden und erst als ich wegen des fehlschlagenden VPN.cfg-Imports weiter gesucht habe, bin ich auf den aktuellen Thread gestossen, in dem ich - zunächst - nur dokumentieren wollte, dass ich Probleme auch mit der OS07.01 habe. Beiträge in 2 Foren synchron korrekt zu halten ist m.E. fast unmöglich, weshalb ich jetzt nur noch hier ausführlich poste und im Routerforum hierher verlinke, wenn denn alles funktioniert.
Und nein, die Telekom hat uns nicht nur 3 Wochen Zeit gegeben. Wie die HW-Lösung aussehen wird, war relativ bald klar. Inhouse musste ein Cat-Kabel vom HVT ins Büro verlegt werden, da die FB bisher im Büro stationiert ist und ein S0 über die existierende Fernmeldeverkabelung realisierbar war (aber nicht 2). Als WLAN-APs wollte ich ürsprünglich die neuen Bintec W2022ac-ext einsetzen, deren Lieferbarkeit sich aber von Monat zu Monat verzögerte, sodass ich jetzt W2003ac-ext einsetze, was den Beschaffungsprozess unnötig verzögert hat. Aufgrund weiterer Umstände (leider hat sich meine Frau auf dem Nachhauseweg von der Arbeit einen Mittelfussknochen gebrochen und war 6 Wochen ausser Gefecht mit entsprechenden Auswirkungen auf meine (häusliche) Arbeitsbelastung) und der Tatsache, dass die Telekom den ISDN-Anschluss nicht wie angekündigt zu Ende November, sondern bereits zu Ende September gekündigt hat, hat zu dem besagten Zeitdruck geführt. Die Telekom agiert allerdings manchmal extrem unkooperativ - bei der Umstellung des Haupt-ISDN-Anschlusses im März 2017 hat man der Bäckerei vor der Beauftragung gesagt, "dass sich nichts ändert", weshalb ich über die Umstellung nicht informiert wurde - da war dann die Not gross, als am Umstellungstag kein Telefon mehr ging, gelöst durch provisorische "fliegende" Verlegung eines S0-Kabels vom Büro zum HVT...
Morgen habe ich ein Treffen mit dem Spezialisten vom Kassenfachbetrieb zwecks Sicherstellung der Datenverbindung für die Kassen - hoffentlich erlebe ich da nicht weitere böse Überraschungen - konkrete technische Angaben waren von diesem Betrieb bis jetzt nicht zu erhalten.
Cheers
-hg
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ich habe das jetzt gelesen, (halbwegs) verstanden und trotzdem noch den Eindruck, daß Du einen "missing link" (oder einen blinden Fleck) bei der Funktion von VPN-Konfigurationen im FRITZ!OS (und auch allgemein) hast.
Das ist aber Quatsch ... MyFRITZ! ist am Ende (zumindest in diesem Kontext, den neuen Datenschutz-Horror der "zentralen Verwaltung" aller Geräte für die Kunden lasse ich mal außen vor) auch nichts anderes als ein simpler DynDNS-Dienst (der bei IPv6 ein paar Erweiterungen bietet) und es ist überhaupt kein Problem, FRITZ!Boxen per VPN miteinander zu verbinden, die in vollkommen unterschiedlichen MyFRITZ!-Konten "angemeldet" werden oder auch eine Kombination aus MyFRITZ!-Namen (auf der einen Seite) und anderen DynDNS-Namen (auf der anderen Seite) zu verwenden.
Hier wäre also lediglich eine Konfiguration der Digitalisierungsbox (oder der "originalen" be.IP, wobei das - abseits von Lizenzen fürs VPN - auch egal sein sollte) erforderlich gewesen und die ganze Umkonfiguration von FRITZ!Boxen auf einen anderen DynDNS-Anbieter hätte problemlos auch unterbleiben können. Das hätte dann zumindest den Vorteil gehabt, daß man sich auf Änderungen an einem einzelnen Standort beschränken hätte können - das hilft auch dabei, den Überblick zu behalten und - durch simplen Tausch gegen die alte 7390 - jederzeit wieder einen funktionsfähigen Zustand herstellen zu können, solange der ISDN-Anschluß noch arbeitet.
Dann wäre man vermutlich auch gar nicht erst auf die Schiene geraten, eine P1-ID in Form einer "user_fqdn" zu verwenden, denn die zwei (oder drei) anderen Boxen arbeiteten ja bis zur "Umstellung" wohl auch eher mit einer P1-ID der Form "fqdn". Da liegt dann - wenn man verstanden hat, daß man die anderen Boxen gar nicht anfassen muß und will bzw. die Änderungen dort auf das Minimum beschränken will - automatisch auch bei der be.IP die Verwendung eines FQDN (für sich selbst und natürlich auch für den Peer) ja nahe - das erst mal zu erkunden und zu erkennen, hätte Dir (nach Deiner eigenen Schilderung) wohl massiv Zeit erspart. Wenn die 7390 bisher eine MyFRITZ!-Adresse hatte und diese von den anderen Boxen zum "Auffinden" des Peers beim VPN genutzt wurde, dann ändert sich diese natürlich, wenn man eine be.IP an dieser Stelle einsetzen will, denn die kann sich nicht hinter ein MyFRITZ!-Konto klemmen.
Wobei man solche überbordenden "Abhängigkeiten" bei VPN-Konfigurationen auch problemlos vermeiden kann (und das vielleicht sogar hier auch sollte) - das Thema "passiver Responder" ist hier mehrfach beschrieben und sorgt nicht nur dafür, daß die eine Seite gar nicht wissen muß, wo der Peer im Internet zu finden ist (der braucht damit auch gar keinen DynDNS-Namen, was für die be.IP bei Verwendung der alten, leicht modifizierten Konfigurationen in den verbleibenden FRITZ!Boxen zutreffend gewesen wäre), sie hilft auch noch beim Vermeiden von Problemen, wenn das wg. spezieller Netzwerk-Konstruktionen (z.B. ein Anschluß auf der einen Seite, der keine eingehenden IPv4-Verbindungen zuläßt) etwas komplizierter wird.
Allerdings ist es tatsächlich so, daß der GUI-Assistent bei der Einrichtung von VPN-Verbindungen in etwas spezielleren Szenarien nicht sehr hilfreich ist ... einen (durchaus entscheidenden) Grund dafür, habe ich weiter vorne schon erwähnt (der kennt halt nur ein Eingabefeld "Internet-Adresse" und kann da nur noch nach DNS-Name vs. IP-Adresse unterscheiden, aber verwurstet das als Wert für mehrere Einstellungen höchst unterschiedlicher Bedeutung).
Hier hätte es aber (immer auf Basis Deiner Schilderungen) bereits gereicht, in den FRITZ!Boxen jeweils den "remotehostname" aus den VPN-Konfigurationen zu entfernen (bei einer VPN-Verbindung zweier Boxen untereinander, wie das wohl von der bei Dir zur 7490 der Fall ist, sucht man sich halt eine aus) und ansonsten bei genau dieser alten und offenbar funktionierenden Konfiguration zu bleiben. Dann bräuchte die be.IP nicht einmal einen DynDNS-Namen, der den anderen Boxen bekannt ist ... sie muß nur selbst dafür sorgen, daß der VPN-Tunnel zu den beiden anderen eingerichtet und am Leben erhalten wird (das "keepalive_ip" der FRITZ!Box hat bestimmt irgendwo bei der be.IP sein Gegenstück - wenn nicht, muß man neu planen).
An die vorhandenen VPN-Konfigurationen jeder einzelnen Box kommt man eben über die Export-Datei heran und die dort enthaltenen Verbindungen kann man (nach Dekodierung der verschlüsselten Werte und anschließendem Editieren jeder Verbindung in einer gesonderten Datei) auch problemlos korrigieren/anpassen und dann wieder importieren.
liest sich nämlich so, als würde eine MyFRITZ!-Anmeldung mit einem speziellen User-Namen eine Voraussetzung für eine erfolgreiche VPN-Verbindung sein.
Das ist aber Quatsch ... MyFRITZ! ist am Ende (zumindest in diesem Kontext, den neuen Datenschutz-Horror der "zentralen Verwaltung" aller Geräte für die Kunden lasse ich mal außen vor) auch nichts anderes als ein simpler DynDNS-Dienst (der bei IPv6 ein paar Erweiterungen bietet) und es ist überhaupt kein Problem, FRITZ!Boxen per VPN miteinander zu verbinden, die in vollkommen unterschiedlichen MyFRITZ!-Konten "angemeldet" werden oder auch eine Kombination aus MyFRITZ!-Namen (auf der einen Seite) und anderen DynDNS-Namen (auf der anderen Seite) zu verwenden.
Hier wäre also lediglich eine Konfiguration der Digitalisierungsbox (oder der "originalen" be.IP, wobei das - abseits von Lizenzen fürs VPN - auch egal sein sollte) erforderlich gewesen und die ganze Umkonfiguration von FRITZ!Boxen auf einen anderen DynDNS-Anbieter hätte problemlos auch unterbleiben können. Das hätte dann zumindest den Vorteil gehabt, daß man sich auf Änderungen an einem einzelnen Standort beschränken hätte können - das hilft auch dabei, den Überblick zu behalten und - durch simplen Tausch gegen die alte 7390 - jederzeit wieder einen funktionsfähigen Zustand herstellen zu können, solange der ISDN-Anschluß noch arbeitet.
Dann wäre man vermutlich auch gar nicht erst auf die Schiene geraten, eine P1-ID in Form einer "user_fqdn" zu verwenden, denn die zwei (oder drei) anderen Boxen arbeiteten ja bis zur "Umstellung" wohl auch eher mit einer P1-ID der Form "fqdn". Da liegt dann - wenn man verstanden hat, daß man die anderen Boxen gar nicht anfassen muß und will bzw. die Änderungen dort auf das Minimum beschränken will - automatisch auch bei der be.IP die Verwendung eines FQDN (für sich selbst und natürlich auch für den Peer) ja nahe - das erst mal zu erkunden und zu erkennen, hätte Dir (nach Deiner eigenen Schilderung) wohl massiv Zeit erspart. Wenn die 7390 bisher eine MyFRITZ!-Adresse hatte und diese von den anderen Boxen zum "Auffinden" des Peers beim VPN genutzt wurde, dann ändert sich diese natürlich, wenn man eine be.IP an dieser Stelle einsetzen will, denn die kann sich nicht hinter ein MyFRITZ!-Konto klemmen.
Wobei man solche überbordenden "Abhängigkeiten" bei VPN-Konfigurationen auch problemlos vermeiden kann (und das vielleicht sogar hier auch sollte) - das Thema "passiver Responder" ist hier mehrfach beschrieben und sorgt nicht nur dafür, daß die eine Seite gar nicht wissen muß, wo der Peer im Internet zu finden ist (der braucht damit auch gar keinen DynDNS-Namen, was für die be.IP bei Verwendung der alten, leicht modifizierten Konfigurationen in den verbleibenden FRITZ!Boxen zutreffend gewesen wäre), sie hilft auch noch beim Vermeiden von Problemen, wenn das wg. spezieller Netzwerk-Konstruktionen (z.B. ein Anschluß auf der einen Seite, der keine eingehenden IPv4-Verbindungen zuläßt) etwas komplizierter wird.
Allerdings ist es tatsächlich so, daß der GUI-Assistent bei der Einrichtung von VPN-Verbindungen in etwas spezielleren Szenarien nicht sehr hilfreich ist ... einen (durchaus entscheidenden) Grund dafür, habe ich weiter vorne schon erwähnt (der kennt halt nur ein Eingabefeld "Internet-Adresse" und kann da nur noch nach DNS-Name vs. IP-Adresse unterscheiden, aber verwurstet das als Wert für mehrere Einstellungen höchst unterschiedlicher Bedeutung).
Hier hätte es aber (immer auf Basis Deiner Schilderungen) bereits gereicht, in den FRITZ!Boxen jeweils den "remotehostname" aus den VPN-Konfigurationen zu entfernen (bei einer VPN-Verbindung zweier Boxen untereinander, wie das wohl von der bei Dir zur 7490 der Fall ist, sucht man sich halt eine aus) und ansonsten bei genau dieser alten und offenbar funktionierenden Konfiguration zu bleiben. Dann bräuchte die be.IP nicht einmal einen DynDNS-Namen, der den anderen Boxen bekannt ist ... sie muß nur selbst dafür sorgen, daß der VPN-Tunnel zu den beiden anderen eingerichtet und am Leben erhalten wird (das "keepalive_ip" der FRITZ!Box hat bestimmt irgendwo bei der be.IP sein Gegenstück - wenn nicht, muß man neu planen).
An die vorhandenen VPN-Konfigurationen jeder einzelnen Box kommt man eben über die Export-Datei heran und die dort enthaltenen Verbindungen kann man (nach Dekodierung der verschlüsselten Werte und anschließendem Editieren jeder Verbindung in einer gesonderten Datei) auch problemlos korrigieren/anpassen und dann wieder importieren.
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Dass ich
Wenn ich mit der Einrichtung des dritten Profils in der Filial-FB7490 und in meiner FB7580 die Verbindungen von und zur be.IP zum Laufen bekomme (Test in der Bäckerei später), kann die MyFritz-Verbindung ja auch weiterhin benutzt werden, falls die Bäckerei-FB7390 wieder in Betrieb genommen werden soll/muss.
"keepalive_ip" kommt ins Spiel, wenn die VPN-Verbindung dauerhaft gehalten werden soll (via always_renew = yes), richtig? Das kann man bei der be.IP natürlich auch konfigurieren (Startmodus = immer aktiv). Bisher war es allerdings so, dass der Tunnel erst bei Anfragen zur einer Peer-IP aufgebaut und dann nach Ausbleiben weiteren Datenverkehrs nach der P1-Lebensdauer (bei der be.IP konfigurierbar, bei der FB offenbar fix 3600s) wieder abgebaut wurde. Gibt es einen Grund dafür, das zu ändern?
Das Thema "passiver Responder" schaue ich mir später an.
Cheers
-hg
- oder auch 2 - habe, halte ich für sehr wahrscheinlich. Ich arbeite allerdings normalerweise nach dem Motto "Hände weg von funktionierenden Systemen" - warum sollte ich also Grundlagenforschung betreiben, wenn ich eine funktionierende VPN-Verbindung vorfinde, bei der ich nur den Peer auf einer Seite ersetzen muss. Dass der Teufel im Detail steckt, habe ich dann ja erlebt. Dass MyFritz just another DynDns Provider ist, war mir klar. Dass der von der be.IP weiter verwendet werden kann, jedoch nicht. Und ganz so einfach ist es ja dann doch auch wieder nicht - mit der ganzen Installation der Decodier-SW usw. - und wie sollte ich auf die Idee kommen, dass es überhaupt möglich ist, die gecrypteten Einträge zu decodieren, erst danach wäre mir vermutlich die Bedeutung der Felder klar geworden (wobei jetzt fqdn = "SECRET"; im Support.txt auch nicht gerade decodierbar aussieht, da ist fqdn = "$$$$4VXJCNA..."; im Settings.export schon vielversprechender). Den Aha-Effekt hatte ich nach Installation der "Fernzugang einrichten"-SW.
Wenn ich mit der Einrichtung des dritten Profils in der Filial-FB7490 und in meiner FB7580 die Verbindungen von und zur be.IP zum Laufen bekomme (Test in der Bäckerei später), kann die MyFritz-Verbindung ja auch weiterhin benutzt werden, falls die Bäckerei-FB7390 wieder in Betrieb genommen werden soll/muss.
"keepalive_ip" kommt ins Spiel, wenn die VPN-Verbindung dauerhaft gehalten werden soll (via always_renew = yes), richtig? Das kann man bei der be.IP natürlich auch konfigurieren (Startmodus = immer aktiv). Bisher war es allerdings so, dass der Tunnel erst bei Anfragen zur einer Peer-IP aufgebaut und dann nach Ausbleiben weiteren Datenverkehrs nach der P1-Lebensdauer (bei der be.IP konfigurierbar, bei der FB offenbar fix 3600s) wieder abgebaut wurde. Gibt es einen Grund dafür, das zu ändern?
Das Thema "passiver Responder" schaue ich mir später an.
Cheers
-hg
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Den Grund für "keepalive" gibt es halt nur, wenn man tatsächlich die FRITZ!Boxen bei der Verbindung zur be.IP nur als passive Parts konfiguriert ... dann haben die nämlich selbst keine Chance, die Verbindung bei anstehendem Traffic aufzubauen.
Bis zur Version 06.93 (inkl.) war auch das VPN im FRITZ!OS (gerade bei "gemischter Konfiguration" mit Fremdprodukten) etwas empfindlich, wenn es darum ging, "on demand"-Tunnel zu verwalten und es konnte schon mal passieren (ob das mit 07.0x immer noch so ist, habe ich noch nicht getestet), daß eine bereits bestehende Verbindung in der einen Richtung einfach wieder mit abgeräumt wurde, wenn ein versuchter (zusätzlicher) Verbindungsaufbau aus der anderen Richtung (ein IPSec-Tunnel kann mehrere SA für ein und dieselbe Richtung haben, muß er aber nicht) in die Hose ging.
Das ist u.a. ein Grund, warum man bei einer Box, die keine eingehenden IPv4-Verbindungen annehmen kann (wegen CGN beim Mobilfunk oder an einem DS-Lite-Anschluß), deren Peer eben nicht als "Initiator" konfigurieren darf beim FRITZ!OS ... denn diese Richtung funktioniert dann nicht eben einfach mal nicht, sondern ein Problem in dieser Richtung reißt auch die von der Gegenseite aufgebaute, funktionierende Verbindung mit in den Orkus.
PS: "keepalive" hat bei der FRITZ!Box auch mit "always_renew" nichts wirklich zu tun ... dafür gibt es einen gesonderten Parameter, der irgendeine beliebige und nicht mal zwingend existierende IP-Adresse aus dem entfernten LAN enthalten sollte. Das "ICMP echo"-Paket für das Öffnen und Offenhalten der Verbindung, erzeugt die Box dann selbst ... mit "always_renew" hat das wenig bis nichts zu tun. Letzteres dient nur der Aushandlung einer neuen SA auch dann, wenn eigentlich kein Traffic ansteht und entfaltet wohl erst dann seine Wirkung, wenn ein aufgebauter Tunnel ansonsten wieder abgeräumt würde - aber so genau sind die AVM-Dokumentationen an dieser Stelle auch nicht und das ist mehr Beobachtung und Interpretation als verbürgte Funktionalität (erst recht so kurz nach einem tiefgreifenden Update des FRITZ!OS).
Bis zur Version 06.93 (inkl.) war auch das VPN im FRITZ!OS (gerade bei "gemischter Konfiguration" mit Fremdprodukten) etwas empfindlich, wenn es darum ging, "on demand"-Tunnel zu verwalten und es konnte schon mal passieren (ob das mit 07.0x immer noch so ist, habe ich noch nicht getestet), daß eine bereits bestehende Verbindung in der einen Richtung einfach wieder mit abgeräumt wurde, wenn ein versuchter (zusätzlicher) Verbindungsaufbau aus der anderen Richtung (ein IPSec-Tunnel kann mehrere SA für ein und dieselbe Richtung haben, muß er aber nicht) in die Hose ging.
Das ist u.a. ein Grund, warum man bei einer Box, die keine eingehenden IPv4-Verbindungen annehmen kann (wegen CGN beim Mobilfunk oder an einem DS-Lite-Anschluß), deren Peer eben nicht als "Initiator" konfigurieren darf beim FRITZ!OS ... denn diese Richtung funktioniert dann nicht eben einfach mal nicht, sondern ein Problem in dieser Richtung reißt auch die von der Gegenseite aufgebaute, funktionierende Verbindung mit in den Orkus.
PS: "keepalive" hat bei der FRITZ!Box auch mit "always_renew" nichts wirklich zu tun ... dafür gibt es einen gesonderten Parameter, der irgendeine beliebige und nicht mal zwingend existierende IP-Adresse aus dem entfernten LAN enthalten sollte. Das "ICMP echo"-Paket für das Öffnen und Offenhalten der Verbindung, erzeugt die Box dann selbst ... mit "always_renew" hat das wenig bis nichts zu tun. Letzteres dient nur der Aushandlung einer neuen SA auch dann, wenn eigentlich kein Traffic ansteht und entfaltet wohl erst dann seine Wirkung, wenn ein aufgebauter Tunnel ansonsten wieder abgeräumt würde - aber so genau sind die AVM-Dokumentationen an dieser Stelle auch nicht und das ist mehr Beobachtung und Interpretation als verbürgte Funktionalität (erst recht so kurz nach einem tiefgreifenden Update des FRITZ!OS).
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
Testergebnis: Dasselbe wie zuvor, FB7490FA164 OS06.93 OK, FB7580A25 OS07.01 NOK (Fe4: Bäckerei, FA164: Filiale, A25: meine Wohnung)
Der Fehler dürfte daran liegen, dass die FB7580A25 beim Import des VPN.cfg die von mir gesetzte localid ID_FQDN "FB7580.A25.myvpn" durch die MyFritz-Adresse und die gesetzte remote ID_FQDN "beIP.Fe4.myvpn" durch den remotehostname ersetzt.
Internet - Online-Monitor:
VPN-Konfig aus der decodierten settings.export:
Auszug aus avmike:
Die FB7490FA164 übernimmt meine FQDNs unverändert und damit wird auch ein Tunnel aufgebaut (lt. avmike meint sie scheinbar, dass für P1 mainmode verwendet wird):
Irgend eine Idee, wie man der FB7580 die eigenen FQDNs beibringen kann?
Vielen Dank an PeterPawn, ohne den Hinweis auf die Decodierung wäre ich definitiv überhaupt nicht weitergekommen.
Cheers
hg
Der Fehler dürfte daran liegen, dass die FB7580A25 beim Import des VPN.cfg die von mir gesetzte localid ID_FQDN "FB7580.A25.myvpn" durch die MyFritz-Adresse und die gesetzte remote ID_FQDN "beIP.Fe4.myvpn" durch den remotehostname ersetzt.
Internet - Online-Monitor:
Code:
Internet, IPv4 (gn) verbunden seit 23.09.2018, 18:31 Uhr, Telekom, Geschwindigkeit des Internetzugangs (verfügbare Bitrate): ↓ 62,2 Mbit/s ↑ 12,4 Mbit/s,
IPv4-Adresse: ll.lll.lll.lll
MyFRITZ! (gn) https://zzzzzzzzzzzzzzzz.myfritz.net:47934, Benutzername: [email protected]
Code:
**** CFGFILE:vpn.cfg
/*
* /var/tmp.cfg
* Tue Sep 25 14:08:39 2018
*/
meta { encoding = "utf-8"; }
vpncfg {
vpncfg_version = 1;
/* partially removed myfritz profile 1 */
localid {
fqdn = "zzzzzzzzzzzzzzzz.myfritz.net";
}
} {
/* partially removed myfritz profile 2 */
localid {
fqdn = "zzzzzzzzzzzzzzzz.myfritz.net";
}
} {
enabled = yes;
editable = yes;
conn_type = conntype_lan;
name = "FB7580A25-beIPFe4-Imp2";
boxuser_id = 0;
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 = "rrrrrrrrrrrrrr.ddnss.de";
keepalive_ip = 0.0.0.0;
localid {
fqdn = "zzzzzzzzzzzzzzzz.myfritz.net";
}
remoteid {
fqdn = "rrrrrrrrrrrrrr.ddnss.de";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "kkkkkkkkkkkkkkkkkkkk";
cert_do_server_auth = no;
use_nat_t = yes;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 172.16.0.0;
mask = 255.255.255.0;
}
}
phase2remoteid {
ipnet {
ipaddr = 172.16.1.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-all-all/ah-none/comp-all/pfs";
accesslist = "permit ip any 172.16.1.0 255.255.255.0";
app_id = 0;
}
}
// EOF
Code:
##### BEGIN SECTION vpn VPN
VPN avmike
-------
-rw-r--r-- 1 root root 6959 Sep 26 06:16 /var/tmp/ike.log
-rw-r--r-- 1 root root 20516 Sep 23 18:31 /var/tmp/ike.old
<snip>
<import of FB7580A25-beIPFe4-Imp2.cfg>
2018-09-23 18:31:08 avmike:< add(appl=dsld,cname=xxxxxxxxxxxxxxxx.myfritz.net,localip=oo.ooo.ooo.ooo, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:08 avmike:new neighbour xxxxxxxxxxxxxxxx.myfritz.net: nat_t
2018-09-23 18:31:08 avmike:< add(appl=dsld,cname=yyyyyyyyyyyyyyyy.myfritz.net,localip=oo.ooo.ooo.ooo, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:08 avmike:new neighbour yyyyyyyyyyyyyyyy.myfritz.net: nat_t
2018-09-23 18:31:08 avmike:< add(appl=dsld,cname=FB7580A25-beIPFe4-Imp2,localip=oo.ooo.ooo.ooo, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:08 avmike:new neighbour FB7580A25-beIPFe4-Imp2: nat_t
<new public IP assigned by DTAG (dip0.t-ipconnect.de): changed from oo... to ll..., obviously caused by FB7580A25 VPN.cfg import>
2018-09-23 18:31:29 avmike:< add(appl=dsld,cname=xxxxxxxxxxxxxxxx.myfritz.net,localip=ll.lll.lll.lll, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:29 avmike:new neighbour xxxxxxxxxxxxxxxx.myfritz.net: nat_t
2018-09-23 18:31:29 avmike:< add(appl=dsld,cname=yyyyyyyyyyyyyyyy.myfritz.net,localip=ll.lll.lll.lll, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:29 avmike:new neighbour yyyyyyyyyyyyyyyy.myfritz.net: nat_t
2018-09-23 18:31:29 avmike:< add(appl=dsld,cname=FB7580A25-beIPFe4-Imp2,localip=ll.lll.lll.lll, remoteip=255.255.255.255, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=0.0.0.0 flags=0x8001 tunnel no_xauth no_cfgmode nat_t no_certsrv_server_auth)
2018-09-23 18:31:29 avmike:new neighbour FB7580A25-beIPFe4-Imp2: nat_t
<snip>
<beIP.Fe4.myvpn tries to ping 172.16.0.254 which is the local IP of FB7580A25 (NOK)>
2018-09-25 18:34:08 avmike:<<< aggressive mode[rr.rr.rrr.rrr:976] ???: V1.0 430 IC 1c76d5432a7a2b34 RC 00000000 0000 SA flags=
2018-09-25 18:34:08 avmike:unknown receive VENDOR ID Payload: XAUTH
2018-09-25 18:34:08 avmike:unknown receive VENDOR ID Payload: DPD
2018-09-25 18:34:08 avmike:> user_query(ipaddr=rr.rr.rrr.rrr)
2018-09-25 18:34:08 avmike:rr.rr.rrr.rrr:976: aggrmode: init aggr-exchange: user request send ID_FQDN : beIP.Fe4.myvpn
2018-09-25 18:34:08 avmike:<<< aggressive mode[rr.rr.rrr.rrr:976] ???: V1.0 430 IC 1c76d5432a7a2b34 RC 00000000 0000 SA flags=
2018-09-25 18:34:09 avmike:<<< aggressive mode[rr.rr.rrr.rrr:976] ???: V1.0 430 IC 1c76d5432a7a2b34 RC 00000000 0000 SA flags=
<snip>
<FB7390Fe4 ping 172.16.0.254 (OK)>
2018-09-26 06:16:22 avmike:<<< aggressive mode[rr.rr.rrr.rr] ???: V1.0 684 IC 236534dafca6f610 RC 00000000 0000 SA flags=
2018-09-26 06:16:22 avmike:aggressive mode yyyyyyyyyyyyyyyy.myfritz.net: selected lifetime: 3600 sec(no notify)
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net receive VENDOR ID Payload: XAUTH
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net receive VENDOR ID Payload: DPD
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net receive VENDOR ID Payload: NAT-T RFC 3947
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: add phase 1 SA: DH2/AES-256/SHA1/3600sec id:1
2018-09-26 06:16:22 avmike:>>> aggressive mode [rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 456 IC 236534dafca6f610 RC d64370612e929d51 0000 SA flags=
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: Warning: source changed from 0.0.0.0:500 to rr.rr.rrr.rr:500
2018-09-26 06:16:22 avmike:<<< aggressive mode[rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 140 IC 236534dafca6f610 RC d64370612e929d51 0000 HASH flags=e
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: embedded inital contact message received
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: Phase 1 ready
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: current=0.0.0.0 new=rr.rr.rrr.rr
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: no valid sa, reseting initialcontactdone flag
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: start waiting connections
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: NO waiting connections
2018-09-26 06:16:22 avmike:<<< infomode[rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 92 IC 236534dafca6f610 RC d64370612e929d51 3c0f5a80 HASH flags=e
2018-09-26 06:16:22 avmike:yyyyyyyyyyyyyyyy.myfritz.net: initial contact message received
2018-09-26 06:16:23 avmike:<<< quickmode[rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 2108 IC 236534dafca6f610 RC d64370612e929d51 fb8a0b2 HASH flags=e
2018-09-26 06:16:23 avmike:>>> quickmode [rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 332 IC 236534dafca6f610 RC d64370612e929d51 fb8a0b2 HASH flags=e
2018-09-26 06:16:23 avmike:<<< quickmode[rr.rr.rrr.rr] yyyyyyyyyyyyyyyy.myfritz.net: V1.0 60 IC 236534dafca6f610 RC d64370612e929d51 fb8a0b2 HASH flags=e
2018-09-26 06:16:23 avmike:yyyyyyyyyyyyyyyy.myfritz.net: Phase 2 ready
2018-09-26 06:16:23 avmike:NEW Phase 2 SA: ESP-AES-256/SHA1 SPI: 534076B6 LT: 3600 I/O: IN
2018-09-26 06:16:23 avmike:NEW Phase 2 SA: ESP-AES-256/SHA1 SPI: 6251B8CB LT: 3600 I/O: OUT
2018-09-26 06:16:23 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: CAA2 LT: 3600 I/O: IN
2018-09-26 06:16:23 avmike:NEW Phase 2 SA: IPComp-LZJH SPI: D954 LT: 3600 I/O: OUT
2018-09-26 06:16:23 avmike:< cb_sa_created(name=yyyyyyyyyyyyyyyy.myfritz.net,id=1,...,flags=0x00002001)
2018-09-26 06:16:23 avmike:yyyyyyyyyyyyyyyy.myfritz.net: start waiting connections
2018-09-26 06:16:23 avmike:yyyyyyyyyyyyyyyy.myfritz.net: NO waiting connections
VPN assocs
----------
/proc/kdsld/dsliface/internet/ipsec/assocs:
xxxxxxxxxxxxxxxx.myfritz.net: ll.lll.lll.lll:0.0.0.0 255.255.255.255:0.0.0.0 0 SAs valid enabled dynlocalip
permit ip any 192.168.164.0 255.255.255.0
Forbidden Clients: 192.168.179.0/24
yyyyyyyyyyyyyyyy.myfritz.net: ll.lll.lll.lll:0.0.0.0 46.81.202.40:0.0.0.0 1 SAs valid enabled dynlocalip
permit ip any 192.168.178.0 255.255.255.0
Forbidden Clients: 192.168.179.0/24
FB7580A25-beIPFe4-Imp2: ll.lll.lll.lll:0.0.0.0 255.255.255.255:0.0.0.0 0 SAs valid enabled dynlocalip
permit ip any 172.16.1.0 255.255.255.0
Forbidden Clients: 192.168.179.0/24
VPN connections
----------
/proc/kdsld/dsliface/internet/ipsec/connections:
xxxxxxxxxxxxxxxx.myfritz.net: pmtu 0 mtu 1492 dont_filter_netbios
yyyyyyyyyyyyyyyy.myfritz.net: pmtu 0 mtu 1492 dpd_supported dont_filter_netbios
FB7580A25-beIPFe4-Imp2: pmtu 0 mtu 1492 dont_filter_netbios
##### END SECTION vpnDie FB7490FA164 übernimmt meine FQDNs unverändert und damit wird auch ein Tunnel aufgebaut (lt. avmike meint sie scheinbar, dass für P1 mainmode verwendet wird):
Code:
2018-09-25 18:34:42 avmike:mainmode FB7490FA164-beIPFe4-Imp2: selected lifetime: 3600 sec(no notify)[/FONT][/FONT][/FONT][/FONT][/FONT][/FONT]
[FONT=Arial][FONT=Courier New][FONT=Arial][FONT=Courier New][FONT=Arial][FONT=Courier New]2018-09-25 18:34:42 avmike:FB7490FA164-beIPFe4-Imp2 remote peer supported XAUTH
2018-09-25 18:34:42 avmike:FB7490FA164-beIPFe4-Imp2 remote peer supported DPD
2018-09-25 18:34:43 avmike:mainmode FB7490FA164-beIPFe4-Imp2: add SA 1
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: Warning: source changed from 0.0.0.0:500 to ff.ff.fff.fff:56656
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: switching to NAT-T (Responder)
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: embedded inital contact message received
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: Phase 1 ready
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: current=0.0.0.0 new=ff.ff.fff.fff:56656
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: no valid sa, reseting initialcontactdone flag
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: local is behind a nat
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: remote is behind a nat
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: start waiting connections
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: NO waiting connections
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: Phase 2 ready
2018-09-25 18:34:43 avmike:< cb_sa_created(name=FB7490FA164-beIPFe4-Imp2,id=1,...,flags=0x00032001)
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: start waiting connections
2018-09-25 18:34:43 avmike:FB7490FA164-beIPFe4-Imp2: NO waiting connections
2018-09-25 18:34:53 avmike:>>>4500 nat-t-keepalive[ff.ff.fff.fff:56656]Vielen Dank an PeterPawn, ohne den Hinweis auf die Decodierung wäre ich definitiv überhaupt nicht weitergekommen.
Cheers
hg
Zuletzt bearbeitet:
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,267
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ich bin zwar noch nicht dazu gekommen, den Import bei der 07.01 zu testen (daß AVM da Änderungen vorgenommen hat, ist bekannt - wie weit die genau gehen, braucht schon systematische Tests), aber ich verstehe halt nicht, warum man der 7580 mit 07.01 nun nicht einfach ihren Willen lassen sollte und die be.IP so konfiguriert, daß die dann eben den MyFRITZ!-Namen als FQDN für die P1-ID des Peers hernimmt.
Denkbar, daß tatsächlich der Import die Datei verändert ... trotzdem irritiert mich das "editable=yes" für die importierte Konfiguration schon mächtig. Wenn das "manuell" gesetzt wurde, stellt sich die Frage, warum das so ist ... es "erlaubt" ja gewissermaßen dem FRITZ!OS, diese Konfiguration anzupassen.
Der Normalfall wäre es halt, daß solchermaßen importierte Konfigurationen da ein "editable=no" stehen haben (oder gar nichts, was dann in ein "no" mündet), weil sie in der Regel ja ein Szenario abbilden sollen, was man mit dem GUI eben gerade nicht konfigurieren kann - ansonsten bräuchte es ja den Import gar nicht wirklich und man könnte es gleich alles per GUI richtig einstellen.
Nur dann, wenn die Einstellungen für eine Verbindung tatsächlich beim Speichern geändert wird, stehen die Chancen auf dauerhafte Änderungen schlecht ... weil "handgemachte" Änderungen über einen Shell-Zugang dann tatsächlich bei jedem neuen Schreiben der "vpn.cfg" verloren wären.
------------------------------------------------------------------------------------------------
Andererseits bin ich schon noch einigermaßen skeptisch, daß die AVM-Änderungen zur 07.0x tatsächlich soo tiefgreifend sind, daß die bisher funktionierenden Konfigurationen den Dienst verweigern ... das betrifft dann ja auch die bereits erwähnten Netzwerk-Zugänge, an denen keine eingehenden IPv4-Verbindungen möglich sind, wenn der "remotehostname" automatisch aus der "remoteid" für den Peer gebildet würde oder umgekehrt.
Genau deshalb würde ich hier schon mal gerne die tatsächlich importierte Datei sehen und nicht erst das "Ergebnis" nach der Speicherung durch das FRITZ!OS ... ich werde nämlich den Verdacht nicht los, daß auch diese wieder von irgendeiner alten und (zumindest mittlerweile) falschen Anleitung aus irgendeinem anderen Board "inspiriert" wurde und eigentlich falsche Angaben (für eine "handgemachte Konfiguration") enthält.
Aber es ist eben nur ein Verdacht meinerseits ... man kann natürlich auch selbst hingehen und mal ermitteln, welche Bedeutung die einzelnen Einstellungen für so eine "connection" wohl haben und das dann einfach mal (mit kritischem Blick) mit den eigenen Einstellungen vergleichen und deren Sinn mal analysieren.
Das muß doch eigentlich gar nicht wirklich sein (ich weiß nicht, ob es bei 07.01 geht oder nicht, weil halt auch die Frage ist, ob es beim Import oder beim Speichern verändert wird), wenn man etwas flexibler agiert.
Denkbar, daß tatsächlich der Import die Datei verändert ... trotzdem irritiert mich das "editable=yes" für die importierte Konfiguration schon mächtig. Wenn das "manuell" gesetzt wurde, stellt sich die Frage, warum das so ist ... es "erlaubt" ja gewissermaßen dem FRITZ!OS, diese Konfiguration anzupassen.
Der Normalfall wäre es halt, daß solchermaßen importierte Konfigurationen da ein "editable=no" stehen haben (oder gar nichts, was dann in ein "no" mündet), weil sie in der Regel ja ein Szenario abbilden sollen, was man mit dem GUI eben gerade nicht konfigurieren kann - ansonsten bräuchte es ja den Import gar nicht wirklich und man könnte es gleich alles per GUI richtig einstellen.
Nur dann, wenn die Einstellungen für eine Verbindung tatsächlich beim Speichern geändert wird, stehen die Chancen auf dauerhafte Änderungen schlecht ... weil "handgemachte" Änderungen über einen Shell-Zugang dann tatsächlich bei jedem neuen Schreiben der "vpn.cfg" verloren wären.
------------------------------------------------------------------------------------------------
Andererseits bin ich schon noch einigermaßen skeptisch, daß die AVM-Änderungen zur 07.0x tatsächlich soo tiefgreifend sind, daß die bisher funktionierenden Konfigurationen den Dienst verweigern ... das betrifft dann ja auch die bereits erwähnten Netzwerk-Zugänge, an denen keine eingehenden IPv4-Verbindungen möglich sind, wenn der "remotehostname" automatisch aus der "remoteid" für den Peer gebildet würde oder umgekehrt.
Genau deshalb würde ich hier schon mal gerne die tatsächlich importierte Datei sehen und nicht erst das "Ergebnis" nach der Speicherung durch das FRITZ!OS ... ich werde nämlich den Verdacht nicht los, daß auch diese wieder von irgendeiner alten und (zumindest mittlerweile) falschen Anleitung aus irgendeinem anderen Board "inspiriert" wurde und eigentlich falsche Angaben (für eine "handgemachte Konfiguration") enthält.
Aber es ist eben nur ein Verdacht meinerseits ... man kann natürlich auch selbst hingehen und mal ermitteln, welche Bedeutung die einzelnen Einstellungen für so eine "connection" wohl haben und das dann einfach mal (mit kritischem Blick) mit den eigenen Einstellungen vergleichen und deren Sinn mal analysieren.
Zuletzt bearbeitet:
drummer1154
Neuer User
- Mitglied seit
- 2 Jun 2017
- Beiträge
- 42
- Punkte für Reaktionen
- 13
- Punkte
- 8
editable = no; bewirkt einerseits genau das, was ich schon erlebt habe: Man kann die Settings in der GUI nicht mehr einsehen (auch wenn man sie gar nicht ändern möchte - wenn man will, muss man ja das Passwort eingeben).
Andererseits werden dann aber die eigenen FQDNs übernommen - soeben verifiziert. Beim Import trennt die FB die Internetverbindung - deshalb dauert es auch so lange.
Meine VPN.cfg habe ich abgeleitet von der vpncfg aus der (codierten) Setting.export und der vom "Fernzugang einrichten"-Tool erstellten (mit BeyondCompare soeben nochmal verifiziert). Die ike_forward_rules (vom Tool) habe ich weggelassen und editable = yes; gesetzt, damit ich die Profile in der GUI anschauen kann.
Ich kann sie gern komplett E-Mailen, meine ist <username><at>arcor.de
Die MyFritz-Namen kann ich mir einfach nicht merken, daher möchte ich die selbst erstellten verwenden, was ja offenbar auch möglich ist, wenn man darauf verzichtet, das Profil in der GUI einzusehen - braucht man auch nicht, wenn mann die Settings decodiert, da gebe ich Dir Recht.
Gibt es einen einfach zu findenden Ort, an dem Erklärungen für
Cheers
-hg
Andererseits werden dann aber die eigenen FQDNs übernommen - soeben verifiziert. Beim Import trennt die FB die Internetverbindung - deshalb dauert es auch so lange.
Meine VPN.cfg habe ich abgeleitet von der vpncfg aus der (codierten) Setting.export und der vom "Fernzugang einrichten"-Tool erstellten (mit BeyondCompare soeben nochmal verifiziert). Die ike_forward_rules (vom Tool) habe ich weggelassen und editable = yes; gesetzt, damit ich die Profile in der GUI anschauen kann.
Ich kann sie gern komplett E-Mailen, meine ist <username><at>arcor.de
Die MyFritz-Namen kann ich mir einfach nicht merken, daher möchte ich die selbst erstellten verwenden, was ja offenbar auch möglich ist, wenn man darauf verzichtet, das Profil in der GUI einzusehen - braucht man auch nicht, wenn mann die Settings decodiert, da gebe ich Dir Recht.
Gibt es einen einfach zu findenden Ort, an dem Erklärungen für
zusammengefasst gelistet sind?
Cheers
-hg
Zuletzt bearbeitet:
Neueste Beiträge
-
[Frage] Freetz-ng auf 7590 AX oder 7690?
- Letzte: KunterBunter
-
[Sammlung] FRITZ!Smart Gateway - Labor/Inhaus 7.90 (Zyklus 'Smart24P1')- Letzte: Ralf-Fritz
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: zorro neu
