CISCO VPN Client

[hegl 10]

Router habe ich schon mal getauscht - negativ!

Ein anderer Kollege berichtet über die gleiche Problematik; anderer Provider und 6 MBit-DSL-Anschluss an einer anderen HW.

[Wordo 11]

Na dann sollte es doch an der PIX liegen. Ein Update magste nicht mal machen?

[hegl 10]

Ein update würde ich allenfalls auf 6.3.5 machen.

 

Aber wieso tippst Du auf die PIX, wenn es doch grundsätzlich läuft?

[hegl 10]

Könnte es was damit zu tun haben?

 

CSCee11278: Change DPD algo to be less aggressive in detecting short

 

Ab 6.3.4 soll dies geändert worden sein..

[hegl 10]

Bin schon wieder am testen - ist halt der Vorteil, wenn man(n) krank zu Hause ist und Langeweile hat ;)

Habe mal versucht das log zu verstehen - nach einwandfreiem Aufbau gibts immer ein folgendes Szenario:

 

1 07:27:49.147 12/05/06 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 222.111.222.111

 

2 07:27:49.147 12/05/06 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 222.111.222.111, our seq# = 1091218983

 

3 07:27:49.207 12/05/06 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 222.111.222.111

 

4 07:27:49.207 12/05/06 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK INFO *(HASH, NOTIFY: DPD_ACK) from 222.111.222.111

 

5 07:27:49.207 12/05/06 Sev=Info/5 IKE/0x63000040

Received DPD ACK from 222.111.222.111, seq# received = 1091218983, seq# expected = 1091218983

 

Irgendwann kommt vom VPN-Peer keine Antwort mehr:

 

227 08:13:52.000 12/05/06 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 213.168.100.252

 

228 08:13:52.000 12/05/06 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 213.168.100.252, our seq# = 1091219028

 

229 08:13:57.007 12/05/06 Sev=Info/4 IKE/0x63000013

SENDING >>> ISAKMP OAK INFO *(HASH, NOTIFY: DPD_REQUEST) to 213.168.100.252

 

230 08:13:57.007 12/05/06 Sev=Info/6 IKE/0x6300003D

Sending DPD request to 213.168.100.252, our seq# = 1091219029

 

Dann erfolgt eine Re-Initialisierung, XAuth-Fenster poppt auf und ich werde aufgefordert die Anmeldedaten einzugeben.

 

278 08:15:14.919 12/05/06 Sev=Info/5 IKE/0x63000047

This SA has already been alive for 0 seconds, setting expiry to 3600 seconds from now

 

279 08:15:14.919 12/05/06 Sev=Info/5 IKE/0x6300002F

Received ISAKMP packet: peer = 213.168.100.252

 

280 08:15:14.919 12/05/06 Sev=Info/4 IKE/0x63000014

RECEIVING <<< ISAKMP OAK TRANS *(HASH, ATTR) from 213.168.100.252

 

281 08:15:14.919 12/05/06 Sev=Info/4 CM/0x63100015

Launch xAuth application

 

Da ich diese aber nicht so schnell eingeben kann, wird die Verbindung getrennt!

Die Frage ist aber weiterhin: Wieso antwortet die PIX nicht mehr auf den DPD_Request?

 

Ich habe jetzt einmal XAuth deaktiviert - schaun wir mal, was jetzt passiert...

[hegl 10]

Wie zu erwarten war, hat es nichts mit XAuth zu tun - abbruch nach 9 min. und in der firma läuft´s und läuft´s und...

Soll ich jetzt oder :)

 

@Schusterharry: von dir hört man gar nichts mehr; hast du nichts neues?

[Wordo 11]

Du kannst auf der PIX auch DPD mal ausschalten. Wenn es von mehreren "Standorten" mit diversen Routern Probleme gibt wuerd ich halt auf die PIX tippen. Oder du klemmst den Rechner direkt ans DSL. Dann gibts kein NAT-T etc.

[hegl 10]

Du kannst auf der PIX auch DPD mal ausschalten.

 

Und wie geht das ? Finde bei CISCO nichts! :mad:

[Wordo 11]

Aeh ... PIX ist nicht meine Staerke. Irgendwo bei dem VPN Zeugs muss das "keepalive" weg. Wahrscheinlich so ne Zeile wie "isakmp keepalive". Aber bitte nur zum Testen!!!

[hegl 10]

Habe explizit nichts konfiguriert, CISCO sagt dazu:

 

The keepalive interval can be between 10 and 3600 seconds. The retry interval can

be between 2 and 10 seconds, with the default being 2 seconds. The retry interval

is the interval between retries after a keepalive response has not been received.

You can specify the keepalive interval without specifying the retry interval, but

cannot specify the retry interval without specifying the keepalive interval.

 

Da im log von heute morgen nach dem ersten nicht beantworteten DPD_Request 1 min und 22 sec vergehen, bevor die Re-Initialisierung startet, und dazwischen der Client alles 5 sec einen neuen DPD_Request schickt, dürfte dies auch nichts bringen.

Aber probieren geht über studieren...

 

Und bis hierhin schon mal recht herzlichen Dank für deine Unterstützung!

[hegl 10]

Verbindung ohne Router, also direkt mit PPPoE, bricht genauso aus unerklärlichen Gründen ab. Selbst wenn ich die CISCO-Vorgaben, d.h. beim VPN-Client die MTU auf 576 und bei der Netzwerkkarte auf 1300 reduziere ändert sich nichts :mad: :mad: :mad:

 

Nur so nebenbei: Eine T-DSL Verbindung klappt dagegen hervorragend, auch mit Router :rolleyes:

[ColdyBln 10]

Hallo Ihr Beiden,

 

exakt das gleiche Problem (bis auf die Zeiten, die ich nicht gemessen habe) habe ich auch. Dabei ebefalls unabhaengig, ob Client hinter NAT oder direkt haengt. Hab's aus verschiedenen Netzen auch versucht, keine Anderung.

Konntet Ihr den eine Loesung finden? Hat das Update auf 6.xx irgendwas gebracht?

 

Gruss ...

[hegl 10]

Hallo Ihr Beiden,

 

...

Konntet Ihr den eine Loesung finden? ...

 

Gruss ...

 

 

Des Rätsels Lösung heisst nat-traversal!

isakmp nat-traversal 20 (20 = default)

 

Damit nutzt der Client udp/4500 der natürlich auch freigeschaltet sein muss!

 

Sag´ Bescheid, ob´s funktioniert!

[ColdyBln 10]

Hi hegl,

 

hoffe, Du hast den Karneval gut ueberstanden. Werde das versuchen und gebe auch INFO.

 

Gruss