[Gelöst] VPN-Tunnel: Zugriff auf Fritz!Box mit NCP-Client funktioniert nicht

[igel_igel]

Liebe Forenteilnehmer,

ich möchte eine Verbindung zwischen meinem Laptop mit installiertem NCP-Client und meiner Fritz!Box aufbauen - bislang leider ohne Erfolg.

Dabei bin ich exakt nach der Anleitung von NCP vorgegangen:
https://www.ncp-e.com/fileadmin/pdf/handbuecher/NCP_Entry_Client_AVM_FRITZ_Box_v2.pdf


Detailangaben:

- Laptop mit Windows7 x64
- Secure Enterprise Client Version 9.32 Build 218
- AVM Fritz!Box 7390 mit Fritz!OS 06.20


Anbei unter dem Spiegelstrich das Fehlerlog des Clients - ich hoffe, es hilft Euch - ich bin leider zu wenig Experte, um es auszuwerten.

Habe bereits stundenlang alle möglichen Kombinationen ausprobiert - leider ohne Erfolg.

Alternativ hatte ich auch schon einmal eine Konfiguration gemäß einer Website von AVM ausprobiert - leider ebenfalls ohne Erfolg:
http://bluefritz.eu/de/Service/Serv...l/VPN_Interoperabilitaet/15591.php?portal=VPN
In der genannten Anleitung findet sich auch eine Beispiel-Konfig-Datei, die ich auf den Server hochgeladen habe und aus der viele (hoffentlich genügend) IPSec-Parameter hervorgehen:
http://bluefritz.eu/de/Service/FAQs/FAQ_Sammlung/images/FRITZBox_NCP.pdf

Jetzt weiß ich wirklich nicht mehr weiter und es wäre sehr nett, wenn Ihr mir helfen könntet.

Viele Grüße

igel_igel



---------------------------------------------------------------------------------------------------------------

Einträge mit "###" sind von mir anonymisiert worden



09.01.2015 21:03:51  IPSec: Start building connection

09.01.2015 21:03:51  IPSec: DNSREQ: resolving GW=<pf6ad3zbeo5nvjnk.myfritz.net> over lan:

09.01.2015 21:03:51  IPSec: DNSREQ resolved vpn ipadr=91.61.###.###

09.01.2015 21:03:51  IpsDial: connection time interface choice,LocIpa=192.168.##.###,AdapterIndex=201

09.01.2015 21:03:51  Ike: Outgoing connect request AGGRESSIVE mode - gateway=91.61.###.### : ncpac3

09.01.2015 21:03:51  Ike: XMIT_MSG1_AGGRESSIVE - ncpac3

09.01.2015 21:03:52  Ike: NOTIFY : ncpac3 : RECEIVED : NOTIFY_MSG_S_RESPONDER_LIFETIME : 24576

09.01.2015 21:03:52  Ike: Remote is reducing IKE lifetime to 3600 seconds for connection <ncpac3>

09.01.2015 21:03:52  Ike: RECV_MSG2_AGGRESSIVE - ncpac3

09.01.2015 21:03:52  Ike: IKE phase I: Setting LifeTime to 86400 seconds

09.01.2015 21:03:52  Ike: Turning on XAUTH mode - ncpac3

09.01.2015 21:03:52  Ike: IkeSa negotiated with the following properties -

09.01.2015 21:03:52  IPSec: Final Tunnel EndPoint is=91.61.###.###

09.01.2015 21:03:52    Authentication=XAUTH_INIT_PSK,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=256

09.01.2015 21:03:52  Ike: ncpac3 ->Support for NAT-T version - 9

09.01.2015 21:03:52  Ike: Turning on NATD mode - ncpac3 - 1

09.01.2015 21:03:52  Ike: XMIT_MSG3_AGGRESSIVE - ncpac3

09.01.2015 21:03:52  Ike: IkeSa negotiated with the following properties -

09.01.2015 21:03:52    Authentication=XAUTH_INIT_PSK,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=256

09.01.2015 21:03:52  Ike: Turning on DPD mode - ncpac3

09.01.2015 21:03:52  Ike: phase1:name(ncpac3) - connected

09.01.2015 21:03:52  SUCCESS: IKE phase 1 ready

