VPN ohne extra client WinXP -> 1811 Problem

Michael Rignaz · Beitrag von **Michael Rignaz** » 26 Okt 2006, 17:12

Hey backslash und eddia, danke euch vielmals für die weitere Unterstützung!
Hat alles nichts geholfen.
Um ein NAT Problem mit meinem router auszuschließen hab ich mal die Verbindung zum ISP direkt von meinem Rechner via PPTP aufgebaut.. keine psfw o.ä. aktiv. --> Selbes Phänomen..

Ist es vielleicht möglich irgendwie anders als über Polling Listen (da die ips an den clients ja dynamisch sind) vom lancom aus festzustellen wann die VPN Verbindung tot ist und sie automatisch neu aufzubauen (für den lancom besteht die Verbindung weiterhin)?Oder kann ich das vom Client aus ohne Zusatztools erreichen (die server ips bleiben ja konstant... also art polling liste von winxp aus?)
Die Lancom sollte das ja feststellen und neu aufbauen, aber das dauert viel zu lange (~5-10 Minuten disconnect bevors neu aufgebaut wird).

Vielen Dank

Lg,
Michael

backslash · Beitrag von **backslash** » 26 Okt 2006, 18:57

Hi Michael Rignaz

Ist es vielleicht möglich irgendwie anders als über Polling Listen (da die ips an den clients ja dynamisch sind)

Der Client hat doch "hinter dem Tunnel" eine feste IP-Adresse - und die kannst du problemlos vom LANCOM aus anpingen.
Ansonsten gäbe as da noch DPD (Dead Peer Detection), aber ob der Windows-Client das kann, weiß ich nicht.

Gruß
Backslash

Michael Rignaz · Beitrag von **Michael Rignaz** » 26 Okt 2006, 21:05

Hmm.. also fest is die höchstens bei mir. Wenn mein Chef aber per UMTS ins Netz geht oder von irgendeinem Hotel aus, ist das leider nicht mehr der fall

Dead peer detection in der Verbindungsliste steht bei meiner Verbindung zB auf 20Sekunden.. bringt absolut nix, da die Verbindung ja ab und zu für mehr als 5 Minuten tot ist, aber angeblich noch besteht...

Gibts nicht noch eine andere Möglichkeit?

Michael Rignaz · Beitrag von **Michael Rignaz** » 27 Okt 2006, 13:07

Was noch sehr merkwürdig ist, ist wie gesagt die Tatsache dass ich per trace + vpn sehen kann dass weiterhin von meiner IP icmp echo requests am Lancom ankommen und antworten geschickt werden.. während so einer tot-tunnelphase wo bei mir alles out-timed... das passiert wenn ich eine öffentliche ip hab ohne firewall/nat auch!
Kann das irgendein routing/firewall bug oder fehleinstellung sein?Aber wie Fehleinstellung wenns ohne zutun funktioniert und dann urplötzlich für paar minuten wieder nicht und dann wieder?
Das sieht dann so aus:

[VPN-Packet] 2006/10/27 13:19:37,630
received: <meine öffip>-><firma öffip> 112 ESP SPI[55d84b93]

[VPN-Packet] 2006/10/27 13:19:37,640
decrypted: <meine öffip>-><firma öffip> 96 IP-ENCAP

[VPN-Packet] 2006/10/27 13:19:37,640
decap: <meine öffip>->192.168.0.2 60 ICMP ECHOREQUEST

[VPN-Packet] 2006/10/27 13:19:37,640
for send: 192.168.0.2-><meine öffip> 60 ICMP ECHOREPLY

[VPN-Packet] 2006/10/27 13:19:37,640
encap: <firma öffip>-><meine öffip> 80 IP-ENCAP

[VPN-Packet] 2006/10/27 13:19:37,640
encrypted: <firma öffip>-><meine öffip> 112 ESP SPI[53863301]

