[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