09.01.2015 21:03:52  IPSec: Phase1 is Ready,AdapterIndex=201,IkeIndex=36,LocTepIpAdr=192.168.##.###,AltRekey=1

09.01.2015 21:03:52  IkeXauth: RECV_XAUTH_REQUEST

09.01.2015 21:03:52  IkeXauth: XMIT_XAUTH_REPLY

09.01.2015 21:03:52  IkeXauth: RECV_XAUTH_SET

09.01.2015 21:03:52  IkeXauth: XMIT_XAUTH_ACK

09.01.2015 21:03:52  IkeCfg: name <ncpac3> - IkeXauth: enter state open

09.01.2015 21:03:52  SUCCESS: Ike Extended Authentication is ready

09.01.2015 21:03:54  IkeCfg: XMIT_IKECFG_REQUEST - ncpac3

09.01.2015 21:03:54  IkeCfg: RECV_IKECFG_REPLY - ncpac3

09.01.2015 21:03:54  IkeCfg: name <ncpac3> - enter state open

09.01.2015 21:03:54  SUCCESS: IkeCfg ready

09.01.2015 21:03:54  IPSec: Quick Mode is Ready: IkeIndex=36,VpnSrcPort=10954

09.01.2015 21:03:54  IPSec: Assigned IP Address: 192.168.63.202

09.01.2015 21:03:54  IPSec: Gateway IP Address: 0.0.0.0

09.01.2015 21:03:54  IPSec: Primary DNS Server: 192.168.63.1

09.01.2015 21:03:54  IPSec: Secondary DNS Server: 0.0.0.0

09.01.2015 21:03:54  IPSec: Primary WINS Server: 0.0.0.0

09.01.2015 21:03:54  IPSec: Secondary WINS Server: 0.0.0.0

09.01.2015 21:03:54  IPSec: Primary NCP SEM Server: 0.0.0.0

09.01.2015 21:03:54  IPSec: Secondary NCP SEM Server: 0.0.0.0

09.01.2015 21:03:54  IkeQuick: XMIT_MSG1_QUICK - ncpac3

09.01.2015 21:04:13  Ike: NOTIFY : ncpac3 : SENT : NOTIFY_MSG_R_U_HERE : 36136

09.01.2015 21:04:13  Ike: NOTIFY : ncpac3 : RECEIVED : NOTIFY_MSG_R_U_HERE_ACK : 36137

09.01.2015 21:04:14  IkeQuick: phase2:name(ncpac3) - error - cleared by phase1

09.01.2015 21:04:14  ERROR - 4037: IKE(phase2):Waiting for message2, cleared by phase1 - ncpac3.

09.01.2015 21:04:14  IpsDial: From Ikemgr - Remote is denied request for an IPSec SA, AdapterIndex=201

09.01.2015 21:04:14  IPSec: Disconnected from ncpac3 on channel 1.

 

[PeterPawn]

Tja, auch nach längerer Wartezeit antwortet kein anderer, dann dränge ich mich wieder auf.

Anhand des (NCP-)Protokolls könnte man auf eine funktionierende VPN-Verbindung für die Dauer von 19 Sekunden schließen, bis das erste Keepalive-Paket (R_U_HERE-Message) sogar noch beantwortet wurde, wenn das "RECEIVED : NOTIFY_MSG_R_U_HERE_ACK" stimmt. Aber der Keepalive-Mechanismus baut wohl auf nur auf eine existierende Phase1 auf, denn es geht dabei ja darum, den Fortbestand der (Transport-)Verbindung zu prüfen und ggf. Verbindungen "offen zu halten".

