[Problem] VPN-Problem (LAN-LAN-Kopplung) zwischen 2 Fritzboxen 6490 - eine davon an DS-Lite

[Sigikid]

Hallo zusammen,

ich versuche seit Wochen erfolglos eine LAN-LAN-Kopplung zwischen meinen beiden Fritzboxen 6490 - beide jeweils an einem Unitymedia-Anschluss - herzustellen.

Fehlerbeschreibung:
1. FB 6490 (eigenes Gerät, Firmware 6.62) an Unitymedia DS-Lite Anschluß
angemeldet an MyFritz!, lokales Netzwerk 192.168.2.0
2. FB 6490 von Unitymedia (Firmware 6.50) an Dual Stack Anschluss (IPv4 + IPv6)
angemeldet an MyFritz!, lokales Netzwerk 192.168.1.0,
zusätzlicher eigener Dyndns Account über Strato.

VPN zwischen Netzwerken ist genau nach AVM-Anleitung auf beiden FB eingerichtet (unter Verwendung des jeweiligen MyFritz! Accounts) - dauerhafte VPN Verbindung aktiviert.
Beide Fritzboxen erkennen die IPv4 Adresse der jeweils anderen Fritzbox, es kann jedoch keine VPN-Verbindung aufgebaut werden.
Fehlermeldung im Log der FB1:
VPN-Fehler: "Myfritz-Adresse von FB2!´", IKE-Error 0x2027

Fehlermeldungen im Log der FB2:
VPN-Verbindung zu "Myfritz-Adresse der FB1" wurde erfolgreich hergestellt
danach direkt:
VPN-Verbindung zu "Myfritz-Adresse der FB1" wurde getrennt. Ursache: 3-IKE server

Beide Fehlermeldung wiederholen sich ständig bis ich den VPN-Account deaktiviere.

Nach zahlreichen erfolglosen Versuchen über den AVM-Support habe ich mich durch die diversen Foren gewühlt und auch Lösungsansätze gefunden, die leider allesamt bei mir bislang nicht zur Lösung geführt haben.

In den Foren habe ich zunächst einmal gefunden, dass die Einrichtung der LAN-LAN-Kopplung über das Web-GUI nicht funktioniert, wenn eine der FB an einem DS-Lite-Zugang hängt (vom AVM-Support kam nichts in diese Richtung!!)
Daraufhin habe ich nach den einschlägigen Anleitungen mir für beide FB entsprechende VPN-Konfig-Dateien erstellt, die ich so modifiziert habe, dass die FB am DS-Lite die Verbindung aufrecht zu erhalten versucht und in der Konfiguration der FB am IPv4 Zugang der "remotehostname" leer ist.
Kein Erfolg noch immer gleiche Fehlermeldungen.

Dann bin ich sogar hingegangen und habe die FB am DS Lite als VPN-Client konfiguriert (FB am IPv4 als VPN-Server) - auch hier kommt keine VPN-Verbindung zustande :-(
Insbesondere letzteres verstehe ich überhaupt nicht, da der VPN-Zugang auf die FB am IPv4-Zugang sowohl für mein iPhone, mein iPad als auch mein Laptop (mittels Shrewsoft-VPN) problemlos funktionieren?!?

Ich verstehe einfach nicht, was ich falsch mache...

Im Anhang sind die verwendeten Konfigurations-Dateien für die LAN-LAN-Kopplung sowie die Fehlerprotokolle aus den Support-Logs beider Fritzboxen (ich habe dabei lediglich die MyFritz-Adressen gegen die Bezeichnung der FB ausgetauscht).
Vielleicht erkennt ja jemand von Euch auf Anhieb, was ich falsch mache.

Danke im Voraus!!

Viele Grüße
Sigikid

 

[Pokemon20021]

Hallo Sigikid,
hier gibt es "en masse" Threads mit Lösungen zur Problemstellung LAN-LAN-Kopplung mit DS-Lite

z.B. http://www.ip-phone-forum.de/showthread.php?t=280350&p=2108105&viewfull=1#post2108105

Schlüssel ist die Anpassung der vpn.cfg auf Seite der FritzBox mit IPv4-Anschluß:

Am einfachsten löschst Du die "remotehostname"- und "remoteip"-Zeilen dort komplett

so dass der Verbindungsaufbau durch die Box mit DS-Lite Anschluß erfolgt.

Gruß
Pokemon20021

PS: irgendwie scheint schreiben einfacher als lesen zu sein;-)

