7490 7.01 / VPN Probleme

[koyaanisqatsi]

Moins


Überprüft doch mal ob ein aktiviertes myfritz.net ( in der Box ) Vorrang vor dem benutzerdefinierten DynDNS hat.

Bei mir, beispielweise, wird kein myfritz.net DynDNS benutzt und deshalb taucht auch nur mein "Securepoint" DynDNS Name in allen möglichen Konfigs* auf.


* VPN und den "Fernzugang" ( HTTPS ), wenn die "MyFRITZ!App 2" ungefragterweise den aktiviert beim "Heimnetzverbindung" einrichten, obwohl dies eben auch VPN ist.


Auch fies/mies
Nach einem normalen Firmwareupdate wird nach Login zur Box mit Dialogen geworfen...
1. Update erfolgreich ( oder auch nicht ? - Noch nicht gesehen )
2. Über Irgendwas via EMail informieren lassen
...wer da nicht checkt, dass der 2. Dialog den MyFritz! ( myfritz.net ) Account anlegt/aktiviert, kann auch in die "VPN Falle" treten.


EDIT
Welcher DynDNS Dienst wird aktuell/zukünftig genommen ?
1. VPN Benutzer in der FRITZ!Box anlegen
2. Daten anzeigen lassen
3. Benutzer wieder löschen

 

[PeterPawn]

Mir reicht schon die (zumindest von mir so herausgelesene) Bestätigung, daß auch FRITZ!OS 7 die Einstellungen beim Import nicht komplett verwürfelt, wenn man das "editable" nicht angibt bzw. auf "no" läßt.

Mir ist etwas schleierhaft, wieso man das AVM-GUI "als Kontrolle" einer importierten VPN-Verbindung einsetzen kann oder will, wenn das doch gar nicht alle Szenarien abbilden kann - das ist ja kein "Editor" für VPN-Konfigurationen, das ist eher ein Assistent, der bei der Einrichtung (der drei häufigsten Szenarien und auch die nur dann, wenn sie tatsächlich fast keine Besonderheiten enthalten) behilflich sein will. Man sollte das eher mit den Assistenten für alles mögliche (von der WLAN-Anmeldung bis zur Internet-Verbindung) vergleichen und nicht mit einem Editor verwechseln.

Hier hast Du Dir offenbar (erneut) selbst ein Bein gestellt, wenn die in #38 "beklagten" Änderungen (nicht zu ernst nehmen die Formulierung) eigentlich nur deshalb erfolgen, weil Du unbedingt "editable = yes;" setzen wolltest ... obwohl Du das hier im IPPF mit einiger Sicherheit (oder ich schreibe vielleicht besser "hoffentlich") nicht gesehen haben wirst - ja, eigentlich sollte man hier sogar die Argumentation gegen ein "editable = yes;" in handgemachten VPN-Konfigurationen finden. Wenn das andere Quellen falsch darstellen, sollte man denen vielleicht mal "Bescheid stoßen".

