IFC-I-Connection-timeout-IKE-IPSEC

[Avalanche]

Hallo,
ich versuche gerade rauszufinden, was genau bei einer VPN-Verbindung schief geht.

Internet <----> Speedport 722V <------> Lancom 1781AW

Die Verbindung lief zuvor für mehrere Wochen stabil. Heute nacht wurde die DSL-Verbindung getrennt und danach konnte die VPN-Verbindung nicht mehr aufgebaut werden (IP-Adressen wurden abgeändert).

Code: Alles auswählen

[VPN-Status] 2012/06/05 10:05:27,964
VPN: set local server addresses for IPSEC (3.3.3.3)
   DNS:  99.99.99.1, 0.0.0.0
   NBNS: 99.99.99.1, 0.0.0.0

[VPN-Status] 2012/06/05 10:05:27,964
vpn-maps[20], remote: IPSEC, nego, dns-name, static-name, connected-by-name

[VPN-Status] 2012/06/05 10:05:27,964
VPN: installing ruleset for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:27,975
VPN: ruleset installed for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:27,975
VPN: start dynamic VPN negotiation for IPSEC (3.3.3.3) via ICMP/UDP

[VPN-Status] 2012/06/05 10:05:27,975
VPN: create dynamic VPN V2 authentication packet for IPSEC (3.3.3.3)
   DNS:  99.99.99.1, 0.0.0.0
   NBNS: 99.99.99.1, 0.0.0.0
   polling address: 99.99.99.1

[VPN-Status] 2012/06/05 10:05:27,975
VPN: dynamic VPN V2 packet send to IPSEC (3.3.3.3)
dynamic VPN V2 header:
    Version: 2
    HdrLen: 20
    InfoLen: 40
    MsgType: address info (1)
    Flags: 0x0000
      Responser: no
    Challenge: 2046216221

[VPN-Status] 2012/06/05 10:05:27,975
VPN: start IKE negotiation for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:27,975
VPN: WAN state changed to WanProtocol for IPSEC (3.3.3.3), called by: 00785a60

[VPN-Status] 2012/06/05 10:05:27,976
VPN: rulesets installed

[VPN-Status] 2012/06/05 10:05:27,976
IKE info: Phase-1 negotiation started for peer IPSEC rule isakmp-peer-IPSEC using MAIN mode


[VPN-Status] 2012/06/05 10:05:28,011
IKE info: The remote peer IPSEC supports NAT-T in draft mode
IKE info: The remote peer IPSEC supports NAT-T in draft mode
IKE info: The remote peer IPSEC supports NAT-T in RFC mode
IKE info: The remote server 3.3.3.3:500 (UDP) peer IPSEC id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 3.3.3.3:500 (UDP) peer IPSEC id <no_id> negotiated rfc-3706-dead-peer-detection


[VPN-Status] 2012/06/05 10:05:28,011
IKE info: Phase-1 remote proposal 1 for peer IPSEC matched with local proposal 1


[VPN-Status] 2012/06/05 10:05:28,012
icmp/upd reply for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:28,012
PING_ECHO, AuthFlags: 7, LastConf: 8320, DynVpnMode: 8, StTunnel: 1

[VPN-Status] 2012/06/05 10:05:28,012
VPN: stop ping for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:57,976
VPN: connection for IPSEC (3.3.3.3) timed out: no response

[VPN-Status] 2012/06/05 10:05:57,976
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for IPSEC (3.3.3.3)

[VPN-Status] 2012/06/05 10:05:57,976
VPN: disconnecting IPSEC (3.3.3.3)

Einstellungen:
Haltezeit: 9999 Sekunden
Extranet-Adresse: 0.0.0.0
Regelerzeugung: Automatisch
Dynamisches VPN (UDP Paket zur Übermittlung der IP-Adresse)

[Jirka]

Hallo Avalanche,

welche IP-Adressen wurden denn geändert? Die aus dem lokalen Netz? Das muss dann auch dem VPN-Router auf der Gegenseite mitgeteilt werden...

Viele Grüße,
Jirka

[Avalanche]

Was meinst Du mit lokalem Netz? Der Lancom hat eine feste Zuweisung aus dem Netz des Speedport Routers. Die sollte sich also nicht geändert haben.

[Jirka]

Hallo Avalanche,

mit lokalem Netz meine ich das lokale IP-Netz im Intranet (andere Bezeichnung IP-Netzwerk oder ARF-Netz).

Viele Grüße,
Jirka

[Avalanche]

Nein, Missversändnis!
Es hat sich keine Konfiguration geändert. Ich habe nur in der hier geposteten Ausgabe die Werte ersetzt. Sorry dass ich das so unglücklich formuliert hatte.

[Jirka]

Hallo Avalanche,

ja, dann sollte es man auf beiden Seiten mal mit einem 'show vpn' auf der Konsole versuchen und die entsprechenden Einträge vergleichen...
Mit dem Trace wo auch noch die IPs geändert sind da oben, kommt man nicht weiter.

Viele Grüße,
Jirka

[Avalanche]

Ich konnte es übrigens dadurch reparieren, dass ich den HTTPS-Tunnelmodus aktiviert habe (d.h. keine anderen Netzbeziehungen o.ä.). Meine Frage zielt also eher darauf ab, ob jemand ein ähnliches Problem schon einmal hatte.

Ich werde das wohl ggf. nochmal vor Ort debuggen müssen. Vielen Dank für die Hilfe!

[Jirka]

Hallo Avalanche,

da hat sich dann wohl eher auf dem Speedport was geändert?! Keine Portforwardings mehr da? Firmware-Update durchgeführt/durchgeführt worden?

Viele Grüße,
Jirka

[Avalanche]

Ich weiß es schlichtweg nicht! Nachdem da fast 2h downtime waren, könnte es durchaus sein, dass die Telekom Änderungen vorgenommen hat bzw. ein Firmwareupdate eingespielt hat.

Portforwarding ist doch für IPSEc gar nicht nötig wenn der rechte Lancom die Verbindung aufbaut, oder?

[Dr.Einstein]

Hallo Avalanche,

du benutzt dyn. VPN obwohl der Lancom Router seine eigene öffentliche IP-
Adresse nicht bekannt ist. Bei solchen Konstellationen kann man Glück haben,
dass die VPNs überhaupt zustande kommen, aber wenn sie dann nicht mehr
funktionieren, ist es ein Zeichen, auf Aggressiv-Mode umzuschwenken, oder auf
DDNS Anbieter.

Gruß Dr.Einstein