- - - Aktualisiert - - -

Fehlermeldung im Log der FB1:
VPN-Fehler: "Myfritz-Adresse von FB2!´", IKE-Error 0x2027

Fehlermeldungen im Log der FB2:
VPN-Verbindung zu "Myfritz-Adresse der FB1" wurde erfolgreich hergestellt
danach direkt:
VPN-Verbindung zu "Myfritz-Adresse der FB1" wurde getrennt. Ursache: 3-IKE server

Hallo Sigikid,
ich sehe in den Supportlogs die Errormeldungen nicht;
könntest Du mal auf beiden Seiten die Boxen neu starten, und neue Supportlogs ziehen, so dass man vollständige Logs mit Errormeldung hat.

Gruß
Pokemon20021

 

[PeterPawn]

Die Protokolle sind "zu spät", da ist praktisch nichts mehr zu sehen. Die Konfigurationsdateien sehen erst einmal richtig aus, P1 kommt ja vermutlich auch zum Abschluß (das fehlt aber eben genau in beiden Protokollen), also wird es hoffentlich nicht an den IDs liegen. Ein Versuch mit nur einem einzigen DynDNS-Konto (also MyFRITZ! oder Strato) lohnt sich event. trotzdem noch - wobei das bei handgearbeiteter Konfiguration auch kein Thema sein sollte, wenn man es richtig eingetragen hat und wie das geht, steht ja oft genug geschrieben.

Wie man sieht, wird immer erfolgreich eine SA eingerichtet, die dann gleich darauf (innerhalb derselben Sekunde) wieder abgeräumt wird und zwar auch auf beiden Seiten. Daß es sich im dieselbe/die richtige SA handelt, sieht man an den SPIs - was jetzt die Ursache für den Abbau ist, kann man nur raten. Nach dem "NO waiting connections" sollte eigentlich erst einmal eine sehr sehr lange Zeit der Ruhe im Protokoll eintreten - was da den sofortigen Abbau der gerade erst eingerichteten SA verursacht (daß es dieselbe ist, sieht man an der ID), ist etwas rätselhaft. Besonders deutet nichts darauf hin, daß da ein Fehler 0x2027 aufgetreten sein könnte, denn das ist (aus dem Kopf, die AVM-Hilfeseiten in der Online-Version (help.avm.de) sind gerade nicht erreichbar für mich) eigentlich "timeout" und dafür bräuchte es ja zumindest mal die Chance für die Gegenseite, "in time" zu antworten.

Ausgehend vom Zeitpunkt des Abräumens würde ich fast vermuten, daß beide Seiten keinen Vorschlag (proposal) für P2 finden, auf den sie sich einigen können - aber angesichts der Nähe der Versionen ist das vermutlich auch kein Problem.

Was auffällt ... beide Seiten kommen nicht dazu, eine SA einzurichten (beide haben unten in der Ausgabe des procfs für den kdsld "0 SAs" verzeichnet) und die DS-Lite-Seite hat eine recht merkwürdige Sicht auf die eigenen IP-Adresse. Eine "192.0.0.2" finde ich selbst für einen DS-Lite-Anschluß bei UM schon sehr komisch, auch wenn ich mangels eigenem Anschluß nicht weiß, wie das dort wirklich konfiguriert wird.

Ich würde also die Protokolle noch einmal anfertigen ... die sollten irgendwie mit "avmike:< add(appl=dsld,cname=" beginnen und danach kommt dann P1 mit der Anzeige, welche IP-Adressen der Peer verwendet und welche IPSec-Optionen er versteht. Das sollte man schon sehen können, wenn man eine Idee entwickeln will - bei Dir sind nur noch mehrere Versuche für P2 zu sehen und weit und breit kein P1 mehr.

Wenn das zeitlich ein Problem darstellt, weil Du nicht schnell genug die Protokolle erzeugen kannst, kann man auch nachträglich auf der DS-Lite-Seite die VPN-Verbindung aktivieren und nach ca. 10 Sekunden wieder deaktivieren. Das sollte (angesichts der sichtbaren Frequenz der Fehler) ausreichen, um sowohl den Start als auch P1 und ein paar Versuche P2 aufzuzeichnen ... deaktiviert man die Verbindung dann wieder, endet da auch das Protokoll und man hat wieder mehr Zeit, die relevanten Stellen zu sichern, bevor sie weiteren Daten weichen müssen.

 

