VPN mit 7270v3/6.05 vs 7490/6.05

[sulihari]

Bevor die Frage kommt, warum wird diese veraltete FW auf der 7490 eingesetzt, hier der Hintergrund.
Es ist aktuell eine 7270v3 mit der letzten FW Version 6.05 im Einsatz, mit diversen LAN2LAN VPN Verbindungen.
Diese soll abgeloest werden durch eine 7490. Die 7490 wurde per recover image auf FW 6.24 gebracht und zum Test
per LAN 1 hinter der 7270 online genommen, da nur eine Leitung vorhanden ist.
Die VPN Definitionen wurden mit der Konfigdatei geladen, die in der 7270 funktionieren.
Soweit war alles gut. Beim Test funktionierte eine VPN Verbindung nicht (ike 2027 timeout).
Die Vergleich der Eintraege in der ipsec.cfg zeigte, das die verwendete Definition fuer Phase 2 nicht vorhanden war.
Um die Sache abzukuerzen, wurde per recover image die FW 6.05 eingespielt und die VPN Konfiguratiion erneut geladen.
Die Annahme war, FW 6.05 auf 7270 und FW 6.05 auf 7490 verhalten sich identisch.
Ein erneuter Test mit besagter VPN Verbindung funktionierte noch immer nicht. Ein Blick in das ike.log zeigt Fehler in phase1.
Danach wurden diverse Proposals versucht, ohne Erfolg. Anstelle des DynDNS Eintrags wurde die aktuelle IP verwendet.
Auch das aendert nichts. Es wurde zwischendurch auch immer wieder mit der 7270 getestet. Dort funktioniert besagte VPN
Verbindung immer sofort.
Und zuletzt wurde die 7490 direkt am DSL angeschlossen, um den Betrieb an LAN 1 als Fehlerquelle auszuschliessen.
Hat aber nichts gebracht.
Suche nach weiteren Anregungen, um die Sache einzugrenzen.

besten Dank
sulihari

 

[PeterPawn]

Der Timeout-Fehler 0x2027 kommt auf welcher Seite?

Beide Seiten sind in der Lage, die Verbindung aufzubauen? Wenn ja, macht es einen Unterschied, wenn eine auf "passiv" (also nur Responder, dazu "remotehostname" nicht eintragen) gesetzt wird? Es gibt immer wieder mal Kollisionen, wenn beide Seiten gleichzeitig die Verbindung starten wollen. Dann wird eine korrekt aufgebaut und würde eigentlich funktionieren, bis dann ein Verbindungsfehler in der anderen Richtung am Ende beide wieder abräumt.

Was steht denn in den ike.log-Files auf beiden Seiten, wenn die Verbindung nicht aufgebaut werden kann und wie unterscheidet sich das von dem ike.log der 7270v3, wo es ja sofort funktioniert? Welches "Proposal-Set" ist eigentlich überhaupt betroffen und warum verwendest Du nicht einfach ein anderes Set, das eine Einigung mit der Gegenstelle ermöglicht?

Welche Auswahl ist denn für diese spezielle Verbindung bisher aktiv (also wenn die 7270v3 die Verbindung funktionsfähig kriegt), was ist das für eine Gegenstelle und wie sieht es mit "NAT-Traversal" bei dieser Gegenstelle aus, denn solange die 7490 hinter der 7270v3 läuft, sollte das die beste Lösung sein.

Ich habe schon gelesen, daß es auch bei direktem Anschluß der 7490 ans DSL nicht funktioniert, das würde ich aber wegen der Geschichte mit den u.U. nicht passenden Proposals nicht überbewerten ... wobei dieser Fehler meiner Erinnerung nach eigentlich 0x2026 sein müßte.

 

[sulihari]

@PeterPawn