Und - mangels Kenntnis des NCP-Clients kann ich das aber nicht 100%ig beurteilen - irgendwie fehlt mir auch die explizite Aussage: So, jetzt steht die Verbindung. Da im "quick mode" eigentlich 3 Nachrichten ausgetauscht werden, irritiert es mich eben auch, wenn da von "XMIT_MSG1_QUICK" die Rede ist (das lese ich als "transmit quick mode message 1"). Normalerweise einigen sich die zwei Parteien im "quick mode" (die Authentifizierung ist vorüber, die Zugriffsberechtigung des Clients ist geprüft) über die Parameter der "logischen" Verbindung wie Tunnel- vs. Transport-Mode, ESP und/oder AH, Verschlüsselungsalgorithmus und Hash-Verfahren. Das alles fehlt im Protokoll und kann genauso gut darauf hindeuten, daß der NCP-Client der FRITZ!Box nur Angebote unterbreitet, mit denen sie nichts anfangen kann. Das sieht man im NCP-Log nicht richtig, aber vielleicht auf der Gegenseite. Eigentlich fehlen die nächsten zwei Nachrichten. In der ersten Response (die zweite Message) müßte die Gegenstelle anhand der vom NCP-Client übermittelten Auswahlmöglichkeiten (IPSec proposals) und ihrer eigenen Konfiguration eine Auswahl treffen und einen konkreten Vorschlag unterbreiten. Den würde dann der NCP-Client mit der dritten Nachricht bestätigen, zusammen mit weiterem konkreten Schlüsselmaterial für die damit dann etablierte Verbindung.

Zwei Fragen entstehen daraus:

1. Ist in dieser Zeit eine Übertragung von Daten durch den Tunnel möglich ?

2. Hier wirst Du eher Leute finden, die die Ausgaben des avmike in der Datei /var/tmp/ike.log auf einer FRITZ!Box kennen. Diese Datei kannst Du entweder per Telnet-Zugriff anzeigen lassen oder in den Support-Daten der FRITZ!Box finden. Es wäre imho nützlich, wenn Du diese zum Vergleich noch dazu packen könntest (ab einer gewissen Größe dann wieder besser als Anhang).

Ich bleibe bei der schon mal geäußerten Annahme, daß da keine kompatiblen Proposals existieren ... die Idee mit den abweichenden Annahmen zum NAT-T würde ich auch noch nicht vollkommen beiseite legen, denn die Nachrichten

09.01.2015 21:03:52 Ike: ncpac3 ->Support for NAT-T version - 9
09.01.2015 21:03:52 Ike: Turning on NATD mode - ncpac3 - 1

im NCP-Log sind für mich - mangels Erfahrung mit dem NCP-Client - da auch noch nicht eindeutig.
(Bei der Gelegenheit eine Bitte ... setze doch mal in #1 das Protokoll in

-Tags, das liest sich irgendwie einfacher.)

Es ist leider auch noch so, daß AVM mit Start der Version 06.20 bei den verwendeten Verschlüsselungsverfahren Änderungen ggü. früheren Versionen vorgenommen hat. 

Damit muß eine Anleitung für eine ältere Firmware-Version (die 06.20 erscheint seit August 2014 Stück für Stück für aktuelle Modelle) nicht mehr unbedingt stimmen. Insbesondere dann, wenn diese Anleitung eine Modifikation der Parameter in "phase1ss" und "phase2ss" einer AVM-VPN-Konfiguration beinhaltet. Die möglichen Einträge dort, die sich seit 06.20 stark geändert haben, findet man in der Datei /etc/default.$CONFIG_PRODUKT/$OEM/ipsec.cfg in der FRITZ!Box-Firmware. Eine kurze Liste hatte ich [URL="http://www.ip-phone-forum.de/showthread.php?t=275714&p=2062024&viewfull=1#post2062024"]hier[/URL] mal gepostet, aber ohne Differenzierung in Phase1 und Phase2. Vielleicht stellst Du ja schon beim Lesen fest, daß/ob Deine Konfiguration für die 06.20 die richtigen Angaben in "phase1ss" und "phase2ss" enthält, die hast Du ja nicht veröffentlicht.

Ein Unterschied zwischen dem "NCP entry level client" und der Enterprise-Version soll ja - nach den Angaben auf der Webseite - nicht vorhanden sein, wenn es um das reine IPSec-VPN geht, damit müßte NCP ja irgendwann auch mal auf Version 06.20 reagieren oder sich zu der Aussage hinreißen lassen, daß die Version für den NCP-Client keine Rolle spielt und es mit 06.20 (bzw. 06.23 bei 7490) auch geht.

Letzte Bemerkung: Das, was jetzt mit einer 7390 nicht funktioniert, kann mit der 7270v3 wegen der älteren Firmware-Version (06.05 wäre aktuell) durchaus klappen. Hast Du da schon einmal getestet ?

 

