FRITZ!Box 7390 - nach Update auf Fritz!OS 6.30 kein VPN Aufbau möglich

[MMark]

Hallo zusammen,

seit dem Update auf 6.30 bricht der Aufbau der VPN-Verbindung mit dem Shrew-Client in Phase 1 ab:

16/04/03 18:35:26 -> : send IKE packet 192.168.xxx.xxx:500 ->       91.248.xxx.xxx:500 ( 613 bytes )
16/04/03 18:35:26 DB : phase1 resend event scheduled ( ref count = 2 )    
16/04/03 18:35:26 DB : phase1 ref decrement ( ref count = 1, obj count =       1 )    
16/04/03 18:35:31 -> : resend 1 phase1 packet(s) [0/2]       192.168.xxx.xxx:500 -> 91.248.xxx.xxx:500    
16/04/03 18:35:36 -> : resend 1 phase1 packet(s) [1/2]       192.168.xxx.xxx:500 -> 91.248.xxx.xxx:500    
16/04/03 18:35:41 -> : resend 1 phase1 packet(s) [2/2]       192.168.xxx.xxx:500 -> 91.248.xxx.xxx:500    
16/04/03 18:35:46 ii : resend limit exceeded for phase1 exchange    
16/04/03 18:35:46 ii : phase1 removal before expire time    
16/04/03 18:35:46 DB : phase1 deleted ( obj count = 0 )    
16/04/03 18:35:46 DB : tunnel ref decrement ( ref count = 1, obj count =       1 )    
16/04/03 18:35:46 DB : policy not found    
16/04/03 18:35:46 DB : policy not found    
16/04/03 18:35:46 DB : policy not found    
16/04/03 18:35:46 DB : policy not found    
16/04/03 18:35:46 DB : removing tunnel config references    
16/04/03 18:35:46 DB : removing tunnel phase2 references    
16/04/03 18:35:46 DB : removing tunnel phase1 references    
16/04/03 18:35:46 DB : tunnel deleted ( obj count = 0 )    
16/04/03 18:35:46 DB : peer ref decrement ( ref count = 1, obj count = 1       )    
16/04/03 18:35:46 DB : removing all peer tunnel references    
16/04/03 18:35:46 DB : peer deleted ( obj count = 0 )    
16/04/03 18:35:46 ii : ipc client process thread exit ...

Ist dies ein bekanntes Thema? Gibt es dazu eine Lösung? Gibt es Informationen darüber, welche Änderungen konkret an der VPN-Funktionalität in der Version 6.30 durchgeführt wurden? Ich konnte leider bisher keine aufschlussreichen Changelogs oder etwas vergleichbares finden.

Dank vorab!

Mark

 

[informerex]

ich würde an der .30 nicht mehr herumdoktern, geh doch auf die http://avm.de/fritz-labor/labor-fuer-fritzbox-7390/uebersicht/ und löse sodann dort deine Probs, soweit noch vorhanden.

 

[MMark]

@informerex,

Danke für die Rückmeldung. Die Box ist allerdings gebrandet und die Version 6.30 ist diejenige, die aktuell vom Netzbetreiber zur Verfügung gestellt wird. Ich hatte zuletzt langwierige Probleme mit der DLS-Verbindung und bin froh, dass es derzeit stabil läuft. Ich überblicke derzeit nicht wirklich die Konsequenzen, wenn ich eine Version einspiele, die vom Netzbetreiber nicht zur Verfügung gestellt wird.

Gibt es einen konkreten Hinweis dazu, dass die 6.30 Probleme mit der VPN-Verbindung hat, die in der Laborversion behoben sind?

VG

Mark

 

[amatör]

Von welchem Netzbetreiber ist denn die Rede?

 

[MMark]

EWE Tel

Danke.

 

[amatör]

Und die verweigern den Service, wenn die Firmware auf der aktuellen Version ist?

Ansonsten mal VPN löschen und neu anlegen (nach einem Backup natürlich) oder hast du das schon probiert?

 

[MMark]

VPN löschen und neu anlegen habe ich probiert. Ohne Erfolg.

 

[amatör]

Hm. Dann kann ich nur sagen, dass ich mit der 6.30 keine VPN-Probleme hatte. Bin aber schon länger auf die Laborversion gegangen wegen anderer Probleme.

 

[Micha0815]

@MMark
kannst Du mal Deine VPN.cfg (gekürzt um Keys+Co) posten?
Da ich seit Wochen mit unterschiedlichen FBs probe, würde ich gerne vergleichen

z.B. kommt die Anweisung

editable = yes;

falls vorhanden nicht gut! ... besser komplett löschen

LG

 

[qwertz.asdfgh]

Und die verweigern den Service, wenn die Firmware auf der aktuellen Version ist?

Ver. 6.30 ist die aktuelle Version für die 7390. Informerex schlägt eine Laborversion vor und das kann ich im übrigen selbst nicht richtig nachvollziehen einem "x-beliebigem" einfach so eine Laborversion zu empfehlen, aktuell ist eben derzeit noch Ver. 6.30. Daher erst einmal Beitrag #2 besser vergessen...

 