Das hier ist das trace gleich nach initiieren der VPN Verbindung.. in diesem Fall ist es also schon gleich nach Beginn des Tunnelaufbaus so, dass ich keinerlei Antworten bekomme, wohl aber sieht der Lancom alles und laut ihm steht der Tunnel... 3/5-10 Minuten später bekomm ich dann auch wieder Antworten und das Spiel beginnt von vorn...

backslash · Beitrag von **backslash** » 27 Okt 2006, 14:48

Hi Michael Rignaz

Hmm.. also fest is die höchstens bei mir. Wenn mein Chef aber per UMTS ins Netz geht oder von irgendeinem Hotel aus, ist das leider nicht mehr der fall

Auch dann hat er eine faste IP. Es geht hier nicht um die IP, die der PC im Internet hat, sondern um die, die er im VPN-Netz (also *HINTER* dem Tunnel) hat - und die kannst - bzw. *MUST* (da du ja sonst keine Phase-2 Regeln erstlellen kannst) - du beliebig festlegen. Und diese Adresse ist *IMMER* fest und somit anpingbar.

Gruß
Backslash

Michael Rignaz · Beitrag von **Michael Rignaz** » 27 Okt 2006, 15:15

Hi backslash,
erstmal wieder vielen dank für die so schnelle antwort. kapier nur nicht was du meinst.
eddia schreibt in seiner FAQ zum VPN Tunnel ohne extraclient, dass die vorher definierte ip -im Fall von nicht statischen ips mit Zertifikaten- in den routes und firewall regeln auf 255.255.255.255 zu ändern sind, also defaultroutes einzurichten sind mit sich unterscheidendem routingtag.
Wo kann ich denn da die IP festlegen? Ich bin jetzt wahrscheinlich ein Vollidiot und versteh irgendwas und/oder dich völlig verkehrt, ich kenne nur openvpn.. da entsteht beim tunnelaufbau ja auf beiden Seiten ein extra, virtuelles nic device dessen ips ich festlegen kann. Aber hier wird der tunnel beim Client doch auf ein schon existierendes interface "gebunden", auf dessen ip ich von server site doch keinen Einfluss habe, da sie ja beim Tunnelaufbau weder geändert werden kann noch ich wissen kann welche der herr gerade so hat?Versteh' das jetzt absolut nicht, oder meinst du die serversite?

Naja wie auch immer, Pollinglisten für das Problem wärn ja nur eine Notlösung, wenngleich ich auch froh bin wenns überhaupt mal annehmbar funktioniert und nicht nur für 5-10 Minuten-Stille-5-10 Minuten-Stille-e.c., ich würde sehr gern wissen an was das überhaupt liegen kann. Ich pinge, bekomm keine antwort. Ich connecte via ssh zum lancom und siehe da der empfängt bzw. sendet auch replies.. sehr sehr witzig...

eddia · Beitrag von **eddia** » 27 Okt 2006, 18:04

Hallo Michael,

eddia schreibt in seiner FAQ zum VPN Tunnel ohne extraclient, dass die vorher definierte ip -im Fall von nicht statischen ips mit Zertifikaten- in den routes und firewall regeln auf 255.255.255.255 zu ändern sind,

nein, das steht da nicht. In den Firewall-Regeln darf nur der Routingtag angepasst werden.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 27 Okt 2006, 21:32

Hallo eddia, danke..
Ja, das habe ich so gemacht, -hab mich nicht gut ausgedrückt- in der routing tabelle eine default route mit in meinem fall tag "1" und in der vom wizard erstellten firewallregel, -nur- den tag auch auf "1".

