[Info] FRITZ!Box 7390 Labor-Firmware 84.05.58-26237 vom 22.08.2013

eisbaerin · 31 Aug 2013

eDonkey schrieb:
die Box selbst, sollte es nicht sein

Warum nicht? Meinst du die lokale oder die remote Box?
Die lokale wäre Quatsch, aber die remote sollte doch gehen.

trendchiller · 31 Aug 2013

Klar, die remote Box macht Sinn, immer das gegenüberliegende Gateway halt...

eDonkey · 31 Aug 2013

das Lan-Interface der entfernten Box wäre auch möglich, aber einerseits ist der Zugriff auf die entfernte Box (bei mir FritzBox-Lan in anderem Subnet als das getunnelte Netz) teilweise eingeschränkt und sicherheitshalber nehme ich einen anderen Endpunkt im entfernten Netz (z.B. IP-Telefon, managbarer Switch, Kopierer mit Fax der immer an ist, NAS oder ... oder) der immer an ist.

BloodyNL · 31 Aug 2013

Hallo,

so ich habe gerade ein Rollback auf Version FRITZ.Box Fon WLAN 7390 84.05.55-26045LABOR gemacht ohne POR oder ähnliches. Und siehe da , alle WLAN Speed Probleme sind behoben. Endlich kann man wieder mit voller Geschwindigkeit kopieren.

rdemann · 31 Aug 2013

rdemann schrieb:
Ich habe mehrere cb_sa_create_failed(name=xx.xx.xx, reason=IKE 0x2027) Meldungen, nachdem es heisst, dass Phase 1 ready sei....
DNS Auflösung funktioniert. Es werden die richtigen IPs angezeigt. Auch funktioniert die Client-Fritzbox VPN Verbindungen ohne Schwierigkeiten. Das mit der Umschaltung auf NAT-T koennte sein. Wie kann ich das feststellen?

Ich vermute, dass die configuration dafuer angepasst werden müsste. Verstehe nur nicht warum, da es >5 Jahre keine Probleme gab

