VPN Verbindung bricht neuerdings ab

motions · Beitrag von **motions** » 22 Nov 2006, 13:58

Konfiguration: 2 Standorte per VPN vernetzt
Lancom 1611-I V6.22, Lancom 1621 V6.22
(bringe beide gerade auf V6.26 aber das wird vermutlich die Ursache nicht beheben).
Bisher funktionierte der VPN Kanal seit Monaten problemlos.
Jetzt bricht der aber nach kurzer Zeit zusammen und wird neu initiiert.
ein trace + vpn zeigt folgendes (während eines ping -t gegenstelle bricht die verbindung auch zusammen).
Kann mir da jemand einen Tip zur Fehlerursache geben?
Vielen Dank

[VPN-Packet] 2006/11/22 13:47:24,160
encrypted: 84.141.78.140->217.226.178.139 120 ESP SPI[655194d8]

[VPN-Packet] 2006/11/22 13:47:24,240
received: 217.226.178.139->84.141.78.140 120 ESP SPI[21538ae5]

[VPN-Packet] 2006/11/22 13:47:24,240
decrypted: 217.226.178.139->84.141.78.140 104 IP-ENCAP

[VPN-Packet] 2006/11/22 13:47:24,240
decap: 192.168.10.4->192.168.0.198 60 ICMP ECHOREPLY

[VPN-Status] 2006/11/22 13:47:24,740
IKE info: Delete Notification received for Phase-2 SA ipsec-0-LANCOMBUETTEL-pr0-l0-r0 peer LANCOMBUETTEL spi [0x655194d8]

[VPN-Status] 2006/11/22 13:47:24,750
IKE info: Phase-2 SA removed: peer LANCOMBUETTEL rule ipsec-0-LANCOMBUETTEL-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [655194d8 ] [21538ae5 ]

[VPN-Status] 2006/11/22 13:47:24,750
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-LANCOMBUETTEL peer LANCOMBUETTEL cookies [f36d8b96c552832b 492a15f96d3b6453]

[VPN-Status] 2006/11/22 13:47:24,760
IKE info: Phase-1 SA removed: peer LANCOMBUETTEL rule LANCOMBUETTEL removed

[VPN-Status] 2006/11/22 13:47:24,760
VPN: LANCOMBUETTEL (217.226.178.139) disconnected

[VPN-Status] 2006/11/22 13:47:24,760
VPN: Disconnect info: remote-disconnected (0x4301) for LANCOMBUETTEL (217.226.178.139)

[VPN-Status] 2006/11/22 13:47:24,840
VPN: selecting next remote gateway using strategy eFirst for LANCOMBUETTEL
=> no remote gateway selected

[VPN-Status] 2006/11/22 13:47:24,840
VPN: selecting first remote gateway using strategy eFirst for LANCOMBUETTEL
=> no remote gateway selected

[VPN-Status] 2006/11/22 13:47:24,840
VPN: installing ruleset for LANCOMBUETTEL (0.0.0.0)

[VPN-Status] 2006/11/22 13:47:24,920
VPN: rulesets installed

[VPN-Status] 2006/11/22 13:47:25,180
VPN: global reconnect lock active

[VPN-Status] 2006/11/22 13:47:30,480
VPN: connecting to LANCOMBUETTEL (0.0.0.0)
VPN: establish dynamic VPN negotiator channel

motions · Beitrag von **motions** » 29 Nov 2006, 12:26

noch mal nachgefragt (weil das Problem immer noch besteht):
Kann es sein, das die SA oder Zertifikate ablaufen und erneuert werden müssen?

backslash · Beitrag von **backslash** » 29 Nov 2006, 18:05

Hi motions

[VPN-Status] 2006/11/22 13:47:24,740
IKE info: Delete Notification received for Phase-2 SA ipsec-0-LANCOMBUETTEL-pr0-l0-r0 peer LANCOMBUETTEL spi [0x655194d8]