[informerex]

@qwertz.asdfgh
wo ist dein Lösungs-Voschlag, weil diesen kann ich nicht ausmachen - also dass du was sinnvolles dem T. beigtragen hast.
(für mich ist nicht nachvollziehbar, warum du "... besser vergessen" geäußert hast - wobei mich das auch weniger interessiert, weil das dem Thread-Starter nicht hilft)

Damit mein post aber auch für dich nachvollziehbar ist, möchte ich vorab anmerken, dass ich kein freetz o.ä. empfohlen hab.
Lt. #1 (bzw. Header) hat VPN bisher funktioniert, nach Update auf die .30 (final) bricht die Leitung zusammen bzw. funktioniert nicht mehr. Als Sofortmaßnahme bleibt sodann auf die vorherige FW oder eben auf die "neue" welche im Labor eingebracht wurde. Diese ist offiziell freigegeben und hat auch kein alpha-Status o.ä. sondern dürfte sich kurz vor final befinden, also eher rc-Status.

Alternativ könnte man natürlich auch ein KKK vermuten und die Konfig. manuell neu aufbauen lassen.

Dass die Box ein branding hat, war bisher unbekannt. (wobei dies für andere EWE-User jedoch kein Hindernis war/ist)

 

[qwertz.asdfgh]

@informerex
Wenn eindeutig klar wäre, dass das Problem des TE mit einer Labor-Version gelöst sein sollte könnte ich das noch nachvollziehen. Ist das denn so? Wenn ja, warum wurde das nicht erwähnt?

Aber wenn man kommentarlos eine Laborversion empfiehlt ohne die Fähigkeiten des Gegenübers zu kennen dann betrachte ich das genauso wenig als Lösungsvorschlag oder sinnvollen Beitrag zum Problem wie du meinen Beitrag dbzgl. anerkennst. Von daher könnte ich auch die Gegenfrage stellen, wo ist dein sinnvoller Beitrag zur Lösung des Problems?

Mag sein, dass du die aktuelle Labor-Version als RC betrachtest aber offiziell ist das seitens AVM so nicht kommuniziert. Und selbst ein RC ist auch nur ein RC und noch nicht unbedingt ein Final-Release.
Beta- und RC-Versionen sind imo nun mal eben nichts für jedermann und haben insb. in produktiven Umgebungen m.E. nichts zu suchen.

Insb. dann wenn der eher ungeübte Nutzer anschließend vor dem Problem steht wieder eine offiziell unterstützte Version aufzuspielen, vor allem dann wenn auf der Box evtl. auch noch ein Provider-Additive vorh. ist (das anschließende Gejammer konnte man hier im Forum schon öfter vernehmen). Von daher kann man ruhig erst einmal von einem sogenannten "KKK" ausgehen wie du es nennst (und auch einige andere hier im Forum).

Ausnahmen gibt es immer, wenn z.B. eine Betaversion (auf die schnelle) ein bekanntes Problem löst. Ich weiß auch, dass die VPN-Implementierung in FritzOS 6.30 nicht perfekt ist aber dennoch wäre es vielleicht ersteinmal nicht schlecht der Ursache des Problem, welches der TE hat, auf den Grund zu gehen. Eine "saubere" Konfiguration würde ich da als erstes angehen anstatt einer Laborversion, eine aktuellere Releaseversion gibt es ja (noch) nicht.

Und bzgl. "freigegeben", auf der AVM-Webseite steht u.a. unmissverständlich:

Diese Laborversion hat Betastatus . ...
...
AVM leistet für diese Laborversion keine technische Unterstützung (Support).

 

[MMark]

@all

Sorry für die späte Rückmeldung. Ich konnte mich zwischenzeitlich nicht um das Thema kümmern.

@Micha0815

Anbei die .cfg in einer 'einfachen' Version. Ich habe micht damals langsam an eine umfangreichere Konfiguration herangetastet. Dies war der erste Schritt und hat in dieser Form auch funktioniert. Ich habe heute alle vorhergehenden Konfigurationen der guten Ordnung halber noch einmal ausprobiert - alle zeigen den obigen Abbruch.

vpncfg {
        connections {
                enabled = yes;
                editable = no;                                    
                conn_type = conntype_user;                        
                name = "VPN-Benutzerzugang xxx";            
                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 = 192.168.178.xxx;
                remoteid {
                        user_fqdn = "xxx@fritzbox";         
                                                                
                }
                mode = phase1_mode_aggressive;                    
                phase1ss = "all/all/all";                        
                keytype = connkeytype_pre_shared;               
                key = "xxx";        
                cert_do_server_auth = no;                        
                use_nat_t = yes;
                use_xauth = no;                                
                use_cfgmode = no;                                 
                phase2localid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipaddr = 192.168.178.xxx;
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";    
                accesslist = 
                             "permit ip 192.168.178.0 255.255.255.0 192.168.178.xxx 255.255.255.255", 
                             "permit ip any 192.168.178.xxx 255.255.255.255";
        }
        ike_forward_rules = "udp 0.0.0.0:500 0.0.0.0:500", 
                            "udp 0.0.0.0:4500 0.0.0.0:4500";
}