Ich kann mir andererseits nicht mal im Ansatz erklären, warum sich jemand einen MyFRITZ!-Namen unbedingt "merken" will ... die werden irgendwo einmalig konfiguriert (bis hin zum Lesezeichen in einem Browser, wenn's sein muß) und dann nie wieder wirklich gebraucht. Das sieht ja offensichtlich auch AVM so, denn ansonsten hätte man da ja auch "sprechendere" Namen verwenden bzw. generieren können. Aber sich den MyFRITZ!-Namen unbedingt merken zu wollen, weil man den ständig irgendwo eingeben muß, erinnert etwas an das Auswendiglernen von IP-Adressen ... auch wenn sich der Name nicht ändern sollte.

Ob eine (ältere) Liste mit AVM-Erläuterungen zu einigen (lange nicht allen und eben schon gar nicht zu den neu eingeführten) Parametern in einer "vpn.cfg" noch existiert, weiß ich nicht (ich denke mal, die ist beim Re-Design der AVM-Site unter die Räder gekommen) ... ursprünglich war es beim FRITZ!OS sogar mal so, daß man tatsächlich alle VPN-Verbindungen auf einen Schlag in einer einzelnen "vpn.cfg" importieren mußte und das Windows-Programm diese gemeinsame Datei auch bei mehreren Verbindungen dann erstellte ... ungefähr aus dieser Zeit stammt die von mir erwähnte Auflistung (ich glaube, da war noch nicht mal "keepalive_ip" implementiert).

Eine andere, umfassende Quelle kenne ich nicht ... ich habe nur mal irgendwo hier erklärt, wie man eine VPN-Konfiguration für LAN-LAN-Kopplung mit dem Editor und passenden Vorlagen selbst erstellt - aber auch da habe ich keine Ahnung, wo das genau war und ich suche das jetzt auch nicht.

 

[drummer1154]

Mir ist etwas schleierhaft, wieso man das AVM-GUI "als Kontrolle" einer importierten VPN-Verbindung einsetzen kann oder will

eben wegen der kryptischen MyFritz-Namen. Es hat nichts mit "Eingeben" zu tun, sondern mit "Lebenserleichterung" im Stress: Wenn Du einen Anruf von der Bäckerei kriegst, dass die Verbindung mit den Kassen nicht funzt, kanst Du in der VPN-Übersicht schauen, ob das VPN für die Filiale aktiv ist. Jetzt stehen da aber 3 kryptische Namen drin - wen man den "Editiergriffel" betätigt, sieht man wenigstens die lokalen IP-Adressen der Peers - und die kennt man tatsächlich meistens auswendig...
Das sollte sich mit der von mir gewählten "Kodierung" der Standorte in den Profilnamen aber erledigt haben.

Hier hast Du Dir offenbar (erneut) selbst ein Bein gestellt

1) Ich habe das nicht hier im IPPF "gefunden", sondern durch eigenes Trial and Error; siehe #14, das ich bisher nicht verstanden habe, weil ich - eben fälschlicherweise - davon ausgegangen bin, dass dieses Setting nur das Editieren in der GUI betrifft.
2) Dass die FW beim Import oder beim Speichern oder sonstwo meine Eingangsdaten ohne irgend welche Rückmeldung verändert, halte ich für ein Unding, zumindest solange sie die gespeicherten Daten nur verschlüsselt wieder rausrückt.

ich habe nur mal irgendwo hier erklärt, wie man eine VPN-Konfiguration für LAN-LAN-Kopplung mit dem Editor und passenden Vorlagen selbst erstellt

Das reicht mir schon zum Suchen, danke.

Nächster Test heute Abned...

Cheers
-hg

 

[PeterPawn]

Du kannst doch jeder VPN-Verbindung (solange Du sie selbst durch den Import einer Datei erstellst) jeden beliebigen Namen geben ... Du kommst mit einer MyFRITZ!-Adresse danach praktisch nie wieder in Kontakt.

Ich habe hier mehrere VPN-Verbindungen und die hören auf verschiedene Namen, aber nicht eine davon hat einen MyFRITZ!- oder irgendeinen anderen DynDNS-Namen als Bezeichnung in der Übersicht:

Ich kann die Argumentation halt immer noch nicht so richtig nachvollziehen ... aber es ist am Ende auch egal.

Du wirst das schon irgendwie hinbekommen ... aber wenn man sich mal überlegt, wieviel Zeit Dich jetzt die Geschichte mit der richtigen ID für P1 gekostet hat (und dabei wird die nur gebraucht, um das passende "pre-shared secret" für eine Verbindung zu finden), dann machst Du Dir das Leben (so "von außen" betrachtet) schon recht schwer an Stellen, wo man einfach durch minimale Änderungen der bereits vorhandenen Konfigurationen (von der Umstellung der FRITZ!Boxen auf Responder-Modus hatte ich ja schon geschrieben) und zumindest temporäre Kompromisse (wenn einem ein Name nicht paßt, kann man den hinterher ja immer noch ändern) praktisch im Handumdrehen zu ersten Erfolgen gekommen wäre, die man dann - wenn es erst mal überhaupt funktioniert - ja auch noch hätte "verfeinern" können.