Da auch die lokalen ips dynamisch sind, je nachdem in welchem Netz er sich einbucht, habe ich das dahingehend angewandt.
Das funktioniert ja auch, nur eben alles andere als beständig.
Hab ich dich da falsch verstanden und ich kann der Verbindung irgendeine x beliebige lokale ip geben, unabhängig von den am Client existierenden (die leider dynamisch sein müssen)?
Denke nein, also wie könnte ich in solch einem Scenario eine Pollingliste verwenden, bzw. kann man ungefähr schätzen an was dieses problem liegen kann?Ist doch echt merkwürdig wenn der Lancom die eingehenden echorequests sieht und auch replies verschickt an meine korrekte lokale ip, die dann aber bei mir in bestimmten sich abwechselnden Phasen von etwa 5-10 Minuten nicht ankommen und dann wieder..

Ich probiere das alles jetzt mit einer neu angelegten "Verbindung" für eine statische ip (ein scenario dass ich leider praktisch nicht brauchen kann (nur bei mir, nicht aber beim Cheflaptop.. wenn der in USA, auf den Seychellen oder sonstwo ist und dabei in irgendwelchen Hotels irgendwelche lokalen ips bekommt)), und beobachte mal ob sich an dem Problem was ändert.

eddia · Beitrag von **eddia** » 28 Okt 2006, 15:20

Hallo Michael,

Hab ich dich da falsch verstanden und ich kann der Verbindung irgendeine x beliebige lokale ip geben, unabhängig von den am Client existierenden (die leider dynamisch sein müssen)?

Durch den Eintrag in der Routingtabelle mit 255.255.255.255 0.0.0.0 und Routingtag 1 wird genau das erreicht. Somit ist die IP des Clients an seinem Interface egal.

Bei unterschiedlichen Client-IPs muss aber jedesmal die IPSec-Regel am Client entfernt werden: ipsec -delete

kann man ungefähr schätzen an was dieses problem liegen kann?

Mach mal folgendes:
-am Client: ipsec -delete
-Lancom neu starten
-VPN-Status Trace einschalten
-am Client: ipsec
-ping vom Client auf eine IP im LAN des Lancoms

Den kompletten Trace über ein paar Minuten laufen lassen und posten.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 30 Okt 2006, 07:55

Hallo eddia,

hier das log, bin echt gespannt was da los ist. Diesmal hat es verhältnismäßig lange gedauert (fast 1 Std, manchmal ist aber schon alles nach ein paar Minuten für einige Zeit tot) bis es zum Stillstand kam, das Trace geht bis zu diesem Zeitpunkt. Danke fürs Durchschauen!

Code: Alles auswählen

[VPN-Status] 2006/10/30 06:38:15,630
IKE info: The remote server <meine öffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft
IKE info: The remote server <meine öffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/30 06:38:15,640
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1


[VPN-Status] 2006/10/30 06:38:16,460
IKE info: Phase-1 [responder] for peer <VERBINDUNG> between initiator id CN=<Mein CN>, responder id CN=<1811 CN> done
IKE info: SA ISAKMP for peer <VERBINDUNG> encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2006/10/30 06:38:16,550
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG> matched with local proposal 1


[VPN-Status] 2006/10/30 06:38:16,740
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG> rule ipsec-6-<VERBINDUNG>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.100/255.255.255.255 '
IKE info: SA ESP [0xb6af5d6d]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x41cdc217]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <1811 Lancom öffIP> dst: <meine öffIP>


[VPN-Status] 2006/10/30 06:38:16,750
VPN: wait for IKE negotiation from <VERBINDUNG> (<meine öffIP>)

[VPN-Status] 2006/10/30 06:38:17,760
VPN: <VERBINDUNG> (<meine öffIP>) connected


[VPN-Status] 2006/10/30 06:39:41,870
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG> peer <VERBINDUNG> cookies [8a19e2a0281b2337 9156f8d1497c9522]


[VPN-Status] 2006/10/30 06:39:41,870
IKE info: Phase-1 SA removed: peer <VERBINDUNG> rule <VERBINDUNG> removed


[VPN-Status] 2006/10/30 07:32:31,670
IKE info: Phase-2 SA removed: peer <VERBINDUNG> rule ipsec-6-<VERBINDUNG>-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [b6af5d6d  ] [41cdc217  ]


