Ipsec - Site2Site Problem

10/03/2008 - 15:40 von Markus Dotzel | Report spam
Hallo,

habe ein Verbindungsproblem mit einen VPN-Tunnel zwischen dem ISA-2004
Server und einer Firewall Sonicwall. Site2site - Tunnel

Interessant ist dass der Tunnel mehrere Stunden problemlos làuft und dann
abbricht und sich nicht mehr aufbauen làßt. Bootet man den ISA-Server ist die
wahrscheinlichkeit wesentlich größer, dass ich die Verbindung wieder
herstellen làßt.

Der Hauptmodus (Phase I) kann immer erfolgreich aufgebaut werden.
Probleme bekommt der Tunnel dann immer in der 2. Phase. (Schnellmodus)

Im Ereignisprotokoll bekomme ich beim Verbindungsaufbau immer folgenden
Eintrag:
EreignisID 547

IKE-Sicherheitszuordnung konnte nicht ausgehandelt werden.
Modus:
Datenschutzmodus (Schnellmodus)

Filter:
Quell-IP-Adresse 172.16.0.0
Quell-IP-Adressmaske 255.255.0.0
Ziel-IP-Adresse 10.10.125.0
Ziel-IP-Adressmaske 255.255.255.0
Protokoll 0
Quellport 0
Zielport 0
Lokale IKE-Adresse 82.212.250.2
Peer-IKE-Adresse 217.6.108.182
IKE-Quellport 500
IKE-Zielport 500
Private Peeradresse

Peeridentitàt:
Kennung des vorinstallierten Schlüssels.
Peer-IP-Adresse: 217.6.108.182

Fehlerpunkt:
Benutzer

Fehlerursache:
Verhandlung hat Zeitlimit überschritten.

Zusàtzlicher Status:
Als drittes verarbeitete Nutzlast (ID)
Initiator (intern). Wartezeit 67
0x0 0x0

Im oakley.log protokolliert er auch immer mit

3-10: 12:04:09:562:acc AUTH: Phase I authentication accepted


3-10: 12:04:09:718:acc exchange: Oakley Main Mode
3-10: 12:04:09:718:acc flags: 1 ( encrypted )
3-10: 12:04:09:718:acc next payload: ID
3-10: 12:04:09:718:acc message ID: 00000000
3-10: 12:04:09:718:acc invalid payload received
3-10: 12:04:09:718:acc GetPacket failed 3613


3-10: 12:04:09:921:acc processing payload NOTIFY
3-10: 12:04:09:921:acc Invalid DOI in notify message: 0
3-10: 12:04:09:921:acc ProcessFailure
...
3-10: 12:04:41:62:574 Sending: SA = 0x0163DB90 to 217.6.108.182:Type 2.500
3-10: 12:04:41:62:574 ISAKMP Header: (V1.0), len = 300
3-10: 12:04:41:62:574 I-COOKIE 6cced1aafc8b6cac
3-10: 12:04:41:62:574 R-COOKIE ea68835a4ab6b6ed
3-10: 12:04:41:62:574 exchange: Oakley Quick Mode
3-10: 12:04:41:62:574 flags: 1 ( encrypted )
3-10: 12:04:41:62:574 next payload: HASH
3-10: 12:04:41:62:574 message ID: 083fc445
3-10: 12:04:41:62:574 Ports S:f401 D:f401
3-10: 12:04:41:62:574 WSASendTo error 10065
3-10: 12:05:13:62:574 retransmit exhausted: sa = 0163DB90 centry 016AF3F8,
count = 6
3-10: 12:05:13:62:574 Datenschutzmodus (Schnellmodus)
3-10: 12:05:13:62:574 Quell-IP-Adresse 172.16.0.0 Quell-IP-Adressmaske
255.255.0.0 Ziel-IP-Adresse 10.10.125.0 Ziel-IP-Adressmaske 255.255.255.0
Protokoll 0 Quellport 0 Zielport 0 Lokale IKE-Adresse 82.212.250.2
Peer-IKE-Adresse 217.6.108.182 IKE-Quellport 500 IKE-Zielport 500 Private
Peeradresse
3-10: 12:05:13:62:574 Kennung des vorinstallierten Schlssels.
Peer-IP-Adresse: 217.6.108.182
3-10: 12:05:13:62:574 Benutzer
3-10: 12:05:13:62:574 Verhandlung hat Zeitlimit berschritten.
3-10: 12:05:13:62:574 Als drittes verarbeitete Nutzlast (ID) Initiator
(intern). Wartezeit 70 0x0 0x0
3-10: 12:05:13:62:574 isadb_set_status sa:0163DB90 centry:016AF3F8 status
35ed
...

usw

Im Ipsec - Monitor sieht man auch immer, dass der Hauptmodus aufgebaut ist.
Der Schnellmodus kommt aber nur hin und wieder zu stande.

Hat jemand eine Idee, wo man hier das suchen anfangen sollte?
Habe schon fleißig im Internet gesucht, bin aber nicht so richtig fündig
geworden.
 

Lesen sie die antworten

#1 Christian Gröbner [MVP]
10/03/2008 - 21:57 | Warnen spam
Hallo Markus,

hast du die Werte der Phase II auf beiden Seiten überprüft. Ich gehe mal
davon aus, dass hier wohl irgendwo ein unterschied sein muss.