Hier baut die Gegenseite ganz normal die Verbindung ab - warum auich immer. Das wirst du aber nur auf der Gegenseite sehen können.

ein trace + vpn zeigt folgendes (während eines ping -t gegenstelle bricht die verbindung auch zusammen).
Kann mir da jemand einen Tip zur Fehlerursache geben?

Ist die Gegenseite ein LANCOM (vermutlich, denn sie heißt ja LANCOMBUETTEL)?

Meinst du mit "ping -t gegenstelle" ein Ping direkt an das LANCOM?

Wenn ja: Ist auf dem entfernten LANCOM vielleicht eine Haltezeit konfiguriert?

Wenn ja: dann hast du den Grund für den Abbau gefunden, da ein ping auf das LANCOM selbst nicht Verbindungserhaltend ist - es läuft schlichtweg die Haltezeit ab...

Gruß
Backslash

motions · Beitrag von **motions** » 29 Nov 2006, 22:01

>>Hier baut die Gegenseite ganz normal die Verbindung ab - warum auich immer. Das wirst du aber nur auf der Gegenseite sehen können.<<
Schon mal ein guter Hinweis, dann muss ich mal auf der entfernten Seite schauen. Momentan kann ich von hier auch kein "trace + vpn" ziehen

>>Ist die Gegenseite ein LANCOM (vermutlich, denn sie heißt ja LANCOMBUETTEL)?<<
Ja, LANCOMBUETTEL ist ein 1611-I, mein lokaler ist ein 1621; beide mit Firmware 6.26

>>Meinst du mit "ping -t gegenstelle" ein Ping direkt an das LANCOM?<<
JA

>>Wenn ja: Ist auf dem entfernten LANCOM vielleicht eine Haltezeit konfiguriert?
Wenn ja: dann hast du den Grund für den Abbau gefunden, da ein ping auf das LANCOM selbst nicht Verbindungserhaltend ist - es läuft schlichtweg die Haltezeit ab..<<.

Auf beiden Lancom ist eine Haltezeit von 600 Sekunden definitiert. Aber der Tunnel bricht nach ca. 1 bis 2 Minuten zusammen.
Ich habe gerade mal einen Test mit einer SSH Verbindung zu einer Linuxmaschine im entfernen Netz gemacht (putty); der Tunnel bricht ebenso zusammen.[/quote]

motions · Beitrag von **motions** » 01 Dez 2006, 15:54