Vielleicht kann das ja als Beispiel für spätere Leser dienen, daß es am Ende häufig sogar noch Zeit spart, wenn man sich erst mal (halbwegs umfassend) schlau macht und erst dann mit "echten" VPN-Konfigurationen beginnt (oder was man sonst auch immer machen will). Das, was man am Beginn in etwas Suchen und Lesen investiert (sagen wir mal 2 Stunden als Hausnummer), hat man hinterher durch gesparte Fehlversuche und Irrwege ganz schnell wieder raus. Das weiß man zwar vorher nie sicher, aber in der deutlichen Mehrzahl der Fälle rechnet sich das tatsächlich ... spätestens wenn man beim nächsten Problem dann bereits auf das zuvor erworbene Wissen zurückgreifen kann.

Mit

2) Dass die FW beim Import oder beim Speichern oder sonstwo meine Eingangsdaten ohne irgend welche Rückmeldung verändert, halte ich für ein Unding, zumindest solange sie die gespeicherten Daten nur verschlüsselt wieder rausrückt.

habe ich auch so meine Probleme ... denn Du hast der Box ja ausdrücklich erlaubt, die VPN-Konfiguration zu ändern bzw. ich wage sogar mal die These, daß die Box das tatsächlich erst dann ändert (und nicht direkt beim Import), wenn man eine solche Verbindung danach auch mit dem GUI anfaßt.

Diese These müßte man zwar vermutlich erst noch einmal verifizieren, aber sie entspräche (ebenso wie das Verhalten bei "editable=no;") dem bisher Gewohnten und man stellt sich ja unwillkürlich die Frage, warum AVM das überhaupt ändern sollte. Im Angesicht Deiner - jetzt nachträglich "ans Licht gekommenen" - Vorgehensweise könnte man sogar die Feststellung, daß AVM beim Import aus "user_fqdn" einfach "fqdn" machen würde, noch einmal auf den Prüfstand stellen - es könnte ja genauso gut auch erst dann geschehen, wenn Du diese Verbindung wieder im GUI-Editor "anpackst".

Abgesehen davon verstehe ich auch nicht so ganz, was es für einen Unterschied macht, ob die Box eine VPN-Konfiguration nun verschlüsselt "rausrückt" oder unverschlüsselt ... eigentlich sollte man für eine per Import erstellte Verbindung ja weiterhin die Import-Datei verfügbar haben. Ein Compiler (um mal eine andere Software zu benennen) gibt mir auch nur die fertige Objektdatei aus und für das "Archivieren" der Eingaben (aka Quelldateien) bin ich selbst verantwortlich.

 

[drummer1154]

Testergebnis: Endlich Erfolg (Fe4: Bäckerei, FA164: Filiale, A25: meine Wohnung):

• be.IPFe4 - FB7490FA164 OS06.93 = OK
• be.IPFe4 - FB7580A25 OS07.01 = OK

Der letzte Schritt ist jetzt noch das Update der FB7490FA164 auf OS07.01 (am Samstag Nachmittag nach Geschäftsschluss), ich erwarte dabei aber keine Überraschung mehr.

EDIT 2018-09-30 Update der FB7490FA164 auf OS07.01 = OK, be.IPFe4 - FB7490FA164 OS07.01 = OK /EDIT

EDIT weil ich den vorhergehenden Beitrag erst jetzt gesehen habe:

die These, daß die Box das tatsächlich erst dann ändert (und nicht direkt beim Import), wenn man eine solche Verbindung danach auch mit dem GUI anfaßt.

kann ich definitiv ausschliessen - VPN.cfg importiert, getestet => FAILED. Und

Du hast der Box ja ausdrücklich erlaubt, die VPN-Konfiguration zu ändern

- genau das geht m.E. aus der lapidaren Bezeichnung "editable = yes;" leider nicht hervor, wenn sich als sichtbarer Effekt lediglich ein "Editiergriffel" in der GUI ergibt - auf die Idee, dass man die eingelesenen Daten rücklesen und decrypten muss, um eine echte Kontrolle zu erlangen, muss man erst mal kommen.

Ein Compiler (um mal eine andere Software zu benennen) gibt mir auch nur die fertige Objektdatei aus und für das "Archivieren" der Eingaben (aka Quelldateien) bin ich selbst verantwortlich

