[c-nsp] sonicwall / PIX VPN woes

Adam Greene maillist at webjogger.net
Sat May 3 09:39:19 EDT 2008


Just wanted to post resolution on this issue. Thanks for the replies I 
received off-list, which suggested making sure PFS was off, and enabling 
nat-traversal if necessary.

The issue turned out to be that the following lines were present in the 
crypto map configuration:

crypto map mapname client configuration address initiate
crypto map mapname client configuration address respond


but the corresponding "no-config-mode" argument was not appended to the 
"isakmp key" command for the VPN:

isakmp key xxxxxxxxxxxx address z.z.z.z netmask 255.255.255.255 
no-config-mode


Live and learn ...

Thanks,
Adam

----- Original Message ----- 
From: "Adam Greene" <maillist at webjogger.net>
To: <cisco-nsp at puck.nether.net>
Sent: Wednesday, April 30, 2008 4:09 PM
Subject: Re: [c-nsp] sonicwall / PIX VPN woes


> Hmmm .... packet capture on Sonicwall reports that some of the ISAKMP
> packets received from the PIX are "malformed".
>
> I can create a site-to-site VPN between the Sonicwall TZ 170 and a 
> Sonicwall
> Pro 4100 but not to the PIX!
>
> Argh!
>
>
> ----- Original Message ----- 
> From: "Adam Greene" <maillist at webjogger.net>
> To: <cisco-nsp at puck.nether.net>
> Sent: Wednesday, April 30, 2008 11:12 AM
> Subject: [c-nsp] sonicwall / PIX VPN woes
>
>
>> Hi,
>>
>> Trying to set up a site-to-site VPN between PIX 515E 6.3(3) and Sonicwall
>> TZ 170 SonicOS Enhanced 3.2.3.0-6e.
>>
>> I followed all the instructions both on CCO
>> (http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a008052c9d4.shtml)
>> and the Sonicwall site
>> (http://www.sonicwall.com/downloads/vpn_interoperability_between_sonicos30e_and_cisco_pix_firewall.pdf).
>>
>> It seems to be hanging on Phase II negotiation.
>>
>> The sonicwall reports:
>>
>> 04/30/2008 10:02:06.080 - Info - VPN IKE - IKE Initiator: Start Main Mode
>> negotiation (Phase 1)
>> 04/30/2008 10:02:06.400 - Info - VPN IKE - IKE Initiator: Main Mode
>> complete (Phase 1) ;3DES; SHA1; DH Group 2; lifetime=28800 secs
>> 04/30/2008 10:02:06.400 - Info - VPN IKE - IKE Initiator: Start Quick 
>> Mode
>> (Phase 2).
>> 04/30/2008 10:02:06.448 - Info - VPN IKE - IKE Responder: Received Quick
>> Mode Request (Phase 2)
>> 04/30/2008 10:02:21.448 - Warning - VPN IKE - Received packet
>> retransmission. Drop duplicate packet
>> 04/30/2008 10:02:36.448 - Warning - VPN IKE - Received packet
>> retransmission. Drop duplicate packet
>>
>> The pix reports:
>>
>> PIX# sh crypto isa sa
>> Total     : 1
>> Embryonic : 0
>>        dst               src        state     pending     created
>>       x.x.x.x    y.y.y.y    OAK_CONF_ADDR   0           0
>>
>> And a pix debug shows:
>>
>> ISAKMP (0): processing SA payload. message ID = 0
>>
>> ISAKMP (0): Checking ISAKMP transform 1 against priority 10 policy
>> ISAKMP:      encryption 3DES-CBC
>> ISAKMP:      hash SHA
>> ISAKMP:      default group 2
>> 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): processing vendor id payload
>>
>> ISAKMP (0): SA is doing pre-shared key authentication using id type
>> ID_IPV4_ADDR
>> return status is IKMP_NO_ERROR
>> crypto_isakmp_process_block:src:x.x.x.x, dest:y.y.y.y 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): received xauth v6 vendor id
>>
>> ISAKMP (0): processing vendor id payload
>>
>> ISAKMP (0): processing vendor id payload
>>
>> ISAKMP (0): remote peer supports dead peer detection
>>
>> return status is IKMP_NO_ERROR
>> crypto_isakmp_process_block:src:x.x.x.x, dest:y.y.y.y spt:500 dpt:500
>> OAK_MM exchange
>> ISAKMP (0): processing ID payload. message ID = 0
>> ISAKMP (0): processing HASH payload. message ID = 0
>> ISAKMP (0): SA has been authenticated
>>
>> ISAKMP (0): ID payload
>>        next-payload : 8
>>        type         : 1
>>        protocol     : 17
>>        port         : 500
>>        length       : 8
>> ISAKMP (0): Total payload length: 12
>> return status is IKMP_NO_ERROR
>> ISAKMP (0): sending INITIAL_CONTACT notify
>> ISAKMP (0): sending NOTIFY message 24578 protocol 1
>> VPN Peer: ISAKMP: Added new peer: ip:x.x.x.x/500 Total VPN Peers:1
>> VPN Peer: ISAKMP: Peer ip:x.x.x.x/500 Ref cnt incremented to:1 Total VPN
>> Peers:1
>> crypto_isakmp_process_block:src:x.x.x.x, dest:y.y.y.y spt:500 dpt:500
>> OAK_QM exchange
>> ISAKMP (0:0): Need config/address
>> ISAKMP (0:0): initiating peer config to x.x.x.x. ID = zzzzzzz 
>> (1xda111cf8)
>> return status is IKMP_NO_ERROR
>> crypto_isakmp_process_block:src:x.x.x.x, dest:y.y.y.y spt:500 dpt:500
>> ISAKMP: phase 2 packet is a duplicate of a previous packet
>> ISAKMP: resending last response
>> crypto_isakmp_process_block:src:x.x.x.x, dest:y.y.y.y spt:500 dpt:500
>> ISAKMP: phase 2 packet is a duplicate of a previous packet
>> ISAKMP: resending last response
>> ISAKMP (0): retransmitting Config Mode Request...
>>
>>
>> Any ideas what might be failing?
>>
>> I'm not sure why OAK messages would be showing up at all.
>>
>> Thanks,
>> Adam
>>
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
>>
>>
>>
>>
>
>
>
>
>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>
>
>
> 







More information about the cisco-nsp mailing list