// EOF

 

[PeterPawn]

Als Gegenstück dazu braucht es auch noch die Daten aus der ike.log in den Support-Daten der FRITZ!Box. Dort müßte dann eine passende eingehende Nachricht vom Shrewsoft-Client zu sehen sein. Dem Protokoll in #1 nach würde ich am ehesten sagen, daß da kein einziges Paket bei der Box angekommen ist bzw. genauer, daß keine einzige Antwort der FRITZ!Box ankam, wenn es eine gegeben haben sollte.

Das kann von einer falschen Adresse der Box wegen eines nicht erfolgten DynDNS-Updates bis zum "Unverständnis" der FRITZ!Box ob des eingehenden Requests so ziemlich alles sein, deshalb muß man auch das auf der einen Seite Gesendete mit den auf der anderen Seite empfangenen Inhalten vergleichen. Dazu braucht es die zeitgleichen Protokolle beider Seiten, am besten nach jeweiligem Neustart und mit korrekter Uhrzeit (auch auf beiden Seiten).

BTW .. zum "Herantasten": Das Ergebnis in #13 beim "accesslist"-Eintrag ist eine Tautologie, der zweite Eintrag schließt sämtliche möglichen Pakete ein, für die auch die erste Regel gilt. Ohne weitere Angaben (z.B. andere Regeln zwischen diesen beiden) ist die erste also überflüssig.

Es ist jedenfalls in #1 noch nichts zu sehen, was nur im Entferntesten auf eine mögliche Ursache in der Firmware-Version hinweisen würde (das wären dann z.B. inkompatible Einstellungen bei den Proposals - das sind die "Vorschläge", welche Verschlüsselungsalgorithmen beide Seiten benutzen könnten) ... der Client kriegt schlicht keine Antwort und sendet seinen ersten Request 4x, bevor er einsieht, daß es ein Monolog ist und seinerseits aufgibt. Das dürfte auch eher auf "Gegenstelle antwortet nicht" als Fehlermeldung hinauslaufen als auf eine andere.

 

[MMark]

@PeterPawn,

danke für die Rückmeldung und insbesondere für die Erläuterungen, die ich soweit verstanden haben.

Ich habe gerade ohne Erfolg über Telnet versucht, die ike.log zu bekommen. Ein Verbindungsaufbau ist nicht möglich, obwohl ich nach dem Code #96*7* eine entsprechende Quittierung bekomme. In älteren Versionen hatte dies funktioniert. Soweit mir bekannt ist, sollte dies auch mit der vorliegenden Version 6.30 noch möglich sein - allerdings sprechen wir hier über eine gebrandete EWE-Version.

Gibt es einen anderen gangbaren Weg um mit vertretbarem Aufwand eine Analyse durchzuführen? Wireshark?

VG
Mark


EDIT:

Ich habe mir mal die Möglichkeiten unter http://fritz.box/html/capture.html angesehen:

1. Internetverbindung
2. Internetverbindung
3. Internetverbindung
4. Internetverbindung
Schnittstelle 0 ('internet')
Schnittstelle 1 ('voip')
Schnittstelle 2 ('tr069')
Schnittstelle 3 ('iptv')
Routing-Schnittstelle

Mir erschließt sich nicht der Unterschied zwischen den erste 5 Punkten und ob darüber der externe Verkehr 'logbar' wäre.

 

[koyaanisqatsi]

Moins


Vielleicht taucht da was in den Supportdaten auf?

 

[MMark]

So, ich werde jetzt hier den ganz großen Kotau machen. Das Problem ist gelöst - es lag letztendlich an der nicht eingerichteten DynDNS Verbindung. Hintergrund ist die Geschichte hier:

http://www.ip-phone-forum.de/showthread.php?t=284667

Ich habe mir mit Wireshark den Verkehr auf "Schnittstelle 0 ('internet')" angeschaut und festgestellt, dass letztendlich gar nichts ankommt. Dann war recht schnell klar, was nicht stimmt.

Was mich vollkommen irritiert hat waren die Fehlermeldungen im Protokoll des Shrew-Clients. "Policy not found" bedeutete für mich, dass der Shrew-Client zumindest einmal einen Versuch unternehmen konnte, die Policy festzustellen. Das ursächlich nicht einmal eine Verbindung bestanden hat, diese Transferleistung war mir nicht möglich.

Trotz dieser blöden Geschichte: vielen Dank für's Mitdenken.

VG

Mark

 

[Micha0815]

Schön wenn es dann geklappt hat?

Da ich neulich eine entfernte FB7240 mit einer neuen cfg bestückt habe - als jmd. anwesend und nicht nur remote- hatte ich festgestellt nach langer Ursachen-Forschung, dass die simple Zeile

editable = no/yes;

bei älteren FBs respektive FWs zu Fehlermeldungen führt. Beim Erstellen/Editieren sucht man erst an anderen neuralgischen Stellen wg. Leerzeichen ö.ä, bevor das auffällt

LG
[/CODE]