So, jetzt habe ich mal die Gegenseite untersucht und dort ein Trace laufen lassen (Fehlermeldung im LancomMonitor bei Abbruch ist dort "Leitungsüberwachung (Line Polling) zum entfernten Gateway fehlgeschlagen [0x1307])"

Hier einige Ausschnitte aus dem trace + vpn dort:

[VPN-Status] 1900/01/10 00:19:04,330
VPN: poll timeout for lancomzentrale (84.141.109.70)
remote site did not answer during interval
(2 retries left)
send poll frame to 192.168.0.253
...
[VPN-Status] 1900/01/10 00:19:06,330
VPN: poll timeout for lancomzentrale (84.141.109.70)
remote site did not answer during interval
no retries left, disconnect channel

[VPN-Status] 1900/01/10 00:19:06,370
VPN: Error: IFC-X-Line-polling-failed (0x1307) for lancomzentrale (84.141.109.70)

[VPN-Status] 1900/01/10 00:19:06,370
VPN: disconnecting lancomzentrale (84.141.109.70)

[VPN-Status] 1900/01/10 00:19:06,420
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-0-lancomzentrale-pr0-l0-r0 to peer lancomzentrale, spi [0x2759ae08]

[VPN-Status] 1900/01/10 00:19:06,420
IKE info: Phase-2 SA removed: peer lancomzentrale rule ipsec-0-lancomzentrale-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [63b19ac2 ] [2759ae08 ]

[VPN-Status] 1900/01/10 00:19:06,430
IKE info: Delete Notificaton sent for Phase-1 SA to peer lancomzentrale

[VPN-Status] 1900/01/10 00:19:06,430
IKE info: Phase-1 SA removed: peer lancomzentrale rule lancomzentrale removed

[VPN-Status] 1900/01/10 00:19:06,530
VPN: selecting next remote gateway using strategy eFirst for lancomzentrale
=> no remote gateway selected

[VPN-Status] 1900/01/10 00:19:06,530
VPN: selecting first remote gateway using strategy eFirst for lancomzentrale
=> no remote gateway selected

[VPN-Status] 1900/01/10 00:19:06,530
VPN: installing ruleset for lancomzentrale (0.0.0.0)

[VPN-Status] 1900/01/10 00:19:06,570
VPN: lancomzentrale (0.0.0.0) disconnected

[VPN-Status] 1900/01/10 00:19:06,580
VPN: rulesets installed

[VPN-Status] 1900/01/10 00:19:10,810

VPN: establish physical channel for lancomzentrale (0.0.0.0)

Okay, also die Leitungsüberwachung schlägt hier fehl.
Aber wo liegt das Problem:
Bei Lancombuettel, welcher die Verbindung trennt und die Leitungsüberwachung überhaupt durchführt?
Oder auf der Seite Lancomzentrale, weil der auf das LinePolling nicht antwortet?

Was mir noch auf der Gegenseite auffiel:
Manchmal steht im LancomMonitor bei den ISDN Ports:
Gegenstelle doppelt [0x010b]
Was bedeutet dieses Fehlermeldung und ist das überhaupt mit dem VPN Problem zusammengehörig (obwohl darüber ja die gegenseitigen dyn. IP Adressen für's VPN ausgehandelt werden).

backslash · Beitrag von **backslash** » 01 Dez 2006, 17:05

Hi motions

Okay, also die Leitungsüberwachung schlägt hier fehl.
Aber wo liegt das Problem:
Bei Lancombuettel, welcher die Verbindung trennt und die Leitungsüberwachung überhaupt durchführt?
Oder auf der Seite Lancomzentrale, weil der auf das LinePolling nicht antwortet?

hast du in der Zentrale etwa ping-Blocking eingeschaltet?

Abgesehen davon, daß ping-Blocking mitnichten sagt, daß dort niemand ist, sondern nur daß dort jemand ist, der ein Schild hochhält, aufdem "du kannst mich nicht sehen" steht, solltest du es maximal für die Default-Route aktivieren, da sonst das Linepolling im VPN fehlschlägt.

Manchmal steht im LancomMonitor bei den ISDN Ports:
Gegenstelle doppelt [0x010b]
Was bedeutet dieses Fehlermeldung

Die Meldung kommt dann, wenn zwei Einwahlen mit dem selben Usernamen erfolgen...

und ist das überhaupt mit dem VPN Problem zusammengehörig

eher nicht

(obwohl darüber ja die gegenseitigen dyn. IP Adressen für's VPN ausgehandelt werden).

Du machst das ganze nicht düber den D-Kanal? Hast du die LANCOMs hinter eine TK-Anlage stehen, die die D-Kanalübermittlung verhindert? Wenn nein, dann soltest du auf den kostenpflichtigen Verbindungsaufbau verzichten

Gruß
Backslash

motions · Beitrag von **motions** » 01 Dez 2006, 18:54

>>hast du in der Zentrale etwa ping-Blocking eingeschaltet?<<
Nein.
Die Firewall in der Zentrale ist sogar abgeschaltet (für diese Untersuchungen und Tests)
Haltezeit und Dead-Peer Detection sind auf beiden Seiten gesetzt auf 600/60. Habe ich eben auch mal auf 0/0 gesetzt, aber das verbessert die Situation nicht.

>>Du machst das ganze nicht düber den D-Kanal? Hast du die LANCOMs hinter eine TK-Anlage stehen, die die D-Kanalübermittlung verhindert? Wenn nein, dann soltest du auf den kostenpflichtigen Verbindungsaufbau verzichten<<
Als Dyn.VPN Verbindungsoption habe ich gesetzt:
Dyn VPN (IP Adressen werden nach Möglichkeit ohne Verbindungsaufbau übermittel). Das sollte schon die richtige Option sein. Es kann aber sein, das eine (oder beide) TK-Anlagen das irgendwie blocken.
Kann man da irgendwie einen Test machen (z.B. von einer CAPI aus)?

Aber ich glaube ich nähere mich dem Problem:
Auf Lancombuettel habe ich die Firewall jetzt mal deaktiviert.
Ich beobachte jetzt mal eine putty/top Sitzung auf einem entfernen Linux server; sieht bisher gut aus!
Aber irgendwie habe ich momentan auch massive ISDN Störungen (unter anderem "Verbindungsaufbau fehlgeschlagen (D-Kanal)". Also geht das wohl schon auf den gebührenlosen Kanal.

Daniel.Sun · Beitrag von **Daniel.Sun** » 21 Dez 2006, 15:45

Hallo

also ich habe das identische Problem mit den identischen Fehlermeldungen.

Mein System lief seit dem 23.03.2006 bis zum 18.12.2006 völlig Problemlos aber seit dem 18.12.2006 habe ich den Verbindungsabbruch.

Also falls irgendwas interessantes rauskommt bitte melden.

MfG
Daniel

motions · Beitrag von **motions** » 21 Jun 2007, 10:04

Das Problem ist seit einigen Tagen plötzlich wieder da. Die Firewalls sind an beiden Seiten ausgeschaltet.
Gibt es hier bei anderen Anwender neue Erkenntnisse?
Firmware ist 6.32 auf beiden Seiten

motions · Beitrag von **motions** » 21 Jun 2007, 10:25

Hier ein aktueller Mitschnitt per trace + vpn-status;
Die VPN Verbindungen dauern jetzt immer nur 30 Sekunden bis zum ersten Timeout

Code: Alles auswählen

[VPN-Status] 2007/06/21 10:21:05,290
VPN: connecting to LANCOMBUETTEL (0.0.0.0)
VPN: establish dynamic VPN negotiator channel

[VPN-Status] 2007/06/21 10:21:09,010
VPN: received dynamic VPN V2 authentication packet from LANCOMBUETTEL (217.226.160.158)
     DNS: 192.168.10.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.10.253

[VPN-Status] 2007/06/21 10:21:09,020
VPN: installing ruleset for LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:09,030
VPN: ruleset installed for LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:09,030
VPN: create dynamic VPN V2 authentication packet for LANCOMBUETTEL (217.226.160.158)
     DNS: 192.168.0.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.0.253

[VPN-Status] 2007/06/21 10:21:09,040
VPN: start IKE negotiation for LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:09,090
VPN: rulesets installed

[VPN-Status] 2007/06/21 10:21:09,090
IKE info: Phase-1 negotiation started for peer LANCOMBUETTEL rule isakmp-peer-LANCOMBUETTEL using MAIN mode


[VPN-Status] 2007/06/21 10:21:09,200
VPN: received dynamic VPN V2 authentication packet from LANCOMBUETTEL (217.226.160.158)
     DNS: 192.168.10.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.10.253

[VPN-Status] 2007/06/21 10:21:09,210
IKE info: The remote server 217.226.160.158:500 peer LANCOMBUETTEL id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 217.226.160.158:500 peer LANCOMBUETTEL id <no_id> negotiated rfc-3706-dead-peer-detection


[VPN-Status] 2007/06/21 10:21:09,210
IKE info: Phase-1 remote proposal 1 for peer LANCOMBUETTEL matched with local proposal 1


[VPN-Status] 2007/06/21 10:21:10,090
VPN: received dynamic VPN V2 authentication packet from LANCOMBUETTEL (217.226.160.158)
     DNS: 192.168.10.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.10.253

[VPN-Status] 2007/06/21 10:21:10,210
IKE info: Phase-1 [inititiator] for peer LANCOMBUETTEL between initiator id  91.6.210.47, responder id  217.226.160.158 done
IKE info: SA ISAKMP for peer LANCOMBUETTEL encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)


[VPN-Status] 2007/06/21 10:21:11,080
VPN: received dynamic VPN V2 authentication packet from LANCOMBUETTEL (217.226.160.158)
     DNS: 192.168.10.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.10.253

[VPN-Status] 2007/06/21 10:21:11,170
IKE info: Phase-2 [inititiator] done with 2 SAS for peer LANCOMBUETTEL rule ipsec-0-LANCOMBUETTEL-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.10.0/255.255.255.0 '
IKE info: SA ESP [0x458e847a]  alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x7d78e98d]  alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1600 sec/160000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 91.6.210.47 dst: 217.226.160.158  


[VPN-Status] 2007/06/21 10:21:12,180
VPN: LANCOMBUETTEL (217.226.160.158) connected, set poll timer to 30 sec

[VPN-Status] 2007/06/21 10:21:17,180
VPN: poll timeout for LANCOMBUETTEL (217.226.160.158)
send poll frame to 192.168.10.253

[VPN-Status] 2007/06/21 10:21:17,240
VPN: Poll reply from LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:47,180
VPN: poll timeout for LANCOMBUETTEL (217.226.160.158)
remote site answered during intervall
send poll frame to 192.168.10.253

[VPN-Status] 2007/06/21 10:21:47,240
VPN: Poll reply from LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:52,110
IKE info: Delete Notification received for Phase-2 SA ipsec-0-LANCOMBUETTEL-pr0-l0-r0 peer LANCOMBUETTEL spi [0x458e847a]


[VPN-Status] 2007/06/21 10:21:52,110
IKE info: Phase-2 SA removed: peer LANCOMBUETTEL rule ipsec-0-LANCOMBUETTEL-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [458e847a  ] [7d78e98d  ]


[VPN-Status] 2007/06/21 10:21:52,120
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-LANCOMBUETTEL peer LANCOMBUETTEL cookies [4a4a79b978cb64e7 052b52818dd12367]


[VPN-Status] 2007/06/21 10:21:52,120
IKE info: Phase-1 SA removed: peer LANCOMBUETTEL rule LANCOMBUETTEL removed


[VPN-Status] 2007/06/21 10:21:52,130
VPN: LANCOMBUETTEL (217.226.160.158) disconnected

[VPN-Status] 2007/06/21 10:21:52,130
VPN: Disconnect info: remote-disconnected (0x4301) for LANCOMBUETTEL (217.226.160.158)

[VPN-Status] 2007/06/21 10:21:52,210
VPN: selecting first remote gateway using strategy eFirst for LANCOMBUETTEL
     => no remote gateway selected

[VPN-Status] 2007/06/21 10:21:52,210
VPN: installing ruleset for LANCOMBUETTEL (0.0.0.0)

[VPN-Status] 2007/06/21 10:21:52,300
VPN: rulesets installed

[VPN-Status] 2007/06/21 10:21:52,510
VPN: global reconnect lock active

motions · Beitrag von **motions** » 21 Jun 2007, 11:38

Eben habe ich mich noch mal ins Auto gesetzt und bin zur Gegenstelle gefahren.
Das Log dort sieht vielversprechender aus:

Code: Alles auswählen

[VPN-Status] 1900/01/09 06:11:47,890
VPN: connecting to LANCOMWILSTER (0.0.0.0)
VPN: establish dynamic VPN negotiator channel

[VPN-Status] 1900/01/09 06:11:50,520
VPN: received dynamic VPN V2 authentication packet from LANCOMWILSTER (91.6.210.47)
     DNS: 192.168.0.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.0.253

[VPN-Status] 1900/01/09 06:11:50,520
VPN: installing ruleset for LANCOMWILSTER (91.6.210.47)

[VPN-Status] 1900/01/09 06:11:50,540
VPN: ruleset installed for LANCOMWILSTER (91.6.210.47)

[VPN-Status] 1900/01/09 06:11:50,540
VPN: create dynamic VPN V2 authentication packet for LANCOMWILSTER (91.6.210.47)
     DNS: 192.168.10.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.10.253

[VPN-Status] 1900/01/09 06:11:50,540
VPN: start IKE negotiation for LANCOMWILSTER (91.6.210.47)

[VPN-Status] 1900/01/09 06:11:50,580
VPN: rulesets installed

[VPN-Status] 1900/01/09 06:11:50,590
IKE info: Phase-1 negotiation started for peer LANCOMWILSTER rule isakmp-peer-LANCOMWILSTER using MAIN mode


[VPN-Status] 1900/01/09 06:11:50,710
VPN: received dynamic VPN V2 authentication packet from LANCOMWILSTER (91.6.210.47)
     DNS: 192.168.0.253, 0.0.0.0
     NBNS: 0.0.0.0, 0.0.0.0
     polling address: 192.168.0.253

[VPN-Status] 1900/01/09 06:11:50,750
IKE info: The remote server 91.6.210.47:500 peer LANCOMWILSTER id <no_id> is Enigmatec IPSEC version 1.5.1
IKE info: The remote server 91.6.210.47:500 peer LANCOMWILSTER id <no_id> negotiated rfc-3706-dead-peer-detection


[VPN-Status] 1900/01/09 06:11:50,750
IKE info: Phase-1 remote proposal 1 for peer LANCOMWILSTER matched with local proposal 1


[VPN-Status] 1900/01/09 06:11:51,640
IKE info: Phase-1 [inititiator] for peer LANCOMWILSTER between initiator id  217.226.133.36, responder id  91.6.210.47 done
IKE info: SA ISAKMP for peer LANCOMWILSTER encryption aes-cbc authentication md5
IKE info: life time ( 108000 sec/ 0 kb)


[VPN-Status] 1900/01/09 06:11:52,460
IKE info: Phase-2 [inititiator] done with 2 SAS for peer LANCOMWILSTER rule ipsec-0-LANCOMWILSTER-pr0-l0-r0
IKE info: rule:' ipsec 192.168.10.0/255.255.255.0 <-> 192.168.0.0/255.255.255.0 '
IKE info: SA ESP [0x7fbcdebd]  alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x476e4579]  alg AES keylength 128 +hmac HMAC_MD5 incoming
IKE info: life soft( 1600 sec/160000 kb) hard (2000 sec/200000 kb)
IKE info: tunnel between src: 217.226.133.36 dst: 91.6.210.47  


[VPN-Status] 1900/01/09 06:11:53,460
VPN: LANCOMWILSTER (91.6.210.47) connected, set poll timer to 30 sec

[VPN-Status] 1900/01/09 06:11:58,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:28,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
setting poll time to 1 sec. 
(5 retries left)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:29,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
(4 retries left)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:30,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
(3 retries left)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:31,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
(2 retries left)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:32,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
(1 retries left)
send poll frame to 192.168.0.253

[VPN-Status] 1900/01/09 06:12:33,460
VPN: poll timeout for LANCOMWILSTER (91.6.210.47)
remote site did not answer during interval
no retries left, disconnect channel

[VPN-Status] 1900/01/09 06:12:33,500
VPN: Error: IFC-X-Line-polling-failed (0x1307) for LANCOMWILSTER (91.6.210.47)

[VPN-Status] 1900/01/09 06:12:33,500
VPN: disconnecting LANCOMWILSTER (91.6.210.47)

[VPN-Status] 1900/01/09 06:12:33,540
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-0-LANCOMWILSTER-pr0-l0-r0 to peer LANCOMWILSTER, spi [0x476e4579]


[VPN-Status] 1900/01/09 06:12:33,540
IKE info: Phase-2 SA removed: peer LANCOMWILSTER rule ipsec-0-LANCOMWILSTER-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [7fbcdebd  ] [476e4579  ]


[VPN-Status] 1900/01/09 06:12:33,550
IKE info: Delete Notificaton sent for Phase-1 SA to peer LANCOMWILSTER


[VPN-Status] 1900/01/09 06:12:33,550
IKE info: Phase-1 SA removed: peer LANCOMWILSTER rule LANCOMWILSTER removed


[VPN-Status] 1900/01/09 06:12:33,650
VPN: selecting first remote gateway using strategy eFirst for LANCOMWILSTER
     => no remote gateway selected

[VPN-Status] 1900/01/09 06:12:33,650
VPN: installing ruleset for LANCOMWILSTER (0.0.0.0)

[VPN-Status] 1900/01/09 06:12:33,680
VPN: LANCOMWILSTER (0.0.0.0) disconnected

[VPN-Status] 1900/01/09 06:12:33,690
VPN: rulesets installed

Also liegt der Fehler wohl am Router "LANCOMWILSTER".
Aber wo muss ich da ansetzen, da dieser wohl nicht auf die Polling-Requests reagiert?

motions · Beitrag von **motions** » 21 Jun 2007, 11:47

Ich glaube ich bin der ursache näher gekommen:
Obwohl die Firewall AUSGESCHALTET ist, sind die "Vorsichtsmaßnahmen" trotzdem aktiv. Dort stand der "Ping blockieren" auf "nur WAN". Das ist hier wohl die Fehlerursache.
Ich habe den Ping-Blocker jetzt mal auf "aus" gesetzt habe, sieht es viel besser aus.
Trotzdem werde ich das jetzt noch mal beobachten ...

backslash · Beitrag von **backslash** » 21 Jun 2007, 12:34

Hi motions

ja, das ping-blocking dürfte der Grund gewesen sein...

Zum Thema Ping-Blocking und Stealth-Mode ist eh nur zu sagen, daß diese keinerlei Sicherheit bieten, auch wenn die Redakteure von Comuter-Bild & Co das meinen und immer wieder propagieren.

Ein blockiertes ping sagt nämlich nicht, daß dart keiner siztz, sondern nur, daß dort einer sitzt, der ein Schild hochhält, uaf dem steht: "du kannst mich nicht sehen" - und das macht ihn für Angreifer erst recht interressant. Wäre da wirklich niemand, dann würde der Router vorher ein "ICMP host unreachable" zurückschicken.

Genauso verhält es sich mit dem Stealth-Mode... Wäre da niemand, würdest du vom Router vorher ein "ICMP host unreachable" bekommen...

Daher: Ping niemals blockieren und Stealthmode niemals aktivieren. Es bringt eine Sicherheit, erschwert hingegen die Fehlersuche oder schlimmer noch: verhindert korrekte Funktion - wie in deinem Fall...

Gruß
Backslash

motions · Beitrag von **motions** » 21 Jun 2007, 14:30

Ja, die Logik leuchtet mir ein.
Die Konsequenz ist jedoch, das ein VPN mit aktivierem Ping-Stealth nicht sicher betreibbar ist. Da wäre ein Warnhinweis in der Lanconfig nicht schlecht.
Auch überhaupt auf die Idee zu kommen, das der Leitungspoll auf Ping basiert und nicht auf internen IPsec poll commandos, Schlüsseltausch etc (bin da jetzt nicht so der IPSEC Spezialist).
Bei RAS Verbindungen wird ja auch ein andere Poll verwendet (kann mich jetzt nicht erinnern wie der hieß).
Wichtig ist also die Erkenntnis: KEIN Ping-Stealth bei VPN Verbindungen; von der eher trügerischen Sicherheit dieser Funktion überhaupt abgesehen.
ich beobachte die Leitung jetzt schon seit einigen Stunden: Funzt einwandfrei!
Dann kann ich ja jetzt die Firewall wieder zuschalten!