[Sigikid]

@Pokemon20021: genau an der vpn.cfg der IPv4 Seite habe ich die Modifikationen entsprechend den Posts vorgenommen: Remotehostename="" und remoteip= 0.0.0.0 - leider ohne Erfolg

@PeterPawn: Danke für Deine erste Analyse. Ich habe das mal nochmal neu durchgefahren und die Protokoll-Datei der IPv4-Box beigefügt - P1 ist jetzt auch mit drin.
Bin gespannt, ob Du was draus ablesen kannst. Leider bin ich jetzt 1 Woche beruflich unterwegs, so dass ich weitere Test erst am nächsten Wochenende durchführen kann.

In jedem Fall schon mal vielen Dank!!

Sigikid

 

[PeterPawn]

Ich verstehe nicht (da fehlt dann nun mal das zeitgleiche Protokoll des Peers), woher da die zweite "initial contact"-Message in der Konversation stammt. Die soll ja genau der Gegenseite mitteilen, daß sie alle bestehenden SAs vergessen soll und neue ausgehandelt werden müssen.

[COLOR="#008000"]2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: embedded inital contact message received[/COLOR]
2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: Phase 1 ready
2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: current=0.0.0.0 new=123.234.123.234:6846
[COLOR="#008000"]2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: no valid sa, reseting initialcontactdone flag[/COLOR]
2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: remote is behind a nat
2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: start waiting connections
2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: NO waiting connections
[COLOR="#FF0000"]2016-09-18 22:12:04 avmike:MyFritz-Adresse-FB-DS-Lite: inital contact message received[/COLOR]

Da gehört wirklich sowohl das Eventlog (da steht ggf. ein VPN-Fehler mit Code drin) und das Log der Gegenseite noch dazu ... ein "normaler Ablauf" sähe z.B. so aus:

2016-09-18 18:33:55 avmike:< add(appl=dsld,cname=Peer,localip=123.234.123.234, remoteip=0.0.0.0, p1ss=all/all/all, p2ss=esp-all-all/ah-none/comp-all/pfs p1mode=4 keepalive_ip=192.168.129.1 flags=0x8001 tunnel no_xauth no_cfgmode nat_t
no_certsrv_server_auth)
2016-09-18 18:33:55 avmike:new neighbour Peer:  dynamic  nat_t
2016-09-18 18:33:55 avmike:Peer start_vpn_keepalive 192.168.129.1
2016-09-18 18:33:57 avmike:mainmode Peer: selected lifetime: 3600 sec(no notify)
2016-09-18 18:33:57 avmike:Peer remote peer supported XAUTH
2016-09-18 18:33:57 avmike:Peer remote peer supported DPD
2016-09-18 18:33:57 avmike:Peer remote peer supported NAT-T RFC 3947
2016-09-18 18:33:57 avmike:mainmode Peer: add SA 1
2016-09-18 18:33:58 avmike:Peer: Warning: source changed from 0.0.0.0:500 to 123.234.123.235:500
[COLOR="#008000"]2016-09-18 18:33:58 avmike:Peer: embedded inital contact message received[/COLOR]
2016-09-18 18:33:58 avmike:Peer start_vpn_keepalive already running
2016-09-18 18:33:58 avmike:Peer: Phase 1 ready
2016-09-18 18:33:58 avmike:Peer: current=0.0.0.0 new=123.234.123.235
2016-09-18 18:33:58 avmike:Peer start_vpn_keepalive already running
[COLOR="#008000"]2016-09-18 18:33:58 avmike:Peer: no valid sa, reseting initialcontactdone flag[/COLOR]
2016-09-18 18:33:58 avmike:Peer: start waiting connections
2016-09-18 18:33:58 avmike:Peer: NO waiting connections
2016-09-18 18:33:58 avmike:Peer: Phase 2 ready
2016-09-18 18:33:58 avmike:< cb_sa_created(name=Peer,id=1,...,flags=0x00002003)
2016-09-18 18:33:58 avmike:Peer stop_vpn_keepalive to 192.168.129.1
2016-09-18 18:33:58 avmike:Peer start_keepalive_timer 3540 sec
2016-09-18 18:33:58 avmike:Peer: start waiting connections
2016-09-18 18:33:58 avmike:Peer: NO waiting connections
2016-09-18 19:27:58 avmike:mainmode Peer: selected lifetime: 3600 sec(no notify)
2016-09-18 19:27:58 avmike:Peer remote peer supported XAUTH
2016-09-18 19:27:58 avmike:Peer remote peer supported DPD
2016-09-18 19:27:58 avmike:Peer remote peer supported NAT-T RFC 3947
2016-09-18 19:27:58 avmike:mainmode Peer: add SA 2
2016-09-18 19:27:58 avmike:Peer: Phase 1 ready
2016-09-18 19:27:58 avmike:Peer: current=123.234.123.235 new=123.234.123.235
2016-09-18 19:27:58 avmike:Peer: sending initial contact message
2016-09-18 19:27:58 avmike:Peer: start waiting connections
2016-09-18 19:27:58 avmike:Peer: NO waiting connections
2016-09-18 19:32:58 avmike:Peer start_keep_alive_timer_func to 192.168.129.1
2016-09-18 19:32:58 avmike:Peer start_vpn_keepalive 192.168.129.1
2016-09-18 19:32:59 avmike:Peer: Phase 2 ready
2016-09-18 19:32:59 avmike:< cb_sa_created(name=Peer,id=2,...,flags=0x00002003)
2016-09-18 19:32:59 avmike:Peer stop_vpn_keepalive to 192.168.129.1
2016-09-18 19:32:59 avmike:Peer start_keepalive_timer 3540 sec
2016-09-18 19:32:59 avmike:Peer: start waiting connections
2016-09-18 19:32:59 avmike:Peer: NO waiting connections
2016-09-18 19:33:58 avmike:mainmode Peer: del SA 1
2016-09-18 19:33:58 avmike:FreeIPsecSA: spi=acb7dfcf          protocol=3 iotype=1
2016-09-18 19:33:58 avmike:FreeIPsecSA: spi=c9a0              protocol=4 iotype=1
2016-09-18 19:33:58 avmike:FreeIPsecSA: spi=d19bbd9           protocol=3 iotype=2
2016-09-18 19:33:58 avmike:FreeIPsecSA: spi=bd15              protocol=4 iotype=2

