Cisco PIX 7.0.1 to Watchguard V60 VPN Tunnel

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

I am upgrading all my compaines firewalls with the new 7.0 on
all our pixes. We have one enviroment with a Watchguard V60. With
version
6.3.4 of the pix software, I have successfully created a VPN tunnel
from the
v60 to the pix many times in the past. Now that my test PIX has been
upgraded to 7.0, I have been unable to do so and it is a major hold up
to my project...but what isn't a hold up right? See partial packet
dump below... Keeps saying PAYLOAD_MALFORMED where i have it marked
with <<<<<<<<<. Nothing of the configs has changed....in fact..Phase I
negotiates properly...when used to try and negotiate Phase II...the
watchgaurd sends the all delete SA message...

I have logs, configs, all available....Anyone have a similar
problem...maybe with a VPN concentrator 3000? I hear they took the
code from the 3000 and used it in the new pix 7.0...any ideas?

ISAKMP Header
Initiator COOKIE: 5f f9 10 cc c4 c7 92 5a
Responder COOKIE: 6b 03 45 83 42 a9 fb 9f
Next Payload: Hash
Version: 1.0
Exchange Type: Informational
Flags: (Encryption)
MessageID: F718DDC0
Length: 68
Payload Hash
Next Payload: Notification
Reserved: 00
Payload Length: 24
Data:
0c c2 e2 c0 da a3 f8 63 10 f5 cc 15 19 9e d4 71
1c 49 d2 9f
Payload Notification
Next Payload: None
Reserved: 00
Payload Length: 16
DOI: IPsec
Protocol-ID: PROTO_IPSEC_ESP
Spi Size: 4
Notify Type: PAYLOAD_MALFORMED <<<<<<<<<<<<<<<<<<<<<<<<<<<
SPI: 7c 8a 79 bc
Sep 15 12:48:17 [IKEv1]: IP = 12.156.2.254, IKE DECODE RECEIVED Message
(msgid=f718ddc0) with payloads : HDR + HASH (8) + NOTIFY (11) + NONE
(0) total length : 68
Sep 15 12:48:17 [IKEv1 DEBUG]: Group = 12.156.2.254, IP = 12.156.2.254,
processing hash
Sep 15 12:48:17 [IKEv1 DEBUG]: Group = 12.156.2.254, IP = 12.156.2.254,
Processing Notify payload

ISAKMP Header
Initiator COOKIE: 5f f9 10 cc c4 c7 92 5a
Responder COOKIE: 6b 03 45 83 42 a9 fb 9f
Next Payload: Hash
Version: 1.0
Exchange Type: Quick Mode
Flags: (Encryption)
MessageID: 185D0F10
Length: 196

IKE Recv RAW packet dump
5f f9 10 cc c4 c7 92 5a 6b 03 45 83 42 a9 fb 9f | _......Zk.E.B...
08 10 05 01 dc 8c 07 d2 00 00 00 44 a0 eb 70 64 | ...........D..pd
d8 0f 66 b7 70 31 62 a8 95 dc 1d 91 09 65 05 39 | ..f.p1b......e.9
c4 f8 b8 29 76 04 42 f1 28 0f f4 b8 24 05 a8 e9 | ...)v.B.(...$...
7f dd 3d 95 | .=.

RECV PACKET from 12.156.2.254
ISAKMP Header
Initiator COOKIE: 5f f9 10 cc c4 c7 92 5a
Responder COOKIE: 6b 03 45 83 42 a9 fb 9f
Next Payload: Hash
Version: 1.0
Exchange Type: Informational
Flags: (Encryption)
MessageID: DC8C07D2
Length: 68

AFTER DECRYPTION
ISAKMP Header
Initiator COOKIE: 5f f9 10 cc c4 c7 92 5a
Responder COOKIE: 6b 03 45 83 42 a9 fb 9f
Next Payload: Hash
Version: 1.0
Exchange Type: Informational
Flags: (Encryption)
MessageID: DC8C07D2
Length: 68
Payload Hash
Next Payload: Notification
Reserved: 00
Payload Length: 24
Data:
4a b8 b4 22 6e d6 13 06 0b 78 f2 38 fc 5a 61 a3
56 07 e7 6d
Payload Notification
Next Payload: None
Payload Length: 16
Reserved: 00
DOI: IPsec
Protocol-ID: PROTO_IPSEC_ESP
Spi Size: 4
Notify Type: PAYLOAD_MALFORMED <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

 

[Guest]

Archived from groups: comp.dcom.vpn (More info?)

try:

3des/sha1 for phase 1 and phase 2
DH Group 2
make sure the watchGuard uses the same
make sure no Perfect Forward Secrecy

From the PIX, give us the outpouts of

debug crypto isak
debug crypto ipsec
sh crypto isak sa det

/edgar