VPN LAN - LAN Verbindungsproblem

[whitesharky]

Hallo Leute,

ich benötige einen Tip.

Ich habe eine VPN LAN - LAN Verbindung die wenn die Verbindung steht funktioniert.

Hier Gegenstelle A und B genannt.

A - LC 1721
B - LC 1711
- beide feste IP
- Gegenstelle B ist ein Cronjob wegen Zwangstrennung mit Befehl do/o/m/d DSLLEIPZ eingerichtet
- Gegenstelle B macht Polling über VPN auf Server hinter A

Leider kann diese Verbindung nur von Gegenstelle A aufgebaut werden. Bei getrennter Verbindung kann Gegenstelle B das VPN nicht aufbauen.

Das ist der Trace von B wenn diese versucht die Verbindung aufzubauen:

#
| LANCOM 1711 VPN
| Ver. 6.26.0022 / 13.11.2006
| SN. 035080600052
| Copyright (c) LANCOM Systems

lancom02_leipzig, Connection No.: 002 (WAN)

Username:
Password:

root@lancom02_leipzig:/
> trace + vpn-status
VPN-Status ON

root@lancom02_leipzig:/
>
[VPN-Status] 1900/01/04 16:47:52,690
VPN: Disconnect info: physical-disconnected (0x4304) for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:47:52,690
VPN: disconnecting LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:47:52,710
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-0-LANCOM01_XANTEN-pr0-l0-
r0 to peer LANCOM01_XANTEN, spi [0x6f5afa51]

[VPN-Status] 1900/01/04 16:47:52,710
IKE info: Phase-2 SA removed: peer LANCOM01_XANTEN rule ipsec-0-LANCOM01_XANTEN-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [7176970b ] [6f5afa51 ]

[VPN-Status] 1900/01/04 16:47:52,710
IKE info: Delete Notificaton sent for Phase-1 SA to peer LANCOM01_XANTEN

[VPN-Status] 1900/01/04 16:47:52,710
IKE info: Phase-1 SA removed: peer LANCOM01_XANTEN rule LANCOM01_XANTEN removed

[VPN-Status] 1900/01/04 16:47:52,750
VPN: connecting to LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:47:52,750
VPN: selecting next remote gateway using strategy eFirst for LANCOM01_XANTEN
=> no remote gateway selected

[VPN-Status] 1900/01/04 16:47:52,750
VPN: selecting first remote gateway using strategy eFirst for LANCOM01_XANTEN
=> CurrIdx=0, IpStr=> x.x.x.79<, IpAddr= x.x.x.79, IpTtl=0s

[VPN-Status] 1900/01/04 16:47:52,750
VPN: installing ruleset for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:47:52,770
VPN: LANCOM01_XANTEN (x.x.x.79) disconnected

[VPN-Status] 1900/01/04 16:47:52,790
VPN: rulesets installed

[VPN-Status] 1900/01/04 16:47:53,760
VPN: Error: IFC-I-No-poll-table-entry-matched (0x1108) for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:48:33,880
VPN: connecting to LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:48:33,880
VPN: installing ruleset for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:48:33,900
VPN: ruleset installed for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:48:33,900
VPN: start IKE negotiation for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:48:33,920
VPN: rulesets installed

[VPN-Status] 1900/01/04 16:48:33,920
IKE info: Phase-1 negotiation started for peer LANCOM01_XANTEN rule isakmp-peer-
LANCOM01_XANTEN using MAIN mode

[VPN-Status] 1900/01/04 16:49:03,920
VPN: connection for LANCOM01_XANTEN (x.x.x.79) timed out: no response

[VPN-Status] 1900/01/04 16:49:03,920
VPN: Error: IFC-I-Connection-timeout-IKE-IPSEC (0x1106) for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:03,920
VPN: disconnecting LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:03,930
VPN: LANCOM01_XANTEN (x.x.x.79) disconnected

[VPN-Status] 1900/01/04 16:49:03,940
VPN: connecting to LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:03,950
VPN: selecting next remote gateway using strategy eFirst for LANCOM01_XANTEN
=> no remote gateway selected
[VPN-Status] 1900/01/04 16:49:03,950
VPN: selecting first remote gateway using strategy eFirst for LANCOM01_XANTEN
=> CurrIdx=0, IpStr=> x.x.x.79<, IpAddr= x.x.x.79, IpTtl=0s