[igel_igel]

Letzte Bemerkung: Das, was jetzt mit einer 7390 nicht funktioniert, kann mit der 7270v3 wegen der älteren Firmware-Version (06.05 wäre aktuell) durchaus klappen. Hast Du da schon einmal getestet ?

Hab's gerade getestet: Leider Fehlanzeige - gleicher Fehler.
Habe inzwischen einmal den NCP-Support angeschrieben - mal sehen, was die dazu sagen, daß Ihre eigene Anleitung nicht funktioniert.

 

[igel_igel]

Voila - so manifestiert sich der Fehler auf dem Server (IP-Adressen habe ich mit "###" anonymisiert):

Auszug der Datei "/var/log/ike.log" aus meiner Fritz!Box 7390:

2015-01-12 07:52:13 avmike:mainmode ncpac3: selected lifetime: 3600 sec(notify)
2015-01-12 07:52:13 avmike:ncpac3 remote peer supported XAUTH
2015-01-12 07:52:13 avmike:ncpac3 remote peer supported NAT-T RFC 3947
2015-01-12 07:52:13 avmike:ncpac3 remote peer supported DPD
2015-01-12 07:52:14 avmike:mainmode ncpac3: add SA 1
2015-01-12 07:52:14 avmike:Phase1 Responder-Lifetime-Payload wird erstellt
2015-01-12 07:52:14 avmike:ncpac3: Warning: source changed from 0.0.0.0:500 to 91.61.###.###:10954
2015-01-12 07:52:14 avmike:ncpac3: switching to NAT-T (Responder)
2015-01-12 07:52:14 avmike:ncpac3: embedded inital contact message received
2015-01-12 07:52:14 avmike:ncpac3: Phase 1 ready
2015-01-12 07:52:14 avmike:ncpac3: current=0.0.0.0 new=91.61.###.###:10954
2015-01-12 07:52:14 avmike:ncpac3: no valid sa, reseting initialcontactdone flag
2015-01-12 07:52:14 avmike:> user_changed(name=ncpac3,ipaddr=91.61.###.###)
2015-01-12 07:52:14 avmike:ncpac3: local is behind a nat
2015-01-12 07:52:14 avmike:ncpac3: remote is behind a nat
2015-01-12 07:52:14 avmike:ncpac3
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-01-12 07:52:14 avmike:ncpac3
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-01-12 07:52:15 avmike:ncpac3
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2015-01-12 07:52:15 avmike:ncpac3: start waiting connections
2015-01-12 07:52:15 avmike:ncpac3: NO waiting connections
2015-01-12 07:52:15 avmike:payloads.cpp:3970: IKE-Error 0x2005
2015-01-12 07:52:22 avmike:payloads.cpp:3970: IKE-Error 0x2005
2015-01-12 07:52:28 avmike:payloads.cpp:3970: IKE-Error 0x2005
2015-01-12 07:52:34 avmike:payloads.cpp:3970: IKE-Error 0x2005

 

[PeterPawn]

Voila - so manifestiert sich der Fehler auf dem Server

1. Man braucht schon beide Logs gleichzeitig und für dieselbe Verbindung.

2. Nützlich (und zwar nicht nur zur Befriedigung meiner persönlichen Neugier) wäre auch die passende VPN-Konfigurationsdatei und im Log zumindest mal die Zeile "< add neighbor" ... so berechtigt Datensparsamkeit (und auch das Maskieren der realen IP-Adressen) ist, das ist ein "global change" in der Datei und dann ist's auch gut. Das spart unnütze Rückfragen und das Rätselraten beim Leser. Die Festlegung, was wichtig in der Protokoll-Datei ist und damit in den Auszug aufgenommen werden muß, kann man selbst treffen und gerne auch doppelte Einträge entfernen, die sich ständig wiederholen; essentielle Teile wegzulassen ist wenig hilfreich. Der Neustart vor der Extraktion eines solchen Protokolls versteht sich (in der FRITZ!Box mit begrenztem Speicherplatz für geschwätzige Protokolle) theoretisch auch von selbst, das hatte ich allerdings vergessen zu erwähnen, so nehme ich das auf meine Kappe. Mit wachsendem Log-Umfang verwendet der avmike noch eine weitere ältere Version der Protokoll-Datei (ike.old), wenn also der Start des avmike (da wird eben das "Verständnis" des avmike für eine konfigurierte VPN-Verbindung "zu Ausdruck gebracht") nicht in der ike.log enthalten ist, dann sollte er in der ike.old stehen. Wenn man das Protokoll zeitnah nach einem Neustart erstellt, steht auch das in der ike.log.

3. Zumindest die FRITZ!Box schaltet auf NAT-T um ("switching to NAT-T (Responder)"), im NCP-Log - das meint das aus #1, das zur Verbindung passende fehlt ja - kann ich das nicht erkennen (ich wiederhole mich nur ungern). Da es beim Aufbau der Pakete einen Unterschied macht, ob NAT-T aktiviert ist oder nicht, sollte der NCP-Client fest auf NAT-T eingestellt werden (wenn das geht, ansonsten bleibt wieder der Shrewsoft). Auch wäre ein Netzwerk-Mitschnitt hilfreich, damit man sehen kann, ob der NCP-Client tatsächlich versucht, auf UDP 4500 mit der FRITZ!Box zu kommunizieren, er selbst nutzt einen variablen Port (10954 im konkreten Versuch). Das kriegst Du dann mit Wireshark auch selbst heraus. Auch bei der Diagnose der Ursache des 0x2005 kann sich der Shrewsoft-Client als hilfreich erweisen, da man dort m.W. viele Details einstellen kann (u.a. wohl auch NAT-T auf "aus/automatisch/erzwingen") und so durch Variation der Parameter auch auf falsche Einstellungen (wohl auch nicht passende Phase2-Proposals) versuchen kann, dasselbe Fehlerbild hervorzurufen, um die Fehlerursache per Analogie-Schluß weiter einzugrenzen.

4. Die Meldungen "fehlerhafte Paketlänge" sind in neuerer Firmware für mich ein wenig ein Mysterium. Dank "closed source" kann man die tatsächliche Ursache nicht ermitteln und sie treten sporadisch - besonders bei/nach der Aushandlung neuer SAs - auch zwischen FRITZ!Boxen im LAN-LAN-Modus auf, ohne die Funktionsfähigkeit der Verbindung zu beeinflussen. Ich behelfe mir und meinem Weltbild an dieser Stelle mit dem Gedanken, daß da tatsächlich Fehler auftreten, die aber auf einer höheren Protokoll-Ebene mit einer entsprechenden Sicherung dann festgestellt und durch Wiederholung von Paketen behoben werden. Ob das so ist ... vielleicht verrät Dir das AVM ja. Das eigentliche Problem sind also wohl nicht diese Meldungen, sondern tatsächlich der IKE-Error 0x2005. Ich plädiere nach wie vor dafür, daß da in Phase2 kein gemeinsames Protokoll gefunden wird, aber der Fehler wird m.W. auch nirgendwo korrekt mit der möglichen Ursache beschrieben. Was da für die FRITZ!Box als Auswahl zur Verfügung steht, kann man wieder nur über den Blick in die VPN-Konfiguration für die konkrete Verbindung ermitteln und was man beim NCP-Client einstellen kann bzw. was der dann verwendet, geht für Phase1 nach meinem Verständnis aus dem Protokoll in #1 hervor:

09.01.2015 21:03:52  Ike: IkeSa negotiated with the following properties -
09.01.2015 21:03:52    Authentication=XAUTH_INIT_PSK,Encryption=AES,Hash=SHA,DHGroup=2,KeyLen=256

, für Phase2 fehlt da aber jede Angabe. Beim AVM-Daemon gibt es wohl keine Einstellungen für eine ausführlichere Protokollierung, vielleicht gibt es ja beim NCP-Client einen entsprechenden Schalter, um das Log etwas ausführlicher zu gestalten. Insbesonders die seitens des NCP-Client verwendeten Proposals für Phase2 muß man mal sehen, solange das nicht aus den gewählten Einstellungen eindeutig hervorgeht. Bei der FRITZ!Box kann man anhand von phase2ss i.V.m. der Datei ipsec.conf genau sagen, welche Verfahren akzeptiert/unterstützt werden, das müßte man für den NCP-Client eben auch mal wissen. Da dabei diverse Dinge zueinander passen müssen (Tunnel- vs. Transport-Mode, Verschlüsselungsalgorithmus, Schlüssellänge, MAC-Verfahren, Kompression), kann da der winzigste Unterschied schon dazu führen, daß die beiden Seiten keine Gemeinsamkeit finden. Da die Phase2 schon verschlüsselt abläuft, ist da mit einem Mitschnitt auch nichts mehr zu sehen, solange man den in Phase1 vereinbarten Schlüssel nirgendwo ablesen kann und damit den Verkehr mit Wireshark dann trotzdem entschlüsseln kann. Da muß man also den Weg über entsprechend ausführliche Protokollierung gehen.

5. Auch NCP kann sich wohl nicht so genau entscheiden, ob und wenn ja wie man AVM am Ende unterstützt. Ich werde jedenfalls aus der Kompatibilitätsmatrix nicht richtig schlau. Wenn das nur für den Server gilt, fehlt die XAUTH-Unterstützung bei AVM in der Zeile, was die FRITZ!Box als Einwahl-Client in ein Firmen-LAN (wo sie dann der einzelne Host im Transport-Modus ist) disqualifizieren würde. Wenn das auch für den NCP-Client gelten sollte (die Seite schreibt ja ausdrücklich von Client und Server), dann verstehe ich nicht, wofür der Client dann überhaupt i.V.m. AVM-FRITZ!Boxen taugen soll. Er wird ja wohl kaum als komplettes LAN (das wäre dann IPSec-Tunnel-Mode anstelle des Transport-Mode) antreten wollen. Das wäre auch hier wieder ein anderer Aufbau von verschlüsselten Paketen und theoretisch auch als Ursache für den 0x2005 denkbar. Also - bei aller Wertschätzung von Deiner Seite für diesen Client - unterstützt der nun tatsächlich die Verbindung mit AVM-FRITZ!Boxen mit Firmware 06.20 oder nicht ? Der Stand der Matrix aus dem Mai 2014 legt den Schluß nahe, daß da von der 06.20 noch gar nichts bekannt war, denn die wurde erst später als Labor-Version getestet und erst Anfang Sept. 2014 freigegeben. Auf die Unterschiede beim AVM-VPN seit 06.20 habe ich schon hingewiesen.

 

[igel_igel]

Hallo zusammen, hallo PeterPawn,

Du, PeterPawn, hast Dir wieder einmal sehr viel Mühe gemacht und hast - soweit ich das als IPsec-Laie beurteilen kann - auch schon ziemlich in die richtige Richtung getippt. Gerne hätte ich Dir die Mühen der vielen Zeilen erspart, aber die Lösung meines NCP-Problemes kam quasi zeitgleich mit der Einstellung Deines Beitrages:

Letztlich hatte ich das Riesenglück, bei NCP mit genau demjenigen Menschen sprechen zu dürfen, der die o.g. Anleitung verfaßt hatte.
Er hatte sogar meine Fritz!Box in gleicher Version und mit gleichem Fritz!OS vorliegen und hat Stein und Bein geschworen, daß seine Anleitung für den NCP-Entry-Client funktioniert.

Das glaube ich ihm auch - nur leider habe ich nicht den Entry-Client sondern den NCP Secure Enterprise Client und dafür fehlten in der Anleitung wichtige Angaben, die er mir nannte und die ich hier für die Nachwelt festhalte:

Also: zunächst einmal alles schön gemäß Anleitung von NCP einrichten:
https://www.ncp-e.com/fileadmin/pdf/handbuecher/NCP_Entry_Client_AVM_FRITZ_Box_v2.pdf

Dann kommen die Anpassungen:

Es ist notwendig im Client über den Menüpunkt "Konfiguration > IPsec" unter "IPsec-Richtlinie" eine neue IPsec-Richtlinie anzulegen, deren Namen man frei wählen kann (z.B. "IPsec-Richtlinie-for-AVM7390"). Sie sollte die folgenden Parameter haben:

- Protokoll: ESP
- Transformation: AES 128 Bit
- Authentisierung: SHA
- PFS/DH-Gruppe: keine
(Sicherstellen, daß nur eine Protokoll/Tranformation in der Richtlinie hinterlegt ist - dazu die Default Protokoll/Transformation ggf. löschen)

Nach Anlage dieser Richtlinie in das (Verbindungs-)Profil wechseln (also das, was in der PDF-Anleitung angelegt wurde).
Dort die Seite bzw. den Reiter "IPsec" öffnen.
Im Feld "IPsec Richtlinien" trägt man dann genau die zuvor neu angelegte Richtlinie ("IPsec-Richtlinie-for-AVM7390") ein.

Ab diesem Moment klappt's schon mit dem Tunnel ....
... vermutlich aber nur 3600 Sekunden - nämlich bis zum nächsten Key-Exchange ...

Um auch dieses Problem noch dauerhaft in den Griff zu bekommen, empfahl mir der NCP-Experte die Verwendung einer anderen IKE-Richtlinie:

Dazu im Client über den Menüpunkt "Konfiguration > IPsec" unter "IKE-Richtlinie" eine neue Richtlinie anlegen, deren Namen man frei wählen kann (z.B. "IKE-Richtlinie-for-AVM7390").
Die Dauer der Gültigkeit (defaultmäßig "000:08:00:00") sollte man auf "000:01:00:00" heruntersetzen. Die Richtlinie sollte die folgenden Parameter haben:

- Authentisierung: Pre-shared Key
- Verschlüsselung: AES 256 Bit
- Hash: SHA
- DH-Gruppe: DH-Gruppe 2 (1024 Bit)

Nach Anlage dieser Richtlinie ins Profil wechseln.
Dort die Seite bzw. den Reiter "IPsec" öffnen.
Im Feld "IKE Richtlinien" trägt man dann genau die zuvor neu angelegte Richtlinie ("IKE-Richtlinie-for-AVM7390") ein.


Tja - und danach solltet Ihr nach Herzenslust tunneln können ...


Viele Grüße

igel_igel

 

[PeterPawn]

Na ja, dann war mal wieder der Vortrag des Redners Glück ... auch wenn ich da NCP eher einen "Vorwurf" mache, weil dort auf bestehende Unterschiede zwischen Entry-Level- und Enterprise-Client nicht hingewiesen wurde, dann das hatte ich ja (#2) versucht zu ergründen. Selbst wenn ich jetzt die konkrete Aussage auf Anhieb nicht mehr finde (habe auch keinen Ehrgeiz, danach ausführlich zu suchen, weil es ohnehin nicht mehr interessiert), würde ich behaupten, ich habe dort etwas davon gelesen, daß der Enterprise-Client dem Entry-Level-Client plus einige zusätzliche "Komfortfunktionen" entsprechen würde. Daher auch die Feststellung in #2.

Wenigstens war die Diagnose nicht nur ungefähr, sondern nach meinem Verständnis auf den Punkt richtig, das stärkt dann mein Vertrauen in meinen eigenen Durchblick (vielleicht merke ich mir die Ursache für 0x2005 ja mal richtig) und ist auch Balsam für die wunden Fingerkuppen.

Was mich aber noch interessieren würde ... kommen denn nun mit dem NCP-Client die Broadcasts auf der FRITZ!Box-Seite an (sprich, wird da auch Layer2 übertragen) und das BC-Problem ist damit auch gleich noch gelöst ? Das muß zwar für MC nicht auch gelten, wäre aber ein Anfang, wenn man dann nur noch MC nach BC "übersetzen" muß.
Das wäre als Erkenntnis an anderen Stellen ja auch interessant, auch wenn ich eine Empfehlung für eine Software, bei der man nicht einmal einen unabhängigen Preisvergleich anstellen kann, ohne gleich einen Reseller ansprechen zu müssen (der einzige Verkäufer "ohne Beratung", den ich gefunden habe, ruft einen stolzen Preis für einen IPSec-Client auf), wohl eher nie aussprechen würde. Bei allem Verständnis für die Kosten hochwertiger Software (ich habe selbst hauptberuflich genug programmiert in meinem Leben) ... aber das sind Preise aus einer anderen Epoche oder für ein anderes Szenario/Klientel als die Verbindung zur privaten FRITZ!Box.

Vergiss bitte nicht, den Thread auf "solved" zu setzen. Danke.