[VPN-Status] 2006/10/30 07:32:31,670
VPN: <VERBINDUNG> (<meine öffIP>) disconnected

[VPN-Status] 2006/10/30 07:32:31,670
VPN: Disconnect info: remote-disconnected (0x4301) for <VERBINDUNG> (<meine öffIP>)

[VPN-Status] 2006/10/30 07:32:31,690
VPN: selecting first remote gateway using strategy eFirst for <VERBINDUNG>
     => no remote gateway selected

[VPN-Status] 2006/10/30 07:32:31,690
VPN: installing ruleset for <VERBINDUNG> (0.0.0.0)

[VPN-Status] 2006/10/30 07:32:31,720
VPN: rulesets installed

[VPN-Status] 2006/10/30 07:37:06,590
IKE info: The remote server <meine öffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/30 07:37:06,600
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1


[VPN-Status] 2006/10/30 07:37:07,140
IKE info: Phase-1 [responder] for peer <VERBINDUNG> between initiator id CN=<Mein CN>, responder id CN=<1811 CN> done
IKE info: SA ISAKMP for peer <VERBINDUNG> encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2006/10/30 07:37:07,210
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG> matched with local proposal 1


[VPN-Status] 2006/10/30 07:37:07,370
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG> rule ipsec-6-<VERBINDUNG>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.100/255.255.255.255 '
IKE info: SA ESP [0xa178b513]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x04410386]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <1811 Lancom öffIP> dst: <meine öffIP>


[VPN-Status] 2006/10/30 07:37:07,380
VPN: wait for IKE negotiation from <VERBINDUNG> (<meine öffIP>)

[VPN-Status] 2006/10/30 07:37:07,390
IKE log: 073707 Default message_recv: invalid cookie(s) 8a19e2a0281b2337 9156f8d1497c9522


[VPN-Status] 2006/10/30 07:37:07,390
IKE log: 073707 Default dropped message from <meine öffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/30 07:37:07,400
IKE info: dropped message from peer unknown <meine öffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/30 07:37:08,390
VPN: <VERBINDUNG> (<meine öffIP>) connected


[VPN-Status] 2006/10/30 07:38:11,860
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG> peer <VERBINDUNG> cookies [60fb7e6aff7e4599 10bb141ca810063a]


[VPN-Status] 2006/10/30 07:38:11,860
IKE info: Phase-1 SA removed: peer <VERBINDUNG> rule <VERBINDUNG> removed

Michael Rignaz · Beitrag von **Michael Rignaz** » 31 Okt 2006, 12:14

Jetzt unter tags bricht meine VPN Verbindung zum 1811er andauernd ein.. schon zu Beginn nach 2 Minuten für 2-5 Minuten aus, dann gings wieder für 2 Minuten, jetzt wieder aus. Es wurde natürlich nichts an irgendwelchen Konfigurationen geändert. Der einzige unterschied ist jetzt dass eine weitere VPN Verbindung (zu einem andren 1811er, die aber niemals Probleme macht) intensiver genutzt wird als in der Früh, als ich das status trace gemacht habe, klarer Weise.
Hier mal das Status-Trace inklusive der anderen Verbindung.

Hier die Zeit zu den Ausfällen von meinem Client (Zeiten +/- 5sec zum Lancom):

11:48 tot
11:52:08 geht
11:54:00 tot
11:58:08 geht
12:00:02 tot

Verbindung1 = Name meiner "Verbindung"
Verbindung2 = Name der "Verbindung" vom 2. 1811er zum selben (1.) 1811 zu dem Verbindung1 aufbaut.

Code: Alles auswählen


[VPN-Status] 2006/10/31 11:45:43,760
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG2> matched with local proposal 1