Da gibt es also keine weitere "initial contact"-Message vom oder zum Peer, erst nach den berüchtigten 54 Minuten ... und das ist ebenfalls ein passiver Responder.

Ich würde glatt mal hingehen und das VPN zu einer anderen FRITZ!Box testen ... wenn die Implementierung in irgendeiner der Boxen (hier dann vermutlich die Retail-Box) nicht ganz rund ist (auch IPv6 hat ja noch so seine Probleme bei echtem DS), dann sucht man sich einen Wolf. Daher würde ich beide Boxen gegen eine dritte prüfen ... wenn das Problem dann nur zwischen einer der beiden und der dritten besteht, hat man zumindest schon mal "den Schuldigen" ausgemacht. Ob das dann am Ende dem DS-Lite-Anschluß geschuldet ist oder der Retail-Firmware oder ob es sogar die Provider-Box ist, die da Späne macht, wird sich dann hoffentlich herausstellen. Wenn gar keine der dann möglichen drei Verbindungen funktioniert (in jeder der drei Boxen natürlich nur 2 Konfigurationen), dann wird es wirklich mysteriös - denn Verbindungen FB6490 vom Provider (mit DS-Lite) zu DSL-Anschlüssen hatten wir ja wirklich schon zur Genüge.

 

[Sigikid]

Hallo zusammen,

ich habe es jetzt endlich geschafft von beiden Fritzboxen zeitgleiche Logs beim (erfolglosen) Aufbau der VPN-Verbindung zu ziehen.

In der Anlage sind die Auszüge zur VPN-Konfiguration, VPN-Log und Event-Log aus den Support-Logs. Ich habe dabei lediglich die MyFritz-Addressen der jeweilige Fritzbox editiert/geändert.

Wäre toll, wenn einer von Euch Experten aus den Logs der beiden Fritzboxen Schlüsse ziehen könnte, wo der Fehler möglicherweise liegt, und mir dazu eine Info gibt.

Danke im Voraus!

Viele Grüße
Sigikid

 

[Pokemon20021]

Die phase2ss Definitionen passen nicht,
bitte mal richtigstellen und nochmal testen.