[VPN-Status] 1900/01/04 16:49:03,950
VPN: installing ruleset for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:03,960
VPN: ruleset installed for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:03,960
VPN: rulesets installed

[VPN-Status] 1900/01/04 16:49:33,960
VPN: connection for LANCOM01_XANTEN (x.x.x.79) timed out: no response

[VPN-Status] 1900/01/04 16:49:34,970
VPN: Error: IFC-I-No-poll-table-entry-matched (0x1108) for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:40,770
VPN: connecting to LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:40,770
VPN: installing ruleset for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:40,790
VPN: ruleset installed for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:40,790
VPN: start IKE negotiation for LANCOM01_XANTEN (x.x.x.79)

[VPN-Status] 1900/01/04 16:49:40,800
VPN: rulesets installed

[VPN-Status] 1900/01/04 16:49:40,810
IKE info: Phase-1 negotiation started for peer LANCOM01_XANTEN rule isakmp-peer-
LANCOM01_XANTEN using MAIN mode


[VPN-Status] 1900/01/04 16:49:55,990
IKE info: The remote server x.x.x.79:500 peer LANCOM01_XANTEN id <no_id> is
Enigmatec IPSEC version 1.5.1
IKE info: The remote server x.x.x.79:500 peer LANCOM01_XANTEN id <no_id> neg
otiated rfc-3706-dead-peer-detection


[VPN-Status] 1900/01/04 16:49:55,990
IKE info: Phase-1 remote proposal 1 for peer LANCOM01_XANTEN matched with local
proposal 1


[VPN-Status] 1900/01/04 16:49:56,390
IKE info: Phase-1 [responder] for peer LANCOM01_XANTEN between initiator id 217
.91.17.79, responder id x.x.x.120 done
IKE info: SA ISAKMP for peer LANCOM01_XANTEN encryption aes-cbc authentication m
d5
IKE info: life time ( 108000 sec/ 0 kb)


[VPN-Status] 1900/01/04 16:49:56,520
IKE info: Phase-2 remote proposal 1 for peer LANCOM01_XANTEN matched with local
proposal 1


[VPN-Status] 1900/01/04 16:49:56,680
IKE info: Phase-2 [responder] done with 2 SAS for peer LANCOM01_XANTEN rule ipse
c-0-LANCOM01_XANTEN-pr0-l0-r0
IKE info: rule:' ipsec 10.1.1.0/255.255.255.0 <-> 192.168.0.0/255.255.224.0 '
IKE info: SA ESP [0x5711c8c1] alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x5e96ea1e] alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1800 sec/180000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: x.x.x.120 dst: x.x.x.79


[VPN-Status] 1900/01/04 16:49:57,690
VPN: LANCOM01_XANTEN (x.x.x.79) connected

[VPN-Status] 1900/01/04 16:49:57,920
IKE info: The remote server x.x.x.79:500 peer LANCOM01_XANTEN id <no_id> is
Enigmatec IPSEC version 1.5.1
IKE info: The remote server x.x.x.79:500 peer LANCOM01_XANTEN id <no_id> neg
otiated rfc-3706-dead-peer-detection

[VPN-Status] 1900/01/04 16:49:57,920
IKE info: Phase-1 remote proposal 1 for peer LANCOM01_XANTEN matched with local
proposal 1

[VPN-Status] 1900/01/04 16:50:13,440
IKE log: 165013 Default message_recv: invalid cookie(s) 6a213c407958cf3c 6a4b362
d0db91ef6

[VPN-Status] 1900/01/04 16:50:13,440
IKE log: 165013 Default dropped message from x.x.x.79 port 500 due to notifi
cation type INVALID_COOKIE


[VPN-Status] 1900/01/04 16:50:13,450
IKE info: dropped message from peer unknown x.x.x.79port 500 due to notific
ation type INVALID_COOKIE


[VPN-Status] 1900/01/04 16:50:24,450
IKE log: 165024 Default message_recv: invalid cookie(s) 6a213c407958cf3c 6a4b362
d0db91ef6

[VPN-Status] 1900/01/04 16:50:24,450
IKE log: 165024 Default dropped message from x.x.x.79 port 500 due to notifi
cation type INVALID_COOKIE

[VPN-Status] 1900/01/04 16:50:24,450
IKE info: dropped message from peer unknown x.x.x.79 port 500 due to notific
ation type INVALID_COOKIE

Was ist das Problem?