[VPN-Status] 2006/10/31 11:45:44,200
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG2> rule ipsec-3-<VERBINDUNG2>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.9.0/255.255.255.0 '
IKE info: SA ESP [0x7b78f350]  alg AES keylength 128 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x2d961283]  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: <1811_1 ÖffIP> dst: <1811_2 ÖffIP>


[VPN-Status] 2006/10/31 11:45:58,220
IKE info: Delete Notification received for Phase-2 SA ipsec-3-<VERBINDUNG2>-pr0-l0-r0 peer <VERBINDUNG2> spi [0x13fb2593]


[VPN-Status] 2006/10/31 11:45:58,220
IKE info: Phase-2 SA removed: peer <VERBINDUNG2> rule ipsec-3-<VERBINDUNG2>-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [13fb2593  ] [01b792a7  ]


[VPN-Status] 2006/10/31 11:46:05,750
IKE log: 114605 Default message_recv: invalid cookie(s) 890c79465db50000 5ef8f4b4a2feaf97


[VPN-Status] 2006/10/31 11:46:05,750
IKE log: 114605 Default dropped message from <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:46:05,750
IKE info: dropped message from peer unknown <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:46:07,800
IKE info: The remote server <meine ÖffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/31 11:46:07,800
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1


[VPN-Status] 2006/10/31 11:46:08,330
IKE info: Phase-1 [responder] for peer <VERBINDUNG1> between initiator id CN=<CN Verbindung1>, responder id CN=<CN 1811_1> done
IKE info: SA ISAKMP for peer <VERBINDUNG1> encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2006/10/31 11:46:08,390
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG1> matched with local proposal 1


[VPN-Status] 2006/10/31 11:46:08,560
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG1> rule ipsec-6-<VERBINDUNG1>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.100/255.255.255.255 '
IKE info: SA ESP [0x49a42225]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x39cc4e3b]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <1811_1 ÖffIP> dst: <meine ÖffIP>


[VPN-Status] 2006/10/31 11:47:20,250
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG1> peer <VERBINDUNG1> cookies [dc0278da2bf3a14c 919c0afa928feaf3]


[VPN-Status] 2006/10/31 11:47:20,250
IKE info: Phase-1 SA removed: peer <VERBINDUNG1> rule <VERBINDUNG1> removed


[VPN-Status] 2006/10/31 11:50:39,260
IKE info: Phase-2 SA removed: peer <VERBINDUNG1> rule ipsec-6-<VERBINDUNG1>-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [c26e6f7b  ] [5f9b9453  ]


[VPN-Status] 2006/10/31 11:52:05,750
IKE log: 115205 Default message_recv: invalid cookie(s) dc0278da2bf3a14c 919c0afa928feaf3


[VPN-Status] 2006/10/31 11:52:05,750
IKE log: 115205 Default dropped message from <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:52:05,750
IKE info: dropped message from peer unknown <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:52:07,800
IKE info: The remote server <meine ÖffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/31 11:52:07,800
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1


[VPN-Status] 2006/10/31 11:52:08,340
IKE info: Phase-1 [responder] for peer <VERBINDUNG1> between initiator id CN=<CN Verbindung1>, responder id CN=<CN 1811_1> done
IKE info: SA ISAKMP for peer <VERBINDUNG1> encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2006/10/31 11:52:08,400
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG1> matched with local proposal 1


[VPN-Status] 2006/10/31 11:52:08,570
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG1> rule ipsec-6-<VERBINDUNG1>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.100/255.255.255.255 '
IKE info: SA ESP [0x82033d17]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x2543fdbf]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <1811_1 ÖffIP> dst: <meine ÖffIP>


[VPN-Status] 2006/10/31 11:53:20,290
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG1> peer <VERBINDUNG1> cookies [d7f35c70ff4a75ff aebcba95b17221fb]


[VPN-Status] 2006/10/31 11:53:20,300
IKE info: Phase-1 SA removed: peer <VERBINDUNG1> rule <VERBINDUNG1> removed