Support-Log FB-IP4.txt:
##### BEGIN SECTION vpn_cfg /var/flash/vpn.cfg
/*
 * /var/flash/vpn.cfg
SNIP
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "MyFritz-Adresse-FB-DS-Lite";
SNIP
                phase2ss = "esp-all-all/ah-none/comp-all/[COLOR=#ff0000]pfs[/COLOR];
SNIP
// EOF
##### END SECTION vpn_cfg

Support-Log FB-DS-Lite.txt:
##### BEGIN SECTION vpn_cfg /var/flash/vpn.cfg
/*
 * /var/flash/vpn.cfg
SNIP
        } {
                enabled = yes;
                editable = no;
                conn_type = conntype_lan;
                name = "MyFritz-Adresse-FB-DS-Lite";
SNIP
                phase2ss = "esp-all-all/ah-none/comp-all/[COLOR=#ff0000]no-pfs[/COLOR];
SNIP
// EOF
##### END SECTION vpn_cfg

 

[Sigikid]

Hallo Pokemon20021,

Kurze Verständnisfrage:
muss ich phase2ss-Definition für die Fritzbox am DS-Lite-Zugang auf "no-pfs" ändern?

Viele Grüße
Sigikid

 

[Pokemon20021]

es geht primär darum, dass beide Peers die gleichen Einstellungen haben und die VPN-Verbindung funktioniert.

da die Firmware unterschiedlich ist, würde ich zuerst mal mit dem einfacheren Einstellung "no-pfs" testen,
wenn damit VPN funktioniert, dann kann man bei Bedarf auch mal den höheren Security-Level "pfs" in beiden Boxen testen.

Bitte durchführen und Rückinfo.

 

[Sigikid]

Hallo,

die Einstellungen der phase2ss-Definitionen waren in beiden VPN.cfg Files jeweils auf "pfs".
Die Einstellung no-pfs findet sich nur in den VPN-Einstellungen für den VPN-Zugang über mein iPhone sowie mein iPad (die problemlos funktionieren)

Ich bin aber nichts destotrotz hingegangen und habe (nach Löschen der alten VPN-Einstellung und Neustart beider FBs) jeweils neue vpn.cfg Files eingespielt, in denen ich die phase2ss-Definitionen jeweils auf no-pfs abgeändert habe.

Das Ergebnis ist leider unverändert:
Exakt gleiches Verhalten, d.h. VPN-Verbindung wird direkt nach Aufbau wieder getrennt, neu aufgebaut, wieder getrennt => entsprechend der Log-Dateien, die ich gestern auch schon hochgeladen hatte (gleiche Fehlermeldungen auf Seite der IP4-Box, keine Fehlermeldung auf Seite des DS-Lite-Box, und auch vergleichbares VPN-Protokoll).

An der PFS Einstellung der phase2ss-Definitionen sollte es daher aus meiner Sicht nicht liegen.

Any other ideas (die ihr evtl. aus dem VPN-Log der Boxen ableiten könnt)?

Viele Grüße
Sigikid

 

[Pokemon20021]

Hallo Sigikid,
ist es Dir möglich eine VPN-Verbindung zu einer anderen Box mal zu testen; siehe Vorschlag von PeterPawn:

Ich würde glatt mal hingehen und das VPN zu einer anderen FRITZ!Box testen ... wenn die Implementierung in irgendeiner der Boxen (hier dann vermutlich die Retail-Box) nicht ganz rund ist (auch IPv6 hat ja noch so seine Probleme bei echtem DS), dann sucht man sich einen Wolf. Daher würde ich beide Boxen gegen eine dritte prüfen ... wenn das Problem dann nur zwischen einer der beiden und der dritten besteht, hat man zumindest schon mal "den Schuldigen" ausgemacht. Ob das dann am Ende dem DS-Lite-Anschluß geschuldet ist oder der Retail-Firmware oder ob es sogar die Provider-Box ist, die da Späne macht, wird sich dann hoffentlich herausstellen. Wenn gar keine der dann möglichen drei Verbindungen funktioniert (in jeder der drei Boxen natürlich nur 2 Konfigurationen), dann wird es wirklich mysteriös - denn Verbindungen FB6490 vom Provider (mit DS-Lite) zu DSL-Anschlüssen hatten wir ja wirklich schon zur Genüge.

evtl. kennst Du einen Bekannten mit FritzBox an DSL mit IPv4 Anschluß der aushelfen kann.

Gruß
Pokemon20021

 

[Sigikid]

Hallo,

Ich muss mal schauen, ob ich einen Bekannten mit Fritzbox an DSL/IPv4 ausfindig machen kann, bei dem ich die Kombinationen mal durchtesten kann.

Wenn jemand von Euch auch noch andere Ideen hat, wo ggf. ein Fehler liegen könnte, wäre ich für jeden Tip dankbar...

Viele Grüße
Sigikid

 

[odoll]

ist es Dir möglich eine VPN-Verbindung zu einer anderen Box mal zu testen; siehe Vorschlag von PeterPawn:

Ich habe den Test heute mal durchgeführt. Die primären Configs für die 6490 (ich) und 7490 (Kumpel) habe ich per PC SW "Fernzugang Einrichten" erstellen lassen.

UM 6490 ich:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "<nam>.ddns.net";
                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 = "<nam>.ddns.net";
                localid {
                        fqdn = "um.<domain>.de";
                }
                remoteid {
                        fqdn = "<nam>.ddns.net";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<key>";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 194.X.Y.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.178.0 255.255.255.0";
        }
        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";
}

7490 Kumpel:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "um.<domain>.de";
                always_renew = yes;
                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 = "um.<domain>.de";
                localid {
                        fqdn = "<nam>.ddns.net";
                }
                remoteid {
                        fqdn = "um.<domain>.de";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<key>";
                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 {
                        ipnet {
                                ipaddr = 194.X.Y.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 194.X.Y.0 255.255.255.0";
        }
        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";
}

Diese Configs habe ich dann manuell für die Kombo 7490 (ich + Kumpel) angepasst.

7490 ich:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "<nam>.ddns.net";
                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 = "<nam>.ddns.net";
                localid {
                        fqdn = "<name>.no-ip.biz";
                }
                remoteid {
                        fqdn = "<nam>.ddns.net";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<keyb>";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 194.X.Y.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2remoteid {
                        ipnet {
                                ipaddr = 192.168.178.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 192.168.178.0 255.255.255.0";
        }
        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";
}

7490 Kumpel:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "<name>.no-ip.biz";
                always_renew = yes;
                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 = "<name>.no-ip.biz";
                localid {
                        fqdn = "<nam>.ddns.net";
                }
                remoteid {
                        fqdn = "<name>.no-ip.biz";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "<keyb>";
                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 {
                        ipnet {
                                ipaddr = 194.X.Y.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/pfs";
                accesslist = "permit ip any 194.X.Y.0 255.255.255.0";
        }
        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";
}

Was soll ich sagen :-( Zwischen den 7490 funktionierts einwandfrei (da die UM allerdings DF-GW ist mußte ich temp. ne stat. Route für 192.168.178/24 auf die 7490 setzen, damit die anderen Hosts erreichbar wurden.)

Die VPN-Verbindung per SW erzeugte Configs zwischen 6490 kommt aber nicht hoch.

PS: da meine UM 6490 ne feste IP hat nutze ich allerdings keinen DynDNS-Service, sondern habe in meiner Domain einen A Record auf die IP für um.<domain>.de, bzw. ng.<domain>.de zeigt per CNAME darauf, was aber IMO keine Rolle spielen sollte (UM FB ist auch per https://um.<domain>.de bzw. https://ng.<domain>.de aus dem Internet erreichbar.)

 

[aberhallo4]

Missverstehe ich das ganze Problem?

Für eine IPv4 basierte VPN Verbindung bedarf es traditionell einer öffentlichen IPv4-Adresse. Was man mit DS-Lite ja aber gerade nicht erhält.

Mit DS-Lite kannst Du aber Verbindung zur Fritzbox aufbauen, wenn die bereits auf entsprechendem Firmwarestand 6.50 ist
https://avm.de/service/fritzbox/fri...FRITZ-Box-am-DS-Lite-Internetzugang-moeglich/
und wenn der Anbieter PCP unterstützt. Was Unitymedia aber offenbar nicht tut
http://www.unitymediaforum.de/viewtopic.php?f=90&t=33973

Ein IPv6-basiertes VPN wäre möglicherweise die Lösung - ich habe es aber bisher nicht selbst probiert. Zumindest meine Fritzbox schafft es mit dem richtigen "Kommando", die IPv6-Adresse zu meinem (kostenlosen) Dyndns-Anbieter https://www.spdyn.de/ hochzuladen. Per ins winzige Feld "Update-URL" eingetragenen String
https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ipaddr> https://update.spdyn.de/nic/update?hostname=<domain>&myip=<ip6addr>

Eine Box-Box-Kopplung könnte also möglicherweise über IPv6 funktionieren. Welche Einschränkungen auch immer dann weiter ans Tageslicht kommen mögen.

 

[PeterPawn]

Solange eine Box mit DS-Lite als Initiator arbeitet und der Peer nur als Responder (also keine aktive Verbindung aufbauen will), funktioniert das auch mit DS-Lite-Anschlüssen und ohne PCP - letzteres dient ja nur dazu, einen eingehenden Port an irgendeiner IPv4-Adresse des Providers über den IPv6-Tunnel bis zur eigenen FRITZ!Box "durchzuschalten" und somit die "ausgehende Verbindung" von der DS-Lite-Box überflüssig zu machen.

Bisher kann das VPN der FRITZ!Boxen auch kein IPv6-Protokoll als Transport benutzen.

Auf die Idee, daß es dort bei der 6490 Unterschiede zu anderen FRITZ!Box-Modellen geben könnte, bin ich auch nur deshalb gekommen, weil die 6490-Firmware eine "libipsec.so" enthält, die - den Namen der enthaltenen Funktionen nach - entweder aus dem strongSwan-Projekt oder aus den "ipsec-tools" stammt.

Ich würde darauf tippen, daß tatsächlich diese Library benutzt wird, wenn es um das Einrichten einer SA in den entsprechenden Kernel-Tabellen geht (pfkey*-Funktionen). Wenn das nur dann Späne macht, wenn die 6490 ihrerseits in der Rolle des Responders ist, dann würde das auch erklären, warum es bisher eher selten aufgefallen ist, wenn/daß es Probleme zwischen zwei 6490 gibt.

Die meisten dieser Boxen dürften bisher bei den KNB im Einsatz gewesen sein und da diese ohne weitere Maßnahmen ja gerne mal zu DS-Lite gegriffen haben, war die Zahl der 6490 als Responder sicherlich nicht übermäßig groß, denn dazu braucht es (derzeit) zwingend die IPv4-Adresse und die meisten Fragen drehten sich dann doch eher darum, wie man mit so einer Box trotz DS-Lite eine VPN-Verbindung hinbekommt.

Ob die AVM-Versuche mit IPv6 als Transportprotokoll für die IPSec-Pakete bei der 6490 schon weiter fortgeschritten sind und das event. der Grund für die libipsec.so sein könnte, kann man auch nur raten - es könnte auch daran liegen, daß AVM die Ver- und Entschlüsselung doch auf den x86-Core auslagern will und der ARM-Core dann nur noch den IKE macht.

 

[odoll]

wenn die 6490 ihrerseits in der Rolle des Responders ist, dann würde das auch erklären, warum es bisher eher selten aufgefallen ist, wenn/daß es Probleme zwischen zwei 6490 gibt.

Mein Problem besteht ja darin eine LAN-LAN-Kopplung zwischen einer UM 6490 (FRITZ!OS:06.50) mit _fester_ WAN-IPv4 und einer 'Versatel' 7490 (FRITZ!OS:06.60) mit _dynamischer_ WAN-IPv4 herzustellen.

Verstehe ich Dich richtig, dass ich lieber mal versuchen sollte die 6490 als Initiator der Verbindung und die 7490 als Responder zu konfigurieren - sprich "always_renew = yes/no;" in den Configs zu tauschen?!

 

[PeterPawn]

@odoll:
Ich gebe ehrlich zu, daß ich mir Deine Konfigurationen gar nicht weiter angesehen habe - das ging mehr um die Frage "IPv4 und PCP bzw. IPv6 als Transportprotokoll für den Tunnel".

Wenn allerdings bei Dir die 6490 auch der Responder ist, würde ich tatsächlich mal versuchen, das zu tauschen - in den funktionierenden Konfigurationen ist m.W. die 6490 immer der Responder Initiator.

Wobei "always_renew" mit dieser Frage ohnehin eher wenig zu tun hat ... das sollte (nach dem, was man so sieht an Auswirkungen) nur darauf wirken, ob die Verbindung nach Ablauf einer SA komplett neu aufgebaut wird (bei der 54 Minuten-Sache von AVM blickt ohnehin keiner mehr durch) oder nur die abgelaufene SA ersetzt wird.

Entscheidend für die Rolle als Initiator und/oder Responder ist die Erreichbarkeit der Gegenseite über eine konfigurierte IP-Adresse (remoteip) oder einen konfigurierten Hostnamen (remotehostname). Kennt die Box die Gegenstelle, versucht sie bei Bedarf selbst den Aufbau der Verbindung, was - bei gleichzeitigem Aufbau von beiden Seiten - zu Problemen führt, wenn eine der beiden eigentlich nicht erreicht werden kann (wie es bei DS-Lite ja der Fall ist für eingehende Verbindungen). Tritt dann für die selbst initiierte Verbindung auf dem (eigentlichen) Responder (also der Box mit der öffentlichen IPv4) der zu erwartende Fehler beim Erreichen der Gegenseite auf, wird selbst eine in der Gegenrichtung bereits erfolgreich aufgebaute Verbindung (bzw. deren SAs) wieder abgeräumt.

Was hier ggf. noch hineinspielt, ist die "keepalive_ip"-Adresse. Ist eine solche gesetzt (und zeigt die auf eine IP-Adresse im entfernten LAN, dazu muß natürlich auch die "accesslist" passen), dann wird unabhängig von einer vorhandenen Verbindung ein ICMP-Echo-Request zu dieser Adresse erzeugt, der dann wieder dafür sorgt, daß die Verbindung aufgebaut wird (praktisch "on demand", aber dank garantiertem Traffic eigentlich auch "always on"). Ob da jemals eine Antwort auf das "ping" kommt oder nicht, interessiert auch niemanden ... das dient praktisch nur dem Aufbau der Verbindung und ggf. noch dem Offenhalten irgendwelcher UDP-Connections - wobei letzteres auch mit anderen Mitteln machbar wäre, aber so wird eben immer gleich ein "richtiges Paket" auf die Reise geschickt und es sieht für die IPSec-Implementierung dann so aus, als wäre es regulärer Traffic.

 

[aberhallo4]

Mein Problem besteht ja darin eine LAN-LAN-Kopplung zwischen einer UM 6490 (FRITZ!OS:06.50) mit _fester_ WAN-IPv4 und einer 'Versatel' 7490 (FRITZ!OS:06.60) mit _dynamischer_ WAN-IPv4 herzustellen.

Dein Problem passt bei genauer Betrachtung aber auch gar nicht in diesen Thread, bei dem es um die Kopplung zweier 6490 und die spezielle Problematik DS-Lite geht.
Denn
- wenn Du eine feste IPv4 hast, dann hast Du kein DS-Lite
- und zudem ist die Gegenseite bei Dir eine 7490 an einem DSL-Anschluss

 

[odoll]

Trittbrettfahrer

Dein Problem passt bei genauer Betrachtung aber auch gar nicht in diesen Thread, bei dem es um die Kopplung zweier 6490 und die spezielle Problematik DS-Lite geht.

Ja, Asche auf mein Haupt - ich hoffe meine folgende Entschuldigung wird akzeptiert: denn als ich mich begann für die Thema zu interessieren (auch wenn bei mir von Anfang an nur eine 6490 im Spiel war), war diese UM 6490 noch mit einer DS-Lite-Config versehen.

Trotzdem hier mein Ergebnis bzgl. des Rollentauschs: mit 6490 Initiator und 7490 Responder funktionierts nun bei mir , wobei ich mir vom Durchsatz (nicht groß testet) 150/10 -> 8/1 mehr versprochen hatte :-(

 

[PeterPawn]

Auch die 6490 macht im Moment die Verschlüsselung noch auf dem (langsameren) ARM-Core ... vielleicht kriegt AVM es ja auf die Reihe (event. bei der 6590?), die auf den APP-Core (x86) auszulagern, auch wenn der NP-Core das Netzwerk in WAN-Richtung bedient. Allerdings mehr als 10-14 MBit/s habe ich auch bei einer 7490 noch nicht gesehen ... das Verschlüsseln beim VPN ist schlecht zu parallelisieren (geht max. beim Empfang, wo HMAC-Check und Entschlüsselung parallel erfolgen könnten).

Aber halten wir mal fest, daß wieder eine von der 6490 ausgehende VPN-Verbindung funktioniert, während die Gegenrichtung nicht so richtig klappt(e).