Danke fuer die Rueckmeldung. Client ist immer nur die Fritzbox. Ich habe jetzt die aktuelle remoteip anstelle des dyndns remotehost eingetragen. Im Ereignislog der 7490 wird eine fehlerhafte dyndns Aufloesung reklamiert, obwohl dyndns im vpn nicht eingetragen ist.
Die 7490 ist aktuell wieder an LAN 1 und verwendet als DNS die IP 192.168.10.1 der 7270. Aber auch wenn 8.8.8.8 als DNS eingetragen ist, kommt der Fehler. Ich kann mich an diese Meldung bei den ersten Versuchen nicht erinnern oder habe nur ike.log gelesen. Moeglicherweise ist es ein DNS Problem.
Hier mal die Konfig, welche in der 7270 problemlos funktioniert. Nochmal meine Frage zu der FW. Ist die FW 6.05 auf der 7490 ungleich zur FW 6.05 der 7270, was VPN betrifft?

{
enabled = yes;
conn_type = conntype_lan;
name = “test";
always_renew = no;
reject_not_encrypted = no;
dont_filter_netbios = yes;
localip = 0.0.0.0;
local_virtualip = 0.0.0.0;
remote_virtualip = 0.0.0.0;
remoteip = ##.###.#.###;
localid {
fqdn = “################”;
}
remoteid {
fqdn = "################";
}
mode = phase1_mode_aggressive;
phase1ss = "all/all/all";
keytype = connkeytype_pre_shared;
key = "#########";
cert_do_server_auth = no;
use_nat_t = no;
use_xauth = no;
use_cfgmode = no;
phase2localid {
ipnet {
ipaddr = 192.168.10.0;
mask = 255.255.255.0;
}
}
phase2ss = "esp-des|3des-all/ah-all/comp-no/pfs";
accesslist = "permit ip any 192.168.9.0 255.255.255.0";

ike.log 7490

2015-06-27 15:01:28 avmike:test: Phase 1 failed (initiator): IKE-Error 0x2027
2015-06-27 15:01:28 avmike:< cb_sa_create_failed(name=test,reason=IKE-Error 0x2027)
2015-06-27 15:01:58 avmike:test: Phase 1 failed (initiator): IKE-Error 0x2027
2015-06-27 15:01:58 avmike:< cb_sa_create_failed(name=test,reason=IKE-Error 0x2027)

Ereignis Log 7490:

27.06.15 15:01:28 VPN-Fehler: test, IKE-Error 0x2027
27.06.15 15:01:20 Dynamic DNS-Fehler: Fehler bei der DNS-Auflösung des Domainnamens
27.06.15 15:00:04 Dynamic DNS-Fehler: Fehler bei der DNS-Auflösung des Domainnamens

ike.log 7270

2015-06-27 15:21:25 avmike:test: Phase 2 starting (start waiting)
2015-06-27 15:21:27 avmike:test: Phase 2 ready
2015-06-27 15:21:27 avmike:< cb_sa_created(name=test,id=1,...,flags=0x00000101)
2015-06-27 15:21:27 avmike:test: start waiting connections
2015-06-27 15:21:27 avmike:test: NO waiting connections1

 

[sulihari]

In beiden Boxen war die VPN Verbindung aus Versehen aktiviert. Somit lief das VPN in Box 1 an und es gibt einen DNS Fehler. Ist korrigiert. Jetzt kommt bei Verwendung des remotehost = ###.dyndns :

015-06-27 15:52:52 avmike:test: Phase 1 failed (initiator): timeout, checking ip address
2015-06-27 15:52:52 avmike:< cb_sa_create_failed(name=test,reason=IKE-Error 0x2027)
2015-06-27 15:54:52 avmike:test: no SAs found, stopping dyndnscheck

Andere VPN Verbindungen funktionieren mit dyndns als auch mit remoteip. Dort wird allerdings nicht dyndns.org als Provider verwendet.

 

[PeterPawn]

Im Ereignislog der 7490 wird eine fehlerhafte dyndns Aufloesung reklamiert, obwohl dyndns im vpn nicht eingetragen ist.

Diese Meldungen haben mit dem VPN nichts zu tun. Du hast nur in der 7490 DynDNS aktiviert und wenn die 7490 nach der angeblich erfolgreichen Aktualisierung die vom DNS gemeldete IP-Adresse mit der 192.168.10.irgendwas vergleicht, die dort ihrer Meinung nach stehen sollte, dann stimmt das nicht überein. Die 7490 hinter der 7270 darf keinen DynDNS-Dienst verwenden, dann ist diese Meldung weg.

Solange die 7490 hinter der 7270 hängt, kann ja - ohne entsprechende Freigaben in der 7270 - die Verbindung nur von der 7490 aus gestartet werden. Sollten da Portforwardings eingerichtet sein, hast Du die mit keinem Wort erwähnt.

Die ganzen DNS-Geschichten kannst Du getrost erst einmal vergessen ...

Was ich bei den Log-Auszügen (man kann die Sparsamkeit auch übertreiben, 3 Zeilen sind kein Log-File) nicht verstehe ... woher stammt denn nun das Log von der 7270? Ist das die Gegenstelle, zu der die 7490 verbindet? Wenn sie hinter der 7270 hängt, kann sie eben keine eingehenden Verbindungen annehmen - wenn das anders ist, wäre einfach mal eine Aussage zur Konfiguration der 7270 nett ... ist die 7490 event. "exposed host"? Wenn ja, muß in der 7270 das VPN komplett deaktiviert sein, sonst wird das auch nicht weitergeleitet und landet nicht am "exposed host", sondern in der 7270.

Hier mal die Konfig, welche in der 7270 problemlos funktioniert. Nochmal meine Frage zu der FW. Ist die FW 6.05 auf der 7490 ungleich zur FW 6.05 der 7270, was VPN betrifft?

Das weiß ich nicht ... aber Du kennst doch selbst die fraglichen Stellen (schließlich schreibst Du ja von der ipsec.cfg), warum siehst Du da nicht selbst nach? Wenn sie sich entscheidend unterscheiden, dann in dieser Datei.

Aber es macht irgendwie auch wenig Sinn, mit einer bekanntermaßen alten Firmware-Version das VPN vielleicht zum Laufen zu bringen und anschließend ist der Update-Pfad bei der 7490 verstellt ... ist es da nicht schlauer, das gleich richtig mit einer aktuellen 06.24 zu machen? Da hat AVM letztens bei den Proposals ohnehin noch einmal nachgebessert.

Wenn ich die von mir gestellten Fragen noch einmal Revue passieren lasse, hast Du von denen (je nachdem, was das für Logs sind), vielleicht einen einzelnen Punkt (Unterschied Log 7270 vs. 7490) beantwortet. Weißt Du die anderen Antworten selbst nicht oder sind die irgendwie "geheim"?

Der ganze Zinnober mit DynDNS und IP-Adresse oder Remote-Hostname hat jedenfalls erst einmal mit dem Problem absolut nichts zu tun und anstelle der (wirklich nichtssagenden) Zeilen aus den ike.log-Dateien wäre mal ein ordentliches Logfile (das beginnt mit der add-Zeile und nicht irgendwo mittendrin) nett. Wenn da auf beiden Seiten eine FRITZ!Box ist, dann gibt es auch auf beiden Seiten ein Protokoll und die Frage, wer da die Verbindung aufbaut, ist auch nicht explizit beantwortet, denn die Angabe von remoteip auf der einen Seite sagt ja noch absolut nichts darüber aus, was auf der anderen Seite konfiguriert ist.

Ich dachte bisher, ich hätte Dein Problem so verstanden, daß Du eine 7270v3 mit 06.05 durch eine 7490 ersetzen willst und nun die VPN-Verbindungen, die bisher zur 7270 gingen, auf die 7490 zu übertragen sind. Und dann ist ja offensichtlich die Frage nach der Gegenstelle der einen nicht funktionierenden Verbindung nicht beantwortet, denn aus

Client ist immer nur die Fritzbox.

kann ich das beim besten Willen nicht ableiten.

Datensparsamkeit in allen Ehren, aber ohne Fakten kann man Dir bei der Übernahme der Verbindungen nicht wirklich helfen.

Die Frage, wie weit VPN bei 06.05 der 7490 von VPN bei 06.05 der 7270v3 abweicht, kann substantiell nur AVM beantworten ... nachdem die 06.05 der 7270v3 aber praktisch 1/2 Jahr nach der für die 7490 erschienen ist und schon diverse Änderungen der 06.20 für die neueren Modelle umsetzt, würde ich da nicht auf allzu große Übereinstimmungen tippen ... den Ansatz mit der Verwendung einer alten Firmware verstehe ich ja aber ohnehin nicht, schon gar nicht bei einem Router, der auf einer Seite im Internet hängt.

EDIT: Die zwischenzeitliche Ergänzung in #4 macht mich tatsächlich auch nicht schlauer. Diese Box (keine Ahnung, welche das nun ist, es steht jedenfalls nicht da) hält sich ja selbst für den Initiator der Verbindung. Wenn da die andere Seite nicht antwortet (das liest sich - wieder nur drei Zeilen, so daß man nur raten kann - aber tatsächlich so, als ob der IKE-Daemon die Remote-Adresse nicht auflösen kann, was mit einem beherzten nslookup sicherlich zu klären wäre), kann das ja eigentlich nur daran liegen, daß die Anfrage nicht ankommt.

 

[sulihari]

@PeterPawn
Auf Clientseite habe ich zum Testen eine 7270v3 am ADSL, dahinter eine 7490 an LAN 1. Diese hat keinerlei DYNDNS Client Eintraege. Server ist ein Draytek Vigor 2200E plus.
Verbindungen werden immer nur von Clientseite aufgebaut. Da das bisher immer mit verschiedensten Clients funktioniert hat, habe ich den Fehler erstmal auf Clientseite gesucht.
Hier das Log nach Reboot der 7490 mit einer gueltigen remoteip in der VPN Config (mehr steht nicht drin):

1970-01-01 01:00:48 avmike:< add(appl=dsld,cname=iPhone ,localip=192.168.10.22, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0
1970-01-01 01:00:48 avmike:new neighbour iPhone : dynamic user nat_t
1970-01-01 01:00:48 avmike:< add(appl=dsld,cname=test,localip=192.168.10.22, remoteip=##.###.#.###, p1ss=all/all/all, p2ss=esp-des|3des-all/ah-all/comp-no/pfs p1mode=4 keepalive_ip
1970-01-01 01:00:48 avmike:new neighbour test:

Da sich andere VPN Verbindungen in dieser Konstellation von der 7490 aus aufbauen lassen, frage ich hier nach Hilfe. Ohne Verbindung kann ich aktuell kein Log auf der Serverseite einsehen.

 

[PeterPawn]

Diese hat keinerlei DYNDNS Client Eintraege.

Das ist sicher? Die Meldung aus #3 sagt etwas anderes aus:

27.06.15 15:01:20 Dynamic DNS-Fehler: Fehler bei der DNS-Auflösung des Domainnamens

Das bezieht sich eindeutig nicht auf die VPN-Verbindung (woher soll der AVM-IKE denn auch wissen, ob es sich um eine dynamische oder eine statische Angabe handelt, wenn man in der VPN-Konfiguration "remotehostname" verwendet) und es ist mit nahezu 100%iger Sicherheit (wenn die 06.05 da nicht einen Riesen-Bug hatte) ein aktiver DynDNS-Client der FRITZ!Box (es kann natürlich auch der MyFRITZ!-Client sein, das ist ja prinzipiell dasselbe in Bezug auf DynDNS).

Server ist ein Draytek Vigor 2200E plus. Verbindungen werden immer nur von Clientseite aufgebaut.

Und einer der Clients für den Vigor ist dann Deine FRITZ!Box ... soweit richtig?

Wenn Du dann schreibst

Da das bisher immer mit verschiedensten Clients funktioniert hat, habe ich den Fehler erstmal auf Clientseite gesucht.

bezieht sich das also auf die 7490, wenn Du von "Clientseite" schreibst? Die 7490 nimmt also keine eingehenden IPSec-Verbindungen an und baut sie nur ausgehend selbst auf, auch richtig?

1970-01-01 01:00:48 avmike:< add(appl=dsld,cname=iPhone ,localip=192.168.10.22, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/no-pfs p1mode=4 keepalive_ip=0

Offenbar ist die 7490 hier ja der Meinung, daß noch gar keine Internetverbindung besteht (zumindest hat sie keinen NTP-Server gefunden und keine Zeit gesetzt) ... da wäre es nicht sooo überraschend, wenn sie auch keine ausgehende VPN-Verbindung aufbaut (das iPhone ist ja sicherlich ohnehin eine eingehende Host-LAN-Verbindung).

Außerdem gibt es mit der Konfiguration aus #3 für die FRITZ!Box keinen Grund, eine IPSec-Verbindung aufzubauen, solange kein Traffic bei ihr aufschlägt, der dorthin zu übertragen wäre. Das ist eben eine "on demand"-Verbindung und da braucht es schon Traffic in Richtung der Gegenstelle. Da sind die 4 Zeilen im Log dann nicht so überraschend ... erst einmal die Internet-Verbindung aufbauen und dann Traffic in Richtung des Vigors erzeugen, dann steht auch etwas im Logfile.

Da sich andere VPN Verbindungen in dieser Konstellation von der 7490 aus aufbauen lassen, frage ich hier nach Hilfe. Ohne Verbindung kann ich aktuell kein Log auf der Serverseite einsehen.

Und hier bin ich beim ersten Satz dann wieder total verloren ... das lese ich jetzt so, daß die 7490 mit anderen Gegenstellen (das werden ja nicht auch alles Vigor 2200E sein) Verbindungen aufbauen kann, aber mit dem Vigor nicht. Das von Dir gepostete Log-Stückchen zeigt das aber gar nicht, daß die Verbindung fehlschlägt ... es zeigt (ich meine jetzt #6, bei #3 weiß ich immer noch nicht so richtig, wer da wer ist) eben gar keine VPN-Aktivität, damit auch keinen Fehler. Was sind denn das ansonsten so für Gegenstellen, zu denen die 7490 (wenn sie denn eine Internetverbindung hat) erfolgreich verbinden kann?

Und die Argumentation, daß Du auf den Server ohne VPN-Verbindung nicht zugreifen kannst, kann ich noch nachvollziehen ... warum Du das dann aber nicht einfach mit der 7270 machst und dort dann bis zum Verbindungsversuch der 7490 im Log zurück gehst, verstehe ich wieder nicht.

Am Schluß stellt sich dann noch die Frage, was der Vigor eigentlich an alternativen Proposals noch beherrschen würde, denn (im schlechtesten Fall) DES mit MD5 ist ja hoffentlich nicht wirklich ernst gemeint. Leider finde ich im Internet dazu nichts ... aber Du wirst die Frage ja sicherlich beantworten können. Wenn ich es richtig verstanden habe, hindert Dich ja nur die fehlende Verbindung am administrativen Zugriff auf den Vigor und nicht mangelnde Rechte.

EDIT: Auch die Ergänzung in #5 (nslookup auf der 7490 für den Namen des Vigor) bitte nicht überlesen ... wir schreiben hier etwas verschachtelt, da geht so etwas schon mal unter.

 

[sulihari]

@PeterPawn

Richtig die 7490 soll nur als Client VPN aufbauen. Bevor eine 7270 damit abgeloest wird, sollte aber auch alles funktionieren. Die Liste der Verbindungen enthielt insgesamt 6 Gegenstellen plus ein iPhone eingehend.
Diese Liste habe ich im Verlauf des Tests immer weiter gekuerzt. Das iPhone war bnoch drin. Daher auch das Missverstaendnis. Die funktionierenden Verbindungen ausgehend laufen gegen neuere Draytek 2860 bzw. 2750. Diese koennen auch AES256
Der Draytek 2200E-plus ist recht alt und kann sicher nicht mit allen aktuellen Proposals umgehen. Moeglicherweise muss er ausgewechselt werden. Die letzte mir vorliegende Verbindungsinformation von einer 7270v3 zeigt auf Draytek Seite:

IPSec Tunnel
3DES-SHA1 Auth

Die ipsec.cfg der 7490 mit FW 6.05 enthaelt die verwendeten Proposals, die im Aufruf stehen. Das hatte ich bereits geprueft.
Deshalb wundert mich das Verhalten um so mehr. Der Hinweis im Draytek mal nach den moeglichen Verbindungsoptionen zu schauen, erscheint vernuenftig.
Sollte es aber partout nicht funktionieren, wird er wohl ausgetauscht werden muessen.

vielen Dank
sulihari

 

[PeterPawn]

3DES-SHA1 Auth

Ok, dann ist der alles entscheidende Unterschied offenbar ja das 3DES.

Die ipsec.cfg der 7490 mit FW 6.05 enthaelt die verwendeten Proposals, die im Aufruf stehen. Das hatte ich bereits geprueft.

Irgendwann gab es in der Firmware mal einen "off by one"-Fehler (so konnte man jedenfalls vermuten), der den ersten Algorithmus in der Liste unbrauchbar machte.

BTW: Was mir bei der Gelegenheit einfällt als definitiver Unterschied des VPN der 7490 von 06.0x nach 06.20 ... es wurden zusätzliche DH-Gruppen implementiert, die es vorher noch nicht gab, was natürlich auch Auswirkungen auf den Aufbau/Inhalt der ipsec.cfg hat. Das alte "dhgroup=def;" steht m.W. für DH-Group 2. Aber das nur als Einschub ...

Tatsache ist jedenfalls, daß das von der 7270v3 verwendete 3DES/SHA1 in den jeweiligen Sets für P2 immer der erste Eintrag ist, wenn ich das richtig sehe. Wobei auch das ja Stochern im Nebel ist, solange gar nicht geklärt ist, in welcher Phase denn die Verbindung stecken bleibt ... wenn es sicher die Transform-Sets sind, dann würde ich es mal mit "def/all/all" in der 7490 (06.05) versuchen für P1 und mit "esp-all-all/ah-all/comp-all/pfs" für P2. Wenn der Vigor dann mit einer zu langen Liste an Proposals für P2 nicht klarkommt (die ist wirklich ellenlang), dann kann man da immer noch "esp-all-all/ah-none/comp-all/pfs" oder auch "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs" nehmen, AH+ESP wäre ohnehin eher ungewöhnlich. Bei den möglichen Sets gibt es ja mehrere Möglichkeiten, vielleicht findest Du ja ein passendes, wo das vom Vigor verstandene 3DES/SHA1 nicht unbedingt der erste Eintrag der Liste ist.

Wenn Du ganz normal die 7490 neu startest (vor dem Neustart die Verbindung zum 2200E aktivieren, damit das nicht anschließend erst erfolgen muß, da das mit einem Neustart des avmike verbunden wäre) und nachdem definitiv die Internet-Verbindung der 7490 steht, das ike.log noch einmal ansiehst, dann müßte da ja irgendetwas zum Verbindungsaufbau drinstehen. Notfalls kannst Du die Verbindung ja durch das Hinzufügen eines "keepalive_ip"-Parameters in der Konfiguration der 7490 von "on demand" auf "always on" stellen, wenn Du keinen Traffic hast, der die Verbindung aufbauen würde.

Wenn man dann weiß, ob es tatsächlich die Namensauflösung ist oder nicht ... oder ob P1 schief geht (i.d.R. kann dann der richtige Verbindungseintrag nicht gefunden werden im "aggressive mode") ... oder ob es tatsächlich erst P2 ist, wo man sich nicht einigen kann (da steht dann ggf. die Frage nach Kompression und ESP/AH oder nur ESP im Raum), dann kann man gezielter suchen und die richtigen Parameter modifizieren.

Zusätzlich bleibt bei der derzeitigen Konstellation (7490 hinter der 7270v3) aber tatsächlich auch noch die Frage übrig, ob der Vigor 2200E überhaupt mit NAT-T umgehen kann. Solange die 7490 hinter der 7270v3 hängt (und nicht "exposed host" bei komplett deaktiviertem VPN der 7270v3 ist), müßte die 7270v3 ansonsten ESP-Passthrough machen. Anders als TCP oder UDP gibt es eben bei ESP keine Ports und damit kann es nur eine einzelne ESP-Verbindung durch einen Router geben, wenn man IPSec mit UDP 500 und ESP nutzt. Genau für solche Situationen wurde ja NAT-T spezifiziert, dabei werden die ESP-Pakete ihrerseits wieder in UDP-Pakete verpackt (dann wird Port 4500 am Server verwendet), deren Header dann die Router auf dem Weg problemlos wieder anpassen dürfen, weil sie nicht zum gesicherten Payload gehören.

Insofern lohnt sich tatsächlich der Versuch mit der 7490 direkt am DSL eher ... aber erst dann, wenn man sich sicher sein kann, daß es nicht aus anderen Gründen in P1/P2 scheitern sollte bzw. daß wenigstens die Pakete auf UDP 500/4500 auch auf der Gegenseite ankommen, denn ein Timeout-Fehler ist in den meisten Fällen dann eben doch das Rufen in den Wald, ohne daß es wieder heraus schallt.

 

[sulihari]

@PeterPawn

Ich habe die Liste der Vorschlaege abgearbeitet, leider ohne Erfolg. Es sieht so aus, als ob die HW/Software Konstellation nicht funktioniert. Testweise habe ich an LAN 1 jetzt mal eine 7170, 7270v2, und eine 7390 angeschlossen.
Damit lade ich die VPN Konfiguration und es funktioniert auf Anhieb mit allen 3 Boxen.
Nochmals vielen Dank fuer die Unterstuetzung.

sulihari

 

[sulihari]

@PeterPawn

Nachdem die ganzen Tests kein Ergebnis gebracht hatten, habe ich die aktuelle FW 6.24 eingespielt alles auf Werkseinstellung gesetzt und nochmal die vpn.cfg mit den zur FW passenden Proposals geladen.
Danach funktionierte es erwartungsgemäss nicht. Alle Tests wurden immer an den LAN Ports der 7490 gemacht, WLAN aus. Durch Zufall habe ich WLAN angeschaltet und eher aus Versehen einen Versuch mit der problematischen
VPN Konfiguration gemacht. Und siehe da, es hat sofort funktioniert. Jetzt war das Interesse geweckt. Der Test mit LAN danach funktionierte nicht. Das Ganze war reproduzierbar. WLAN+VPN geht, LAN+VPN geht nicht.
Da die Firewall auf Linux und 7490 Seite unangetastet war, habe ich nach den Ports geschaut. Diese stehen per default auf Gb für LAN 1 und 100 Mb für LAN2-4. Da die Endgeräte GB können wurde alle Ports kurzerhand auf GB gestellt.
Ergebnis unverändert. Nachdem jetzt alle Ports auf 100 Mb stehen, startet das VPN wie erwartet. Ergänzend noch der Hinweis, alles andere hat Netzwerktechnisch prima funktioniert (Zugriff auf die GUI der FB, Internet usw.)
Daher bestand auch kein Verdacht. Und der Fehler im VPN in phase 1 ist somit auch zu erklären.

sulihari

 

[PeterPawn]

Nochmal ganz deutlich "zum Mitmeißeln" ... wenn das WLAN der FRITZ!Box eingeschaltet(!) wird (und nicht wenn eine FRITZ!Box per WLAN an einer anderen hängt, die 7490 ist schon direkt am DSL, oder?), dann funktionieren VPN-Verbindungen, die 3DES und SHA einsetzen. Ist das WLAN der Box deaktiviert, funktioniert auch das VPN nicht (AES schon, 3DES eben nicht)?

Das klingt dann zwar nach einem Problem mit irgendwelchen Libs, aber wenn sich das tatsächlich reproduzieren läßt, wäre das schon ein sehr meldenswerter Fehler.

Wenn alle LAN-Ports auf 100 MBit/s festgetackert sind, geht es aber auch, unabhängig vom WLAN-Status? Irgendwie fehlt mir hier etwas der Zusammenhang ... aber da die Libs alle ge"strip"t sind, kann da nur AVM selbst debuggen.

 

[sulihari]

@PeterPawn

Die 7490 musste zum Test wieder an LAN 1 hinter die 7370, da der vorhandene VOIP Anschluss zum Telefonieren gebraucht wird.
Ich hatte den Verbindungsaufbau immer manuell per Ping in das Netz hinter dem VPN Server aufgebaut.
Mit dem Vorschlag, per keep alive via Konfig Datei die Verbindung aufbauen zu lassen, waere ich wohl schneller hinter das Problem gekommen.
Ich kann das jetzt nochmal in Ruhe nachstellen und mit mehreren, verschiedenen Endgeraeten und Kabeln testen.
Es koennte aber auch sein, das die 7490 ein HW Problem hat. Das muss ein spaeterer Test mit einer zweiten 7490 zeigen.
Sollte es auch an einer anderen Box reproduzierbar sein, geht eine Meldung an AVM raus.

sulihari