[VPN-Status] 2006/10/31 11:58:05,740
IKE log: 115805 Default message_recv: invalid cookie(s) d7f35c70ff4a75ff aebcba95b17221fb


[VPN-Status] 2006/10/31 11:58:05,750
IKE log: 115805 Default dropped message from <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:58:05,750
IKE info: dropped message from peer unknown <meine ÖffIP> port 500 due to notification type INVALID_COOKIE


[VPN-Status] 2006/10/31 11:58:07,800
IKE info: The remote server <meine ÖffIP>:500 peer def-main-peer id <no_id> supports NAT-T in mode draft


[VPN-Status] 2006/10/31 11:58:07,800
IKE info: Phase-1 remote proposal 1 for peer def-main-peer matched with local proposal 1


[VPN-Status] 2006/10/31 11:58:08,330
IKE info: Phase-1 [responder] for peer <VERBINDUNG1> between initiator id CN=<CN Verbindung1>, responder id CN=<CN 1811_1> done
IKE info: SA ISAKMP for peer <VERBINDUNG1> encryption 3des-cbc authentication sha1
IKE info: life time ( 28800 sec/ 0 kb)


[VPN-Status] 2006/10/31 11:58:08,390
IKE info: Phase-2 remote proposal 1 for peer <VERBINDUNG1> matched with local proposal 1


[VPN-Status] 2006/10/31 11:58:08,560
IKE info: Phase-2 [responder] done with 2 SAS for peer <VERBINDUNG1> rule ipsec-6-<VERBINDUNG1>-pr0-l0-r0
IKE info: rule:' ipsec 192.168.0.0/255.255.255.0 <-> 192.168.1.100/255.255.255.255 '
IKE info: SA ESP [0x955e9c9f]  alg 3DES keylength 192 +hmac HMAC_MD5 outgoing
IKE info: SA ESP [0x10bbad43]  alg 3DES keylength 192 +hmac HMAC_MD5 incoming
IKE info: life soft( 3240 sec/45000 kb) hard (3600 sec/50000 kb)
IKE info: tunnel between src: <1811_1 ÖffIP> dst: <meine ÖffIP>


[VPN-Status] 2006/10/31 11:58:39,570
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-6-<VERBINDUNG1>-pr0-l0-r0 to peer <VERBINDUNG1>, spi [0x69ee486f]


[VPN-Status] 2006/10/31 11:58:39,570
IKE info: Phase-2 SA removed: peer <VERBINDUNG1> rule ipsec-6-<VERBINDUNG1>-pr0-l0-r0 removed
IKE info: containing Protocol IPSEC_ESP, with spis [c7e6f128  ] [69ee486f  ]


[VPN-Status] 2006/10/31 11:59:20,340
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG1> peer <VERBINDUNG1> cookies [9c2b48ed65acbc86 9614b2f8524e2ce0]


[VPN-Status] 2006/10/31 11:59:20,340
IKE info: Phase-1 SA removed: peer <VERBINDUNG1> rule <VERBINDUNG1> removed

Wenig später nach "IKE info: Delete Notificaton sent for Phase-2 SA " isses dann bei mir tot, aber niemals zeitgleich.. kann durchaus eine Minute dauern.
"IKE info: Delete Notification received for Phase-2 SA " kommt jedoch auch für Verbindung2, die aber nie merkbar down war.

Lg,
Michael

eddia · Beitrag von **eddia** » 31 Okt 2006, 13:05

Hallo Michael,

Diesmal hat es verhältnismäßig lange gedauert (fast 1 Std, manchmal ist aber schon alles nach ein paar Minuten für einige Zeit tot) bis es zum Stillstand kam, das Trace geht bis zu diesem Zeitpunkt.

ich hab das Problem jetzt nachvollziehen können.

[VPN-Status] 2006/10/30 06:39:41,870
IKE info: Delete Notification received for Phase-1 SA isakmp-peer-<VERBINDUNG> peer <VERBINDUNG> cookies [8a19e2a0281b2337 9156f8d1497c9522]

