From: chon_mon@nym.hush.com
Date: Mon Jun 20 2005 - 23:36:17 GMT-3
Thanks for your support! Version 6.6 was the version of the Sonic.
I finally resolved the issue with regards to the tunnel - and your
stab was absolutely correct. I used the names command: name
1.1.1.1 xmas.new.com and that was all it took! It was trying to
resolve to a "ID_FQDN" and thus Phase 1 was failing.
Thanks!
-Sean
On Mon, 20 Jun 2005 18:51:15 -0700 Scott Morris <swm@emanon.com>
wrote:
>By the way... What is version 6.6??? That's not your PIX
>software. :)
>
>-----Original Message-----
>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>Behalf Of
>chon_mon@nym.hush.com
>Sent: Monday, June 20, 2005 8:59 PM
>To: swm@emanon.com
>Cc: ccielab@groupstudy.com; security@groupstudy.com
>Subject: RE: VPN timeout issues
>
>I am running version 6.6. I got passed the timeout errors, and
>NAT-
>
>traversal errors on the Sonicwall. Now on the pix, when I ping
>from a host
>on the 192.168.2.0 network to a host on the 192.168.10.0 network
>the
>following is my debug from the PIX:
>
>scenario for site-to-site VPN
>192.168.2.0<---->PIX<----------->SONIC<-------->192.168.10.0
>
>pixconfig i
>sysopt connection permit-ipsec
>crypto ipsec transform-set halo esp-3des crypto map test 10 ipsec-
>isakmp
>crypto map test 10 match address NONAT crypto map test 10 set pfs
>group2
>crypto map test 10 set peer 210.4.56.9 crypto map test 10 set
>transform-set
>halo crypto map test interface outside isakmp enable outside
>isakmp key test
>address 210.4.56.9 netmask 255.255.255.192 no-xauth
>
>no-config-mode
>isakmp policy 10 authentication pre-share isakmp policy 10
>encryption 3des
>isakmp policy 10 hash md5 isakmp policy 10 group 1 isakmp policy
>10 lifetime
>28800
>
>Any help you can provide, I would be grateful! TIA - Sean
>
>PIX(config)# sh debug
>debug crypto ipsec 1
>debug crypto isakmp 1
>PIX(config)#
>ISAKMP (0): beginning Main Mode exchange
>crypto_isakmp_process_block:src:210.4.56.9, dest:21.19.178.2
>spt:500 dpt:500
>OAK_MM exchange ISAKMP (0): processing SA payload. message ID = 0
>
>ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
>ISAKMP: encryption 3DES-CBC
>ISAKMP: hash MD5
>ISAKMP: default group 1
>ISAKMP: auth pre-share
>ISAKMP: life type in seconds
>ISAKMP: life duration (basic) of 28800
>ISAKMP (0): atts are acceptable. Next payload is 0 ISAKMP (0): SA
>is doing
>pre-shared key authentication using id type
>
>ID_FQDN
>return status is IKMP_NO_ERROR
>crypto_isakmp_process_block:src:210.4.56.9, dest:21.19.178.2
>spt:500 dpt:500
>OAK_MM exchange ISAKMP (0): processing KE payload. message ID = 0
>
>ISAKMP (0): processing NONCE payload. message ID = 0
>
>ISAKMP (0): processing vendor id payload
>
>ISAKMP (0): processing vendor id payload
>
>ISAKMP (0): processing vendor id payload
>
>ISAKMP (0): received xauth v6 vendor id
>
>ISAKMP (0): ID payload
> next-payload : 8
> type : 2
> protocol : 17
> port : 500
> length : 24
>ISAKMP (0): Total payload length: 28
>return status is IKMP_NO_ERROR
>crypto_isakmp_process_block:src:210.4.56.9, dest:21.19.178.2
>spt:500 dpt:500
>ISAKMP (0): processing NOTIFY payload 18 protocol 1
> spi 0, message ID = 2111508800
>ISAKMP (0): dropping NOTIFY on unauthenticated SA.
>return status is IKMP_NO_ERR_NO_TRANS
>ISAKMP (0): retransmitting phase 1 (1)...
>crypto_isakmp_process_block:src:208.253.241.130, dest:21.19.178.2
>spt:500
>dpt:500
>ISAKMP: error, msg not encryptedIPSEC(key_engine): request timer
>fired: count = 1,
> (identity) local= 21.19.178.2, remote= 210.4.56.9,
> local_proxy= 192.168.2.0/255.255.255.0/0/0 (type=4),
> remote_proxy= 192.168.10.0/255.255.255.0/0/0 (type=4)
>
>ISAKMP (0): retransmitting phase 1 (2)...
>crypto_isakmp_process_block:src:210.4.56.9, dest:21.19.178.2
>spt:500 dpt:500
>ISAKMP: error, msg not encrypted
>ISADB: reaper checking SA 0x582bf84, conn_id = 0 ISAKMP (0):
>deleting SA:
>src 21.19.178.2, dst 210.4.56.9
>ISADB: reaper checking SA 0x582bf84, conn_id = 0 DELETE IT!
>
>VPN Peer:ISAKMP: Peer Info for 210.4.56.9/500 not found - peers:0
>und all
>PIX(config)#
>
>
>On Mon, 20 Jun 2005 17:13:04 -0700 Scott Morris <swm@emanon.com>
>wrote:
>>Keepalives are good only after your IKE SA is set up! Lifetimes
>are
>>good for the negotiation, but do all your other IKE parameters
>match?
>>
>>I don't play with Sonicwall stuff, so I have no idea what to tell
>you
>>to look for on there. But the things that you configure in your
>isakmp
>>policy on the PIX should help you determine what things need to
>match
>>on the other end!
>>
>>Do debugs on the PIX tell you anything?
>>
>>Scott
>>
>>-----Original Message-----
>>From: nobody@groupstudy.com [mailto:nobody@groupstudy.com] On
>Behalf Of
>>chon_mon@nym.hush.com
>>Sent: Monday, June 20, 2005 5:43 PM
>>To: ccielab@groupstudy.com; security@groupstudy.com
>>Subject: VPN timeout issues
>>
>>Dear Group,
>>
>>I have configured a site-to-site VPN between a PIX and a Sonic
>FW.
>
>>
>>When the PIX initiates the connection, the Sonic at the remote
>site
>>accepts the phase 1 request, but then times out. The Sonic
>>states
>>that the "IKE responder: remote party timeout" - and then
>nothing!
>
>>
>>I have both my isakmp keepalives and lifetimes matching for both
>sides
>>of the VPN. Can anyone shed some light on this? TIA - Sean
>>
>>__________________________________________________________________
>_
>
>>____
>>Subscription information may be found at:
>>http://www.groupstudy.com/list/CCIELab.html
>
>___________________________________________________________________
>____
>Subscription information may be found at:
>http://www.groupstudy.com/list/CCIELab.html
This archive was generated by hypermail 2.1.4 : Wed Jul 06 2005 - 14:43:42 GMT-3