Lese dir hirzu mal den Punkt "Erwartetes IKE-Verhalten" von
http://www.microsoft.com/germany/te...00347.mspx
durch, vielleicht hilft dir das schon weiter.

Gruß

Christian

"Markus Dotzel" schrieb im
Newsbeitrag news:
Hallo,

habe ein Verbindungsproblem mit einen VPN-Tunnel zwischen dem ISA-2004
Server und einer Firewall Sonicwall. Site2site - Tunnel

Interessant ist dass der Tunnel mehrere Stunden problemlos làuft und dann
abbricht und sich nicht mehr aufbauen làßt. Bootet man den ISA-Server ist
die
wahrscheinlichkeit wesentlich größer, dass ich die Verbindung wieder
herstellen làßt.

Der Hauptmodus (Phase I) kann immer erfolgreich aufgebaut werden.
Probleme bekommt der Tunnel dann immer in der 2. Phase. (Schnellmodus)

Im Ereignisprotokoll bekomme ich beim Verbindungsaufbau immer folgenden
Eintrag:
EreignisID 547

IKE-Sicherheitszuordnung konnte nicht ausgehandelt werden.
Modus:
Datenschutzmodus (Schnellmodus)

Filter:
Quell-IP-Adresse 172.16.0.0
Quell-IP-Adressmaske 255.255.0.0
Ziel-IP-Adresse 10.10.125.0
Ziel-IP-Adressmaske 255.255.255.0
Protokoll 0
Quellport 0
Zielport 0
Lokale IKE-Adresse 82.212.250.2
Peer-IKE-Adresse 217.6.108.182
IKE-Quellport 500
IKE-Zielport 500
Private Peeradresse

Peeridentitàt:
Kennung des vorinstallierten Schlüssels.
Peer-IP-Adresse: 217.6.108.182

Fehlerpunkt:
Benutzer

Fehlerursache:
Verhandlung hat Zeitlimit überschritten.

Zusàtzlicher Status:
Als drittes verarbeitete Nutzlast (ID)
Initiator (intern). Wartezeit 67
0x0 0x0

Im oakley.log protokolliert er auch immer mit

3-10: 12:04:09:562:acc AUTH: Phase I authentication accepted


3-10: 12:04:09:718:acc exchange: Oakley Main Mode
3-10: 12:04:09:718:acc flags: 1 ( encrypted )
3-10: 12:04:09:718:acc next payload: ID
3-10: 12:04:09:718:acc message ID: 00000000
3-10: 12:04:09:718:acc invalid payload received
3-10: 12:04:09:718:acc GetPacket failed 3613


3-10: 12:04:09:921:acc processing payload NOTIFY
3-10: 12:04:09:921:acc Invalid DOI in notify message: 0
3-10: 12:04:09:921:acc ProcessFailure
...
3-10: 12:04:41:62:574 Sending: SA = 0x0163DB90 to 217.6.108.182:Type 2.500
3-10: 12:04:41:62:574 ISAKMP Header: (V1.0), len = 300
3-10: 12:04:41:62:574 I-COOKIE 6cced1aafc8b6cac
3-10: 12:04:41:62:574 R-COOKIE ea68835a4ab6b6ed
3-10: 12:04:41:62:574 exchange: Oakley Quick Mode
3-10: 12:04:41:62:574 flags: 1 ( encrypted )
3-10: 12:04:41:62:574 next payload: HASH
3-10: 12:04:41:62:574 message ID: 083fc445
3-10: 12:04:41:62:574 Ports S:f401 D:f401
3-10: 12:04:41:62:574 WSASendTo error 10065
3-10: 12:05:13:62:574 retransmit exhausted: sa = 0163DB90 centry 016AF3F8,
count = 6
3-10: 12:05:13:62:574 Datenschutzmodus (Schnellmodus)
3-10: 12:05:13:62:574 Quell-IP-Adresse 172.16.0.0 Quell-IP-Adressmaske
255.255.0.0 Ziel-IP-Adresse 10.10.125.0 Ziel-IP-Adressmaske
255.255.255.0
Protokoll 0 Quellport 0 Zielport 0 Lokale IKE-Adresse 82.212.250.2
Peer-IKE-Adresse 217.6.108.182 IKE-Quellport 500 IKE-Zielport 500
Private
Peeradresse
3-10: 12:05:13:62:574 Kennung des vorinstallierten Schlssels.
Peer-IP-Adresse: 217.6.108.182
3-10: 12:05:13:62:574 Benutzer
3-10: 12:05:13:62:574 Verhandlung hat Zeitlimit berschritten.
3-10: 12:05:13:62:574 Als drittes verarbeitete Nutzlast (ID) Initiator
(intern). Wartezeit 70 0x0 0x0
3-10: 12:05:13:62:574 isadb_set_status sa:0163DB90 centry:016AF3F8 status
35ed
...

usw

Im Ipsec - Monitor sieht man auch immer, dass der Hauptmodus aufgebaut
ist.
Der Schnellmodus kommt aber nur hin und wieder zu stande.

Hat jemand eine Idee, wo man hier das suchen anfangen sollte?
Habe schon fleißig im Internet gesucht, bin aber nicht so richtig fündig
geworden.






Ähnliche fragen