Das kommt bei mir auch (zwischen 20s - bis 80s nach Verbindungsbeginn). Hier schickt Windows offenbar zum Lancom die Aufforderung die SA zu löschen. Im oakley-log des Windows-Clients sieht man zeitgleich:

Code: Alles auswählen

10-31: 11:36:57:556:20c CE Dead. sa:000FB5E0 ce:000D9088 status:35ef
10-31: 11:37:16:239:20c SA Dead. sa:000FB5E0 status:35f0
10-31: 11:37:16:239:20c isadb_set_status sa:000FB5E0 centry:00000000 status 35f0
10-31: 11:37:16:239:20c constructing ISAKMP Header
10-31: 11:37:16:239:20c constructing HASH (null)
10-31: 11:37:16:239:20c constructing DELETE. MM 000FB5E0
10-31: 11:37:16:239:20c constructing HASH (Notify/Delete)
10-31: 11:37:16:239:20c Not setting retransmit to downlevel client. SA 000FB5E0 Centry 00000000
10-31: 11:37:16:239:20c 
10-31: 11:37:16:239:20c Sending: SA = 0x000FB5E0 to xxx.xxx.xxx.xxx:Type 1.500
10-31: 11:37:16:239:20c ISAKMP Header: (V1.0), len = 76
10-31: 11:37:16:239:20c   I-COOKIE 1493d1d20e36d7d1
10-31: 11:37:16:239:20c   R-COOKIE be8f1c89c2b06ead
10-31: 11:37:16:239:20c   exchange: ISAKMP Informational Exchange
10-31: 11:37:16:239:20c   flags: 1 ( encrypted )
10-31: 11:37:16:239:20c   next payload: HASH
10-31: 11:37:16:239:20c   message ID: 69d86c85
10-31: 11:37:16:239:20c Ports S:f401 D:f401

Der einzige unterschied ist jetzt dass eine weitere VPN Verbindung (zu einem andren 1811er, die aber niemals Probleme macht) intensiver genutzt wird als in der Früh, als ich das status trace gemacht habe, klarer Weise.

Könnte durchaus daran liegen. Das pure IPSec von Windows scheint wohl nicht für die grossen Latenzzeiten im WAN geeignet.

[VPN-Status] 2006/10/31 11:58:39,570
IKE info: Delete Notificaton sent for Phase-2 SA ipsec-6-<VERBINDUNG1>-pr0-l0-r0 to peer <VERBINDUNG1>, spi [0x69ee486f]

Hat bei mir mehr als eine Stunde gedauert, bis das auftrat. Leider gibt es beim Windows-Client keinen Eintrag im log, dass er dies empfangen hätte.

Tja - da bin ich überfragt.

Gruß

Mario

Michael Rignaz · Beitrag von **Michael Rignaz** » 31 Okt 2006, 13:30

Danke eddia für deine bemühungen!
wenn niemand anders rat weiss, dann könntest du mir vielleicht eine andere (freeware für win32) lösung empfehlen?

eddia · Beitrag von **eddia** » 01 Nov 2006, 17:53

Hallo Michael,

dann könntest du mir vielleicht eine andere (freeware für win32) lösung empfehlen?

die einzige 'Freeware', die ich kenne, ist der alte Lancom VPN-Client. Lungert auf älteren CDs rum oder sollte auf Anfrage beim Support erhältlich sein. Gibt aber wohl ein paar Probleme mit XP SP2, die in der KB von Lancom beschrieben sind.

Gruß

Mario

Beitrag von **LoUiS** » 01 Nov 2006, 19:13

Hi,

ich habe gerade den Freeware VPN Client von Shrew http://www.shrew.net/ gefunden, aber noch nicht selbst getestet, aber die Daten der 1.1.0 stable Version sehen recht vielversprechend aus. Waere doch einen Versuch wert.

Ciao
LoUiS