- korrekt, aber da kannst Du mit dem Debugger wenn nötig Schritt für Schritt nachvollziehen, was der Compiler aus Deiner Source gemacht hat, im Zweifelsfall im Assemblercode - hier geht genau das nicht (ich wüsste jedenfalls nicht wie, ohne die Kiste zu modden) und es bleibt nur Trial-and-Error. Noch zum Thema Suchen: Ich habe als erstes nach einem "Rezept" gesucht, wie man via VPN die be.IP mit einer FB koppelt, und das nicht beschränkt auf IPPF (v.a. weil mir hier zuwenig Threads für Bintec drin sind), was nach "Erfolgsmeldungen" zu angeblich funktionierenden Konfigurationen zu endlosem Trial-and-Error geführt hat, und eben nicht mit 2 Stunden Recherche abgetan war. /EDIT

Ich möchte die hier mühsam gewonnenen Erkenntnisse in einem neuen Thread zusammenfassen und dort ein kommentiertes VPN.cfg zur Verfügung stellen, nachdem ich hier im Forum zwar 100 Treads zum Thema gefunden habe, die sich aber alle mit separaten Einzeldetails befassen (teilweise in epischer Breite ausgewälzt), aber eben keine zusammenfassende Darstellung, v.a. für Leute, die ihre FBs nicht modden wollen/können. Es tut mir auch Leid, diesen Thread sozusagen "gekapert" zu haben; der IP/TE ist wohl mit seinem eigentlichen Problem (#1) nicht wirklich weiter gekommen, oder?

Ich möchte allerdings in diesem neuen Thread möglichst nur 1 Beitrag haben (und daher das Ganze erst mal offline vorbereiten, evt. auf einem Cloudservice, zu dem ich interessierten "Mitstreitern" bzw. Experten Zugang geben möchte, bei Interesse bitte E-Mail (s. #40), echte PMs sind hier im IPPF ja leider nicht möglich) und ausserdem den Beitrag dauerhaft editieren/updaten können - falls ein Moderator mitliest: Ist sowas möglich? EDIT 2018-09-30 Offenbar darf man eigene Beiträge unbegrenzt editieren. /EDIT

PS: Heute muss ich eine andere "Baustelle" beackern...

Cheers
-hg

 

[Micha0815]

Der letzte Schritt ist jetzt noch das Update der FB7490FA164 auf OS07.01 ... ich erwarte dabei aber keine Überraschung mehr

Genau diese Überraschungen waren/sind hier das Thema wie auch in benachbarten Threads.

echte PMs sind hier im IPPF ja leider nicht möglich

Das nennt sich nunmehr Unterhaltung.
LG

 

[sulihari]

Habe jetzt von der "Gegenseite" einen Syslog Auszug erhalten. Unverändert bis auf "name" und "IP"
Kann hier evt. jemand einen Hinweis geben? (von 7490 mit 7.01 zum Draytek)
vpn.cfg siehe #9, ike_forward_rules sind mittlerweile entfernt, da scheinbar nicht mehr notwendig.

17:38:10 DrayTekIKE <==, Next Payload=ISAKMP_NEXT_SA, Exchange Type = 0x4, Message ID = 0x0
17:38:10 DrayTekResponding to Aggressive Mode from #.#.#.#
17:38:10 DrayTekAccept Phase1 prorosals : ENCR OAKLEY_AES_CBC, HASH OAKLEY_SHA
17:38:10 DrayTekIKE ==>, Next Payload=ISAKMP_NEXT_SA, Exchange Type = 0x4, Message ID = 0x0
17:38:10 DrayTekIKE <==, Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x4, Message ID = 0x0
17:38:10 DrayTekISAKMP SA #105212 will be replaced after 2700 seconds
17:38:10 DrayTekISAKMP SA established with #.#.#.#. In/Out Index: -1/0
17:38:10 DrayTekIKE <==, Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x20, Message ID = 0x464d147
17:38:10 DrayTekIKE ==>, Next Payload=ISAKMP_NEXT_HASH, Exchange Type = 0x5, Message ID = 0xa9826f66
17:38:10 DrayTek[IPSEC/IKE][L2L][1:name][@#.#.#.#] state transition fail: STATE_QUICK_R0
17:38:10 DrayTek[IPSEC/IKE][L2L][1:name][@#.#.#.#] may be security method/sbunet setting/GRE setting unmatched?

besten Dank
sulihari

//edit by stoney: [CODE] TAG s [/CODE] gesetzt

 

[Shirocco88]

17:38:10 DrayTek[IPSEC/IKE][L2L][1:name][@#.#.#.#] state transition fail: STATE_QUICK_R0 17:38:10 DrayTek[IPSEC/IKE][L2L][1:name][@#.#.#.#] may be security method/sbunet setting/GRE setting unmatched?

ohne zugehörige Config (FritzBox und Draytek) wird es schwierig;
Bitte anonymisieren und posten; ggf. Screenshots von Draytek-Config.

was steht im avmike.log der FritzBox ?

passen die phase2localid sowie phase2remoteid Einstellungen zw. FritzBox und Draytek-Config ?

               phase2localid {
                       ipnet {
                               ipaddr = 192.168.xxx.0;
                               mask = 255.255.255.0;
                       }
               }
phase2remoteid {
                       ipnet {
                               ipaddr = 172.16.yyy.0;
                               mask = 255.255.255.0;
                       }

 

[sulihari]

Die Fritzbox 7490 vpn.cfg habe ich korrigiert siehe #9. Der ursprünglich fehlende Block "phase2remoteid" war durch diverses Probieren cut/paste usw. verloren gegangen, aber effektiv in der geladenen vpn.cfg enthalten.
Die Draytek Config muss ich anfragen, da der VPN Zugriff eben nicht mehr funktioniert und andere Leute die Hand darauf haben. Ist etwas kompliziert.
Ich warte ebenfalls noch auf Rückmeldung zum angeforderten Update der Draytek FW von derzeit 3.8.5 auf 3.8.9.3.
Was den import von vpn.cfg unter 7.01 betrifft, da werden keine Meldungen mehr angezeigt (ausser EOF) seit die ike forward rules entfernt wurden. Allerdings bleibt im GUI sporadisch die Liste leer.
Da kann ich mir derzeit keinen Reim drauf machen. Nach Wechsel zurück auf 6.93 funktioniert sowohl import als auch vpn mit den Drayteks. Da diese Settings lt. Forums Beiträgen von beiden Partitionen gleich sein sollten,
wird die Ursache meiner Probleme an Änderungen im VPN Part von 7.01 liegen. An der VPN Konfiguration wurde in den letzten Jahren nur die Verschlüsselung geändert auf AES.

vielen Dank für bisherigen diversen Hinweise
sulihari

 

[PeterPawn]

Bei der 07.01 ist aber auch das VPN-Protokoll bei AVM merklich ausführlicher ... ein Blick sollte sich also lohnen (aber am besten nach einem Neustart und dem ersten gescheiterten Verbindungsversuch).

 

[sulihari]

Soeben konnte ich mit einem der bisher unter 7.01 nicht funktionierenden Drayteks eine VPN Verbindung aufbauen. Am Draytek 2860n+ wurde die aktuellste FW 3.8.9.3 eingespielt (bisher 3.8.5). Schlagartig sprechen beide wieder miteinander.
Mal schauen, ob es bei den 3200er Modellen auch hilft. Die change logs sind bei Draytek aber genauso "detailliert" wie bei AVM. Daraus kann man jetzt nicht erkennen, was der Grund für die "Unverträglichkeit" war.

 

[sulihari]

Mit Hilfe des AVM Supports konnte die Problematik eingegrenzt und gelöst werden. Das VPN bis 6.93 funktionierte und nach dem Update auf 7.01 nicht mehr, liegt an dem erweiterten Support der Fritzbox mit AES512 / SHA2. Die Aushandlung beginnt sinnvollerweise mit der höchsten/besten Verschlüsselung. Der Vigor 3200 unterstützt kein SHA2 und kommt bei der Aushandlung scheinbar ins straucheln. Die Lösung in diesem Fall war die Verwendung eines anderen Proposals für Phase 2. Nunmehr ist "esp-aes-sha/ah-all/comp-lzjh-no/pfs" in Verwendung.