Das habe ich nicht ganz verstanden :-( Kannst Du das etwas konkrete machen? Das waere fuer mich die perfekte Lösung

Danke
Robert

So ich habe eine Menge ausprobiert (conn_type = conntype_user um nur eine Initiator zu haben, always_renew=yes, keepalive_ip=xxx.xxx.xxx.xxx und use_nat_t = yes gesetzt um die nicht mehr funktionierende Lan to Lan VPN Verbindung an die immer noch funktionierende OSX/IOS/Android/Win7 VPN Verbindung anzugleichen. Leider immer noch kein erfolg.

Phase 1 ready meldungen bekomme ich. Leider komme ich ueber Phase 2 starting nicht hinaus. config files liegen und logs liegen bei.

Vielen Dank fuer Feedback und Input

Code:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_user;
                name = "xxx.xxx.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 = 0.0.0.0;
                remotehostname = "xxx.xxx.xxx";
                localid {
                        fqdn = "yyy.yyy.yyy";
                }
                remoteid {
                        fqdn = "xxx.xxx.xxx";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "secure";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.165.177.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip any 192.165.175.0 255.255.255.0";
        } {
                enabled = yes;
                conn_type = conntype_user;
                name = "[email protected]";
                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.165.177.240;
                remoteid {
                        key_id = "[email protected]";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "secure";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = yes;
		use_cfgmode = no;
		xauth {
			valid = yes;
			username = "xxx";
			passwd = "xxx";
		}
		phase2localid {
			ipnet {
				ipaddr = 0.0.0.0;
				mask = 0.0.0.0;
			}
		}
		phase2remoteid {
			ipaddr = 192.165.177.240;
		}
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = 
                             "permit ip any 192.165.177.240 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

Code:

vpncfg {
        connections {
                enabled = yes;
                conn_type = conntype_lan;
                name = "yyy.yyy.yyy";
                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 = "yyy.yyy.yyy";
		keepalive_ip = 192.165.177.x;
                localid {
                        fqdn = "xxx.xxx.xxx";
                }
                remoteid {
                        fqdn = "yyy.yyy.yyy";
                }
                mode = phase1_mode_aggressive;
                phase1ss = "all/all/all";
                keytype = connkeytype_pre_shared;
                key = "secure";
                cert_do_server_auth = no;
                use_nat_t = yes;
                use_xauth = no;
                use_cfgmode = no;
                phase2localid {
                        ipnet {
                                ipaddr = 192.165.175.0;
                                mask = 255.255.255.0;
                        }
                }
                phase2ss = "esp-all-all/ah-none/comp-all/no-pfs";
                accesslist = "permit ip any 192.165.177.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";
}


// EOF

Remote Log

Code:

2013-08-31 20:17:11 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:17:11 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:17:11 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:17:13 avmike:91.39.97.153:4500: aggrmode: no neighbour
2013-08-31 20:17:13 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:17:14 avmike:mainmode fritzbox.dyndns.org: add SA 117
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: sending embedded inital contact message (0,91.39.97.153,91.39.97.153)
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: switching to NAT-T (Initiator)
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: current=91.39.97.153 new=91.39.97.153:4500
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:17:14 avmike:fritzbox.dyndns.org: Phase 2 starting (start waiting)
2013-08-31 20:17:43 avmike:mainmode fritzbox.dyndns.org: del SA 117
2013-08-31 20:17:43 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 20:17:43 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:17:43 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:17:43 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:17:45 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:17:45 avmike:mainmode fritzbox.dyndns.org: add SA 118
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: current=91.39.97.153:4500 new=91.39.97.153:4500
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:17:45 avmike:fritzbox.dyndns.org: NO waiting connections
2013-08-31 20:17:46 avmike:fritzbox.dyndns.org: inital contact message received
2013-08-31 20:17:46 avmike:fritzbox.dyndns.org: inital contact message ignored
2013-08-31 20:18:16 avmike:mainmode fritzbox.dyndns.org: del SA 118
2013-08-31 20:18:16 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 20:18:16 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:18:16 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:18:16 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:18:18 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:18:18 avmike:mainmode fritzbox.dyndns.org: add SA 119
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: current=91.39.97.153:4500 new=91.39.97.153:4500
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:18:18 avmike:fritzbox.dyndns.org: NO waiting connections
2013-08-31 20:18:20 avmike:fritzbox.dyndns.org: inital contact message received
2013-08-31 20:18:20 avmike:fritzbox.dyndns.org: inital contact message ignored
2013-08-31 20:18:51 avmike:mainmode fritzbox.dyndns.org: del SA 119
2013-08-31 20:18:51 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 20:18:51 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:18:51 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:18:51 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:18:54 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:18:54 avmike:mainmode fritzbox.dyndns.org: add SA 120
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: current=91.39.97.153:4500 new=91.39.97.153:4500
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:18:54 avmike:fritzbox.dyndns.org: NO waiting connections
2013-08-31 20:18:55 avmike:fritzbox.dyndns.org: inital contact message received
2013-08-31 20:18:55 avmike:fritzbox.dyndns.org: inital contact message ignored
2013-08-31 20:19:26 avmike:mainmode fritzbox.dyndns.org: del SA 120
2013-08-31 20:19:26 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 20:19:26 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:19:26 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:19:26 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:19:28 avmike:91.39.97.153:4500: aggrmode: no neighbour
2013-08-31 20:19:29 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:19:30 avmike:mainmode fritzbox.dyndns.org: add SA 121
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: sending embedded inital contact message (0,91.39.97.153,91.39.97.153)
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: switching to NAT-T (Initiator)
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: current=91.39.97.153 new=91.39.97.153:4500
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:19:30 avmike:fritzbox.dyndns.org: Phase 2 starting (start waiting)
2013-08-31 20:19:59 avmike:mainmode fritzbox.dyndns.org: del SA 121
2013-08-31 20:19:59 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 20:19:59 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 20:19:59 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 20:19:59 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 20:20:01 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 20:20:01 avmike:mainmode fritzbox.dyndns.org: add SA 122
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: current=91.39.97.153:4500 new=91.39.97.153:4500
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 20:20:01 avmike:fritzbox.dyndns.org: NO waiting connections
2013-08-31 20:20:03 avmike:fritzbox.dyndns.org: inital contact message received
2013-08-31 20:20:03 avmike:fritzbox.dyndns.org: inital contact message ignored

Main Log

Code:

2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: Phase 1 ready
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: current=58.32.238.73:4500 new=58.32.238.73:4500
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: local is behind a nat
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: remote is behind a nat
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: sending initial contact message
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: start waiting connections
2013-08-31 14:28:13 avmike:fritzbox.dyndns.info: NO waiting connections
2013-08-31 14:28:34 avmike:mainmode [email][email protected][/email]: selected lifetime: 3600 sec(no notify)
2013-08-31 14:28:34 avmike:[email protected] remote peer supported NAT-T RFC 3947
2013-08-31 14:28:34 avmike:[email protected] remote peer supported XAUTH
2013-08-31 14:28:34 avmike:[email protected] remote peer supported DPD
2013-08-31 14:28:34 avmike:mainmode [email][email protected][/email]: add SA 4
2013-08-31 14:28:35 avmike:[email protected]: Warning: source changed from 58.32.238.74:56856 to 58.32.238.73:61017
2013-08-31 14:28:35 avmike:[email protected]: switching to NAT-T (Responder)
2013-08-31 14:28:35 avmike:[email protected]: Phase 1 ready
2013-08-31 14:28:35 avmike:[email protected]: current=58.32.238.74:56856 new=58.32.238.73:61017
2013-08-31 14:28:35 avmike:[email protected]: no valid sa, reseting initialcontactdone flag
2013-08-31 14:28:35 avmike:> user_changed([email protected],ipaddr=58.32.238.73)
2013-08-31 14:28:35 avmike:[email protected]: local is behind a nat
2013-08-31 14:28:35 avmike:[email protected]: remote is behind a nat
2013-08-31 14:28:35 avmike:[email protected]: sending initial contact message
2013-08-31 14:28:35 avmike:[email protected]: inital contact message received
2013-08-31 14:28:35 avmike:[email protected]: inital contact message ignored
2013-08-31 14:28:37 avmike:[email protected]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:28:38 avmike:[email protected]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:28:38 avmike:[email protected]: start waiting connections
2013-08-31 14:28:38 avmike:[email protected]: NO waiting connections
2013-08-31 14:28:38 avmike:[email protected]
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:28:38 avmike:[email protected]: start waiting connections
2013-08-31 14:28:38 avmike:[email protected]: NO waiting connections
2013-08-31 14:28:39 avmike:(null)
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:28:40 avmike:[email protected]: Phase 2 ready
2013-08-31 14:28:40 avmike:< cb_sa_created([email protected],id=4,...,flags=0x00032003)
2013-08-31 14:28:40 avmike:[email protected]: start waiting connections
2013-08-31 14:28:40 avmike:[email protected]: NO waiting connections
2013-08-31 14:28:44 avmike:fritzbox.dyndns.info
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:28:44 avmike:mainmode fritzbox.dyndns.info: del SA 202
2013-08-31 14:28:44 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE
2013-08-31 14:28:44 avmike:mainmode fritzbox.dyndns.info: selected lifetime: 3600 sec(no notify)
2013-08-31 14:28:44 avmike:fritzbox.dyndns.info remote peer supported XAUTH
2013-08-31 14:28:44 avmike:fritzbox.dyndns.info remote peer supported DPD
2013-08-31 14:28:44 avmike:fritzbox.dyndns.info remote peer supported NAT-T RFC 3947
2013-08-31 14:28:45 avmike:mainmode fritzbox.dyndns.info: add SA 203
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: Phase 1 ready
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: current=58.32.238.73:4500 new=58.32.238.73:4500
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: local is behind a nat
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: remote is behind a nat
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: sending initial contact message
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: start waiting connections
2013-08-31 14:28:46 avmike:fritzbox.dyndns.info: NO waiting connections
2013-08-31 14:28:50 avmike:>>>4500 nat-t-keepalive[58.32.238.73:61017]
2013-08-31 14:29:19 avmike:fritzbox.dyndns.info
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:29:19 avmike:mainmode fritzbox.dyndns.info: del SA 203
2013-08-31 14:29:19 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE
2013-08-31 14:29:19 avmike:mainmode fritzbox.dyndns.info: selected lifetime: 3600 sec(no notify)
2013-08-31 14:29:19 avmike:fritzbox.dyndns.info remote peer supported XAUTH
2013-08-31 14:29:19 avmike:fritzbox.dyndns.info remote peer supported DPD
2013-08-31 14:29:19 avmike:fritzbox.dyndns.info remote peer supported NAT-T RFC 3947
2013-08-31 14:29:20 avmike:mainmode fritzbox.dyndns.info: add SA 204
2013-08-31 14:29:20 avmike:mainmode fritzbox.dyndns.info: selected lifetime: 3600 sec(no notify)
2013-08-31 14:29:20 avmike:fritzbox.dyndns.info remote peer supported XAUTH
2013-08-31 14:29:20 avmike:fritzbox.dyndns.info remote peer supported DPD
2013-08-31 14:29:20 avmike:fritzbox.dyndns.info remote peer supported NAT-T RFC 3947
2013-08-31 14:29:20 avmike:mainmode fritzbox.dyndns.info: add SA 205
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: switching to NAT-T (Responder)
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: embedded inital contact message received
2013-08-31 14:29:21 avmike:mainmode fritzbox.dyndns.info: del SA 204
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: Phase 1 ready
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: current=58.32.238.73:4500 new=58.32.238.73:4500
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: local is behind a nat
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: remote is behind a nat
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: start waiting connections
2013-08-31 14:29:21 avmike:fritzbox.dyndns.info: NO waiting connections
2013-08-31 14:29:51 avmike:fritzbox.dyndns.info
 fehlerhafte Paketlaenge: Hdr-length > read-Data
2013-08-31 14:29:51 avmike:mainmode fritzbox.dyndns.info: del SA 205
2013-08-31 14:29:51 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE
2013-08-31 14:29:52 avmike:mainmode fritzbox.dyndns.info: selected lifetime: 3600 sec(no notify)
2013-08-31 14:29:52 avmike:fritzbox.dyndns.info remote peer supported XAUTH
2013-08-31 14:29:52 avmike:fritzbox.dyndns.info remote peer supported DPD
2013-08-31 14:29:52 avmike:fritzbox.dyndns.info remote peer supported NAT-T RFC 3947
2013-08-31 14:29:52 avmike:mainmode fritzbox.dyndns.info: add SA 206
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: Phase 1 ready
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: current=58.32.238.73:4500 new=58.32.238.73:4500
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: local is behind a nat
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: remote is behind a nat
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: sending initial contact message
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: start waiting connections
2013-08-31 14:29:53 avmike:fritzbox.dyndns.info: NO waiting connections

trendchiller · 31 Aug 2013

Ist der AVMIKE irgendwo dokumentiert ? Sind die Parameter ähnlich wie racoon oder ähnlich ?

H´Sishi · 31 Aug 2013

/ot: @rdemann: Bitte verwende statt "Zitat" die "Code"-Tags für die Logs und Configs. "Zitat" bläht den Post viel zu sehr auf, während "Code" einen fixen Bereich mit Scrollfunktionen bietet.
Eventuell kannst Du die Dateien auch einfach anhängen ...

rdemann · 31 Aug 2013

trendchiller schrieb:
Ist der AVMIKE irgendwo dokumentiert ? Sind die Parameter ähnlich wie racoon oder ähnlich ?

Habe hier etwas http://www.wehavemorefun.de/fritzbox/Avmike gefunden. Hilft mir aber momentan nicht weiter

Gruesse
Robert

PeterPawn · 31 Aug 2013

eDonkey schrieb:
Das lässt sich seit einiger Zeit eleganter lösen, habe beim durchstöbern der Supportdaten, einen undokumentierten Parameter gefunden, den man händisch in die vpn.cfg eintragen muss.

remotehostname = "xxxxxxx";
keepalive_ip = xxx.xxx.xxx.xxx; <--- hier einfache einen Host eintragen, der immer online ist, die Box selbst, sollte es nicht sein (warum siehe #165)
localid {

Vor einiger Zeit hat das Setzen der keepalive_ip noch nicht geholfen, da avmike das Senden von KeepAlive-Paketen erst dann ausführte, wenn die Verbindung schon stand. Macht ja eigentlich auch so Sinn ... wenn niemand etwas aus dem entfernten Netz will, braucht auch kein keepalive gesendet zu werden.

Solange kein Paket mit einer Zieladresse im entfernten Netz auf "dev dsl" zum Routen ankommt, wird die IPSec-Verbindung gar nicht erst aufgebaut.

Kommt dann ein Paket an, wird als erstes der Tunnel aufgebaut und dann die "angehaltene" Verbindung hergestellt (sprich das Paket, was den Start verursachte, wird weitergeleitet).

Dauert der Tunnelaufbau zu lange, kommt es auch gerne mal zu einem ersten Timeout bei der Verbindung, die den Tunnelaufbau verursacht hat.

Ist das mit der keepalive_ip jetzt anders und der Tunnelaufbau wird auch von Keepalive-Pings initiiert ?

rdemann schrieb:
So ich habe eine Menge ausprobiert (conn_type = conntype_user um nur eine Initiator zu haben, always_renew=yes, keepalive_ip=xxx.xxx.xxx.xxx und use_nat_t = yes gesetzt um die nicht mehr funktionierende Lan to Lan VPN Verbindung an die immer noch funktionierende OSX/IOS/Android/Win7 VPN Verbindung anzugleichen. Leider immer noch kein erfolg.

Das meinte ich so nicht ...

Einfach bei der bisher vorhandenen VPN-Konfiguration auf der "Responder"-Seite die Informationen zur IP-Adresse und/oder zum DynDNS-Namen der Gegenstelle (Initiator) weglassen, dann wird der Tunnelaufbau automatisch nur von einer Seite aus möglich und der Responder wartet nur auf eingehende Verbindungen.

Wenn ich die AVM-Implementierung richtig verstehe, wird mit conntype_user der Transport-Modus eingerichtet, Du brauchst aber den Tunnel-Modus. Wenn eine der beiden Seiten den falschen Modus auswählt, kommen solche Nachrichten wie
"fehlerhafte Paketlaenge: Hdr-length > read-Data" zustande, da der Aufbau der IPSec-Pakete im jeweiligen Modus abweicht (http://de.wikipedia.org/wiki/IPsec).

Probiere doch mal bitte wie beschrieben ... also ohne Hinweis auf die öffentliche Adresse der Gegenstelle - weder DNS-Name noch IP-Adresse - in der Konfiguration des "Responders" und poste dann die Logs der beiden Seiten noch einmal (bzw. besser als Attachment).

[OT]
Das mit der IP-Telefonnummer würde ich ja gerne noch erläutern, aber im Moment nervt mich die vBulletin-Software hier mit ständigen Fehlern (404) beim Drücken auf Vorschau.
[/OT]

So, ich versuche es mal mit der SIP-Konfiguration ...

1. Auf der "Responder"-Seite ein neues Telefoniegerät (LAN/WLAN) anlegen.

2. Auf der "Initiator"-Seite eine neue Internet-Rufnummer einrichten mit
- anderer Anbieter
- Internet-Rufnummer = Benutzername = in Schritt 1 vergebene Rufnummer
- Kennwort aus Schritt 1
- Registrar = LAN-IP der Responder-Box
- kein Proxy
- Anmeldung immer über eine Internetverbindung

Damit versucht die Initiator-Box beim Start diese Telefonnummer beim Responder zu registrieren und löst so den Aufbau des Tunnels aus. Das ist für mich bisher (außer keepalive geht inzwischen auch ohne aufgebauten Tunnel, was aber m.E. eher ein Bug wäre, s.o.) der effektivste Weg, da so außer den beiden beteiligten Boxen kein anderes Gerät involviert ist. Das AVM-KeepAlive funktionierte nach meinen früheren Tests auch eher so, daß bei Nichterreichbvarkeit dieser IP der avmike von einem Abbruch der Verbindung ausging und die betreffenden SA nur verwarf. Wenn ich mir jetzt die IKE-Logs aber genau ansehe, hat AVM offenbar irgendwann mal DPD (RFCeingebaut:

Code:

... remote peer supported XAUTH
... remote peer supported DPD
... remote peer supported NAT-T RFC 3947

, auch wenn ich nicht eindeutig erkennen kann, ob es auch wirklich verwendet wird und mit einem Ping (ICMP) zur keepalive_ip nicht nur das Verfallen von NAT-Einträgen auf dem Weg zwischen den beiden Endpunkten verhindert wird. Der Eintrag "avmike:>>>4500 nat-t-keepalive[109.45.xxx.xxx:4500]" läßt eigentlich letzteres vermuten. Da hilft wohl nur mal ein Paketmitschnitt ...

Selbst wenn man das Einrichten des Telefoniegeräts auf dem Responder wegläßt, versucht der Initiator nach dem Start dann eben eine nicht existierende Nummer zu registrieren, was aber auch zum Aufbau des Tunnels führt. Die dabei im Systemprotokoll des Initiators entstehenden Fehlermeldungen können jedoch nerven und das Interval, in dem die fehlgeschlagene Registrierung erneut versucht wird, verlängert sich irgendwann auch recht ordentlich, so daß dann auch mal ein unbeabsichtigter Abbau des Tunnels (die "default lifetime" einer SA zwischen zwei Fritzboxen ist 3600 Sekunden) stattfinden kann, wenn kein DPD aktiviert ist.

Bei erfolgreicher Registrierung wird dagegen alle 150 Sekunden ein SIP-REGISTER wiederholt und das reicht dann normalerweise um den Tunnel am Leben zu halten bzw. spätestens 149 Sekunden nach dem Ablauf der SA ein Rekeying auszuführen.

rdemann · 31 Aug 2013

PeterPawn schrieb:
Das mit der IP-Telefonnummer würde ich ja gerne noch erläutern, aber im Moment nervt mich die vBulletin-Software hier mit ständigen Fehlern (404) beim Drücken auf Vorschau.
[/OT]

Habe ich bereits verstanden und eingerichtet.

Ich habe auch conn_type wieder auf conntype_lan gesetzt und remotehostname aus kommentiert. Eigentlich kaum eine Änderung. Nun tauch ab und zu eine IKE-Error 0x203d Meldung auf. Habe auch beide Anlage mal an und aus gemacht

Habe logs fuer die Zeitfenster kombiniert. Ansonsten ist alles gleich (inklusive Hdr-length Fehler von oben)

Ich weiss es nicht. Habe ein Gefuehl, dass es etwas mit avmike:wolke_neighbour_renew_sa, avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE zu tun hat, add SA und del SA zu tun hat

Code:

Remote:
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: Phase 2 starting (start waiting)
2013-08-31 23:04:08 avmike:mainmode fritzbox.dyndns.org: del SA 410
2013-08-31 23:04:08 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 23:04:08 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 23:04:08 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 23:04:08 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 23:04:09 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 23:04:09 avmike:mainmode fritzbox.dyndns.org: add SA 411

Main:
2013-08-31 23:03:00 avmike:mainmode fritzbox.dyndns.org: del SA 409
2013-08-31 23:03:00 avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE
2013-08-31 23:03:00 avmike:fritzbox.dyndns.org start_vpn_keepalive already running
2013-08-31 23:03:33 avmike:fritzbox.dyndns.org: Phase 1 failed (initiator): timeout, checking ip address
2013-08-31 23:03:33 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 23:03:38 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 23:03:38 avmike:mainmode fritzbox.dyndns.org: add SA 410
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: sending embedded inital contact message (0,91.39.97.153,91.39.97.153)
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: switching to NAT-T (Initiator)
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: current=91.39.97.153 new=91.39.97.153:4500
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 23:03:38 avmike:fritzbox.dyndns.org: Phase 2 starting (start waiting)
2013-08-31 23:04:08 avmike:mainmode fritzbox.dyndns.org: del SA 410
2013-08-31 23:04:08 avmike:wolke_neighbour_renew_sa 0 SAs
2013-08-31 23:04:08 avmike:wolke_neighbour_renew_sa 0 SAs RENEW 
2013-08-31 23:04:08 avmike:fritzbox.dyndns.org: Phase 1 starting (renew)
2013-08-31 23:04:08 avmike:< cb_sa_create_failed(name=fritzbox.dyndns.org,reason=IKE-Error 0x2027)
2013-08-31 23:04:09 avmike:mainmode fritzbox.dyndns.org: selected lifetime: 3600 sec(no notify)
2013-08-31 23:04:09 avmike:mainmode fritzbox.dyndns.org: add SA 411
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org remote peer supported XAUTH
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org remote peer supported DPD
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org remote peer supported NAT-T RFC 3947
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: Phase 1 ready
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: current=91.39.97.153:4500 new=91.39.97.153:4500
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: local is behind a nat
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: remote is behind a nat
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: start waiting connections
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: NO waiting connections
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: inital contact message received
2013-08-31 23:04:09 avmike:fritzbox.dyndns.org: inital contact message ignored

PeterPawn · 31 Aug 2013

rdemann schrieb:
Ich weiss es nicht. Habe ein Gefuehl, dass es etwas mit avmike:wolke_neighbour_renew_sa, avmike:wolke_del_neighbour_sa_by_remote: no SAs available, set canceld = TRUE zu tun hat, add SA und del SA zu tun hat

Leg doch mal bitte die Protokolle etwas ausführlicher - und auch die nun wirklich verwendeten Konfigurationen - offen.

Anhand der schmalen Auszüge würde ich raten, "Main" soll bei Dir der Initiator sein und "Remote" ist die (nunmehr passive) Gegenstelle. Wenn ich die weiter oben geposteten Config-Files dazu nehme und die von Dir beschriebenen Änderungen berücksichtige, fehlt mindestens auf einer Seite für Phase 2 die Information über das entfernte Subnetz, was bei use_cfgmode=no aber zwingend ist. So sieht es im Moment für mich aus, als wenn die Boxen zwar die Identität der Gegenstelle prüfen können (Phase 1), aber die in Phase 2 erwartete Konfiguration des Tunnels nicht stattfindet (Timeout nach 30 Sekunden ohne Konfiguration und Neustart Phase 1 mit neuer SA).

In beiden Konfigurationen muß der Eintrag phase2localid und phase2remoteid enthalten sein und jeweils das eigene und das entfernte IP-Subnetz beschreiben (also phase2localid auf der einen Seite = phase2remoteid auf der anderen Seite). Diese Einträge werden zusammen mit phase2ss verwendet, um die konkrete "Ausgestaltung" des Tunnels auszuhandeln. Alles davor in der Konfiguration dient eigentlich nur der Identifikation und Authentifizierung der jeweiligen Gegenstelle (Phase 1).

Ich habe gerade noch etwas gesehen, was beim flüchtigen Überfliegen Deiner Konfigurationen gar nicht weiter auffiel: Du verwendest keine "privaten" Adressen für die Subnetze auf beiden Seiten (192.165.x.x ist keine private IP nach RFC 1918 ) und da kann es dann auch schon einmal passieren, daß eine Änderung in der AVM-Software (z.B. eine zusätzliche Prüfung der IP) zu einem nicht mehr funktionierenden VPN führt. Die Access-Lists sehen auch etwas merkwürdig aus, liegt aber vielleicht auch an der Mischung von Transport- und Tunnel-Modus im oben stehenden Posting.

Die Aussage

Habe auch beide Anlage mal an und aus gemacht

verstehe ich auch nicht richtig ... ein kürzlich erfolgter Neustart kann damit eigentlich nicht gemeint sein, denn die FB zählt die SAs nach einem Neustart von 1 beginnend neu und bei SA 410 sind dann mal locker 205 Minuten (=> knapp 3,5 Stunden bei neuer SA alle 30 Sekunden) vergangen.

rdemann · 1 Sep 2013

PeterPawn schrieb:
Leg doch mal bitte die Protokolle etwas ausführlicher - und auch die nun wirklich verwendeten Konfigurationen - offen.
Anhand der schmalen Auszüge würde ich raten, "Main" soll bei Dir der Initiator sein und "Remote" ist die (nunmehr passive) Gegenstelle.

Habe ich soeben gemacht. Main = Responder.cfg.txt (fritzbox.dyndns.org) und Remote = Initiator.cfg.txt(fritzbox.dyndns.info); also genau andersrum. Ich habe auch hier "use_nat_t" wieder zurueckgesetzt auf "no", da ich keine Verbesserung sehen konnte. Logs (Ike.log und web) liegen auch bei

PeterPawn schrieb:
So, ich versuche es mal mit der SIP-Konfiguration ...

1. Auf der "Responder"-Seite ein neues Telefoniegerät (LAN/WLAN) anlegen.

2. Auf der "Initiator"-Seite eine neue Internet-Rufnummer einrichten mit
- anderer Anbieter
- Internet-Rufnummer = Benutzername = in Schritt 1 vergebene Rufnummer
- Kennwort aus Schritt 1
- Registrar = LAN-IP der Responder-Box
- kein Proxy
- Anmeldung immer über eine Internetverbindung

Danke. Das ist wirklich sehr interessant und hilfreich und ich hoffe, dass ich es zum laufen bringen kann sobald mein VPN arbeitet. Habe es bereits richtig eingerichtet

Ich habe gerade noch etwas gesehen, was beim flüchtigen Überfliegen Deiner Konfigurationen gar nicht weiter auffiel: Du verwendest keine "privaten" Adressen für die Subnetze auf beiden Seiten (192.165.x.x ist keine private IP nach RFC 1918 ) und da kann es dann auch schon einmal passieren, daß eine Änderung in der AVM-Software (z.B. eine zusätzliche Prüfung der IP) zu einem nicht mehr funktionierenden VPN führt. Die Access-Lists sehen auch etwas merkwürdig aus, liegt aber vielleicht auch an der Mischung von Transport- und Tunnel-Modus im oben stehenden Posting.

IPs, die Anzahl der SAA sowie Hostnamen sind nachtraeglich editiert worden. Beim naechsten Mal beschraenke ich mich auf die Hostnamen

PeterPawn · 1 Sep 2013

rdemann schrieb:
Ich habe auch hier "use_nat_t" wieder zurueckgesetzt auf "no", da ich keine Verbesserung sehen konnte.

NAT-Traversal ist in Deinem Scenario unabdingbar, da zwischen fritzbox.dyndns.info und dem "echten" Internet offenbar noch ein Gateway (intern 192.168.255.254, extern 58.32.238.73) sitzt (ich hoffe jedenfalls, es ist nur ein zusätzlicher NAT-Router).

Bei IPSec wird ja nicht nur der Inhalt eines Pakets verschlüsselt, es wird auch noch durch weitere Maßnahmen sichergestellt, daß das Paket unterwegs nicht manipuliert wird. Genau diese Manipulation (Änderung der Absenderadresse und ggf. des Ports) ist aber die Aufgabe eines NAT-Routers.

Wenn fritzbox.dyndns.info ein IPSec-UDP-Paket auf die Reise schickt, enthält es die Absenderadresse 192.168.249.242 und (da ja kein NAT-T gesetzt) die Port-Nummer 500. Das Paket geht (wenn die Routing-Tabelle nichts anderes sagt) an die Adresse 192.168.255.254, wo sich der betreffende Router um die Weiterleitung zu kümmern hat. Da dieser Router aber kein Paket mit einer privaten Absender-IP (192.168.249.242) ins Internet leitet (selbst wenn er das tut und das Paket kommt am Ziel an ... eine Antwort bliebe definitiv aus), modifiziert der Router an 192.168.255.254 das Paket so, daß er seine eigene externe IP-Adresse als Absender einträgt und sich in einer internen Tabelle merkt, wann er dieses Paket wohin weitergeleitet hat und von wem er dieses Paket zur Weiterleitung erhalten hat. Trifft jetzt von der Gegenstelle eine Antwort ein, wird dieses Paket mit den Angaben in der Tabelle verglichen und die originale Absenderadresse als Zieladresse in das Antwortpaket eingetragen und das Paket dann wieder ins LAN ausgeliefert. Das ist das Grundprinzip der "Network Address Translation", auch bekannt als NAT. Da hinter einem NAT-Router auch mehrere andere Systeme hängen können, wird u.U. nicht nur die Absenderadresse, sondern auch der Absenderport eines Pakets modifiziert, wenn der "originale" Absenderport schon von einer anderen Verbindung (also einem anderen Rechner) benutzt wurde. Damit das bei IPSec an dieser Stelle nicht sofort in die Hose geht, gibt es in vielen Routern die (veraltete) Funktion "IPSec Passthrough", die eine zusätzliche Manipulation des Ports verhindert. Auch damit ist aber nur eine einzige VPN-Verbindung aus dem internen Netz möglich, weil die eigentlichen Pakete mit dem verschlüsselten Payload (ESP) auch umgeschrieben werden müssen und das nur für eine Verbindung gleichzeitig geht.

Das modernere Verfahren ist IPSec mit NAT-Traversal (RFC 3947). Dabei wird der eigentliche sichere Payload (also die ESP-Pakete) zusätzlich noch in UDP-Pakete verpackt, das Ein- und Auspacken übernehmen die Tunnel-Endpunkte. Da diese UDP-Pakete wie ganz normale andere Pakete auch beim Transport geändert werden können, steht auch ein NAT-Router einer VPN-Verbindung nicht mehr im Weg.

Also langer Rede kurzer Sinn: Das Ganze bitte noch einmal von vorne, diesmal auf beiden Seiten mit use_nat_t=yes. Selbst wenn NAT-T nicht benötigt werden sollte, schadet diese Einstellung eigentlich nie, da beide Seiten im Rahmen des Schlüsselaustauschs in Phase 1 feststellen, ob NAT im Spiel ist und nur bei Bedarf NAT-T aktivieren.

BTW: Die Syntax mit dem Auskommentieren des remotehostname in der Responder.cfg finde ich mutig ... funktioniert das wirklich ? Habe ich in AR7-Style-Konfigurationen mitten in den Werten so noch nicht gesehen ...

Baktosh · 1 Sep 2013

Obgleich der vielen Infos bzgl. der Geschwindigkeit hinter Kabelmodems habe ich mich nun doch getraut die Labor zu installieren. Was soll ich sagen, die Infos sind tatsächlich richtig.

Kaum war die Labor drin, brach mein Downspeed an meinem Unitymedia 100er Premium komplett ein.

Mit den korrekt eingestellten Werten für 100Mbit down und 5Mbit up kam ich nicht über eine Geschwindigkeit von 554kbit/s

:crazy:
Surfen während ein Download lief komplett unmöglich.

Dann hier den Tip befolgt und die Werte für Up und Down geändert, Box reboot und direkt den gleichen Download wie vorher gestartet...
Geschwindigkeit des Downloads sind wieder auf den alten Werten wie sie auch sein sollten.

Um auszuschließen das hier nicht nur der Reboot was gemacht hat, Werte wieder auf die normalen zurückgeändert und rebootet.
Geschwindigkeit erneut miserabel und läuft nach erneuter Änderung und reboot wieder mit der korrekten Anschlussmöglichen Downspeed.

Also liebe Leute die ihr auch bei UM seit und eine 7390 hinter einem 3208 (ohne G) habt, welche mit dieser Labor grottige Werte liefert, ändert den Wert für Up & Down ab und rebootet eure FB.

AVM muß das bis zur Final auf jedenfall in den Griff bekommen

rdemann · 1 Sep 2013

PeterPawn schrieb:
NAT-Traversal ist in Deinem Scenario unabdingbar, da zwischen fritzbox.dyndns.info und dem "echten" Internet offenbar noch ein Gateway (intern 192.168.255.254, extern 58.32.238.73) sitzt (ich hoffe jedenfalls, es ist nur ein zusätzlicher NAT-Router).

Bei IPSec wird ja nicht nur der Inhalt eines Pakets verschlüsselt, es wird auch noch durch weitere Maßnahmen sichergestellt, daß das Paket unterwegs nicht manipuliert wird. Genau diese Manipulation (Änderung der Absenderadresse und ggf. des Ports) ist aber die Aufgabe eines NAT-Routers.

....

Also langer Rede kurzer Sinn: Das Ganze bitte noch einmal von vorne, diesmal auf beiden Seiten mit use_nat_t=yes. Selbst wenn NAT-T nicht benötigt werden sollte, schadet diese Einstellung eigentlich nie, da beide Seiten im Rahmen des Schlüsselaustauschs in Phase 1 feststellen, ob NAT im Spiel ist und nur bei Bedarf NAT-T aktivieren.

BTW: Die Syntax mit dem Auskommentieren des remotehostname in der Responder.cfg finde ich mutig ... funktioniert das wirklich ? Habe ich in AR7-Style-Konfigurationen mitten in den Werten so noch nicht gesehen ...

Habe ich gemacht. Die neuen logs liegen bei. Wie Du aus beiden logs lesen kannst scheitert es immer noch an der 2ten Phase.
Gibt es die Moeglichkeit diese 2te Phase abzuschalten? Ich habe einige AVM-Cisco configs gesehen aber die habe bei mir nicht funktioniert.
Habe auch versucht mit use_cfgmode = yes, aber damit gab es noch mehr Fehler auf dem Responder und die erste Phase konnte nicht abgeschlossen werden.

Bis auf dem Firmware upgrade hatte ich ja eigentlich nichts verändert (die config files mit use_nat_t = no sind von 2008 und haben bisher ja funktioniert), deshalb verstehe ich nicht warum es auf einmal nicht funktioniert.

Danke fuer die bisherige Hilfe. Bin gespannt wo der Fehler liegt wenn es nicht Firmware sein soll

PeterPawn · 1 Sep 2013

rdemann schrieb:
Gibt es die Moeglichkeit diese 2te Phase abzuschalten?

Ja, einfach kein IPSec verwenden ...

Ernsthaft: In Phase 2 einigen sich die beiden Seiten, welchen Verschlüsselungsalgorithmus und welches Authentifizierungsverfahren (bei avmike immer ohne -> ah-none in phase2ss) sie verwenden wollen, das kann man nicht einfach weglassen.

Bei use_cfgmode=yes wird die Konfiguration der (privaten) IP-Adressen nicht vorher festgelegt, sondern erst im Rahmen des Tunnelaufbaus. Das wird bei LAN-LAN-Kopplung eigentlich fast nie verwendet und dient in erster Linie zum Anbinden von "Roadwarriors" an ihr Firmennetz. Am ehesten kann man diesen Modus mit der IP-Adressvergabe durch einen DHCP-Server vergleichen, nur eben für VPN-Clients (conn_type = conntype_user).

Dem Protokoll zufolge kommt entweder auf Port 4500 überhaupt kein Paket an (Firewall dazwischen ? Die Ports in den FB sollten offen sein, wenn die geposteten Config-Files stimmen.) oder die Pakete können nicht richtig entschlüsselt/zugeordnet werden (Ist die 100%-ige Übereinstimmung der PSK auf beiden Seiten sicher ?). Noch eine Bemerkung zu den Angaben in "localid" und "remoteid": Diese müssen wirklich über Kreuz übereinstimmen (also localid "links" = remoteid "rechts" und umgekehrt). Ich betone das deshalb noch einmal, weil Du ja (sinnvollerweise) nur die bearbeiteten Config-Files herausgibst. Da mußt Du dann selbst ordentlich prüfen. Da die in der Box gespeicherten Konfigurationen bei LAN-LAN die localid und die remoteid nur verschlüsselt enthalten (wie beim key="$$$$..." auch), könnte ich mir auch da noch ein theoretisches Problem vorstellen, falls beim Entschlüsseln mit der neuen Firmware etwas schief geht (aber wirklich nur theoretisch ... ich hoffe doch mal, daß AVM beim Verschlüsseln in den Wert einen Teilstring zur Prüfung der korrekten Entschlüsselung mit einbaut).

Solange die VPN-Verbindung nicht prinzipiell wieder funktioniert, würde ich auch erst einmal auf irgendwelche Keep-Alives verzichten, da diese u.U. das Protokoll verfälschen. Für eine "saubere" Diagnose anhand der Protokoll-Dateien ist es günstig, wenn der Initiator später neu gestartet/neu konfiguriert wird, als der Responder (der ja eigentlich nur in einen definierten Zustand warten dürfte). Das könnte auch bei Dir der Fall gewesen zu sein, allerdings fehlt auf der Initiator-Seite der Beginn des Protokolls. Dazu muß man dann noch wissen, daß der avmike (vermutlich beim Überschreiten einer best. Dateigröße) eine neue ike.log-Datei erstellt und die vorherige unter dem Namen ike.old in demselben Verzeichnis liegen bleibt. Die Rekonfiguration des avmike findet immer an den Stellen statt, wo Zeilen wie "avmike:< add (appl=dsld,cname=<vpn-definition>..." im Protokoll auftauchen. Da diese Zeile für den Initiator fehlt, kann man nicht sehen, wie die Konfiguration aus der Datei vpn.cfg dann wirklich beim avmike ankommt.

Wenn ich suche müßte, würde ich als nächstes auf der Responder-Box einen Paket-Mitschnitt starten und überprüfen, ob überhaupt Pakete auf UDP-Port 4500 von der Gegenstelle (also der, die 6 Stunden weiter ist) eingehen. Ist das nicht der Fall, dann auf der Initiator-Box prüfen, ob diese Pakete gesendet werden. Wenn ja, blockiert irgendwo auf dem Weg jemand diese Pakete und es hat gar nichts mit Deinen Boxen zu tun.

Kommen hingegen Pakete auf UDP 4500 herein auf der Responder-Seite, würde ich den PSK und localid/remoteid doppelt und dreifach checken. Ich hatte aber auch schon den Fall, daß nach dem temporären Deaktivieren (Haken aus der Checkbox raus und "Übernehmen") einer VPN-Verbindung und anschließender erneuter Aktivierung einfach kein erfolgreicher Aufbau einer Verbindung mehr möglich war. Ich vermute mal, daß da beim Schreiben (im Rahmen des De-/Aktivierens) der geänderten vpn.cfg doch irgendetwas mit den verschlüsselten Einträgen in der Konfigurationsdatei passiert war. Abhilfe war nur durch das erneute Einspielen der VPN-Verbindung aus einer Textdatei mit Klartext und anschließenden Neustart möglich. Inzwischen werden ja glücklicherweise vor dem Import einer Verbindung nicht mehr alle anderen gelöscht, so daß man nicht immer alle VPN-Definitionen in einer einzelnen Datei vorhalten muß.

lieblingsbesuch · 1 Sep 2013

Mit dieser Firmware kann mein Drucker (Envy 120) nicht mehr auf den Router connecten. Er versucht es zwar, kriegt dann aber keine IP mehr. Die vorige Beta war da problemlos (und alle anderen davor auch)

rdemann · 1 Sep 2013

lieblingsbesuch schrieb:
Mit dieser Firmware kann mein Drucker (Envy 120) nicht mehr auf den Router connecten. Er versucht es zwar, kriegt dann aber keine IP mehr. Die vorige Beta war da problemlos (und alle anderen davor auch)

Mit dem Envy 110 gibt es keine Schwierigkeiten. Bei mir laeuft es...
Gruesse
Robert

Benares · 1 Sep 2013

Ich hab grad festgestellt, dass meine Fritzbox mit der Beta (s. Signatur) abstürzt und neu bootet, sobald ich über Explorer oder Fritz-NAS auf den Onlinespeicher gehe. Ich meine, ich hätte das hier schon irgendwo gelesen, finde es aber momentan grad nicht. Daraufhin hab ich es auch über die Router-7390 mit der 52er Final probiert, dort ist es genauso. Ich hab die Funktion schon längere Zeit nicht mehr genutzt.

Call bei AVM ist raus. Kann das jemand bestätigen?

Ansonsten läuft sowohl die Beta als auch die Final bisher ohne Probleme.

ProTech1982 · 1 Sep 2013

gmeyer schrieb:
Kann das jemand bestätigen?

Ansonsten läuft sowohl die Beta als auch die Final bisher ohne Probleme.

Bei mir ist es auch so...

[Info] FRITZ!Box 7390 Labor-Firmware 84.05.58-26237 vom 22.08.2013

IPPF-Urgestein

Mitglied

Neuer User

Neuer User

Neuer User

Mitglied

IPPF-Promi

Neuer User

IPPF-Urgestein

Neuer User

IPPF-Urgestein

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

Neuer User

Anhänge

IPPF-Urgestein

Neuer User

Neuer User

Benares

Guest

Neuer User

Statistik des Forums