Danke Whitesharky!

[backslash]

Hi whitesharky

hier hat offenbar die Zwangstrennung zugeschlagen und die Gegenseite hat das nicht mitbekommen, weil die Telekom die Verbindung nicht mehr wie früher sauber trennt sondern kannhart abbricht.

Deshalb nimmt die Gegestelle zunächst auch keine IKE-Pakete an und der Aufbauversuch endet im Timeout. Nachdem die Gegenseite den Abbruch über DPD bemerkt hat, kommt die Verbindung auch wieder zustande. Welche Seite dabei nun zum Tragen kommt, ist wohl eher zufällig.

Gruß
Backslash

[whitesharky]

Hallo Backslash,

danke für die Antwort.

Was ist mit DPD gemeint? Kann man in diesem Fall etwas machen?

Ich bekomme seit ca. 1 Woche jeden Morgen einen Anruf von der Gegenstelle B das diese nicht in das Netz A kommen. Dann mache ich einen Ping ins Netz B und die VPN-Verbindung steht wieder. Eigenartiger Weise hat es vor der o. g. Woche prima funktioniert. Ich habe auch schon mal mit der DTAG telefoniert um die Leitung mal zu prüfen. Die konnten eine hohe Dämpfung feststellen und arbeiten daran. Ich kann mir aber kaum vorstellen, das es an die Dämpfung damit etwas zu tun hat.

Gruß
Whitesharky

[backslash]

Hi whitesharky

Was ist mit DPD gemeint? Kann man in diesem Fall etwas machen?

DPD steht für Dead Peer Detection und ist dafür da, diesen Zustand zu erkennen und den VPN-Tunnel abzubauen. Ohne DPD würde es u.U. Stunden (und zwar solange, bis die Lifetime der Phase 1 abläuft) dauern bis wieder eine Verbindung möglich ist.

In obigem Trace ist die Verbindung duch die Zwangstrennung oder gar einen Sync-Verlust des Modems abgebaut worden und nicht durch die Cron-Tabelle. Das hat die andere Seite halt nicht mitbekommen, weshalb hier nun DPD greifen muß. Der Default für DPD ist 60, d.h. daß die Gegenstelle alle 60 Sekunden geprüft wird. Die andere Seite erkennt den Zusammenbruch auch erst nach Ablauf dieser Zeit (genauer der doppelten Zeit). In dieser Zeit nimmt sie keine IKE-Pakete an und der Tunnel kann nicht aufgebaut werden, wodurch es zum Timeout kommt .

Im Trace tritt dieser Timeout auch genau zweimal auf (was nebenbei bemerkt genau einer Minute entspricht), bis der Tunnel wieder aufgebaut wird. In jedem Fall ist der Tunnel im Trace ja wieder hochgekommen.

Hier der Ablauf:


um 16:47:52 ist die Internetverbindung zusammengebrochen...

um 16:48:33 wird zum ersten Mal versucht den Tunnel neu aufzubauen (das deutet auf einen Sync-Verlust des Modems hin, weil die Internetverbindung in dieser Zeit offenbar nicht verfügbar war)

um 16:49:03 läuft dieser Versuch in einen Timeout (weil die Gegenseite den Zusammenbruch noch nicht mitbekommen hat)

um 16:49:03 wird erneut versucht die Verbindung aufzubauen

um 16:49:33 läuft auch dieser Versuch in einen Timeout

um 16:49:40 startet der dritte Versuch

um 16:49:55 hat die gegenseite den Zusammenbruch bemerkt und antwortet nun auch auf den dritten Versuch

und um 16:49:57 steht der Tunnel wieder


Wenn die Kollegen im Netz B schon nach zwei Minuten anrufen, dann ist das deutlich übertrieben... Du kannst aber den DPD-Timeout auf 30 Sekunden herabsetzen, dann dauert das ganze nur eine Minute

Die konnten eine hohe Dämpfung feststellen und arbeiten daran. Ich kann mir aber kaum vorstellen, das es an die Dämpfung damit etwas zu tun hat.

Doch, denn die Dämpfung dürfte für den Sync-Verlust des Modems verantwortlich sein...

Gruß
Backslash

[whitesharky]

Hallo Backslash,

danke für deine umfassende Antwort. Super.

DPD - oh Mann, klar jetzt wo du es sagst. Peinlich , peinlich

Schönen Tag noch
Gruß
Whitesharky