R: R: [c-nsp] lan-to-lan pix-vpn3k unidirectional problem

[Zacchello Marco]

Hi all,

I solved my problem, here the summary: 
Cisco PIX Firewall Version 6.3(4) to VPN 3000 Concentrator Version 4.7.1.Rel

(1)At the beggining the VPN L2L starts only from the VPN3k, but if started from
the pix nothing works and the 'debug crypto isakmp/ipsec' logs:
"IPSEC(sa_initiate): ACL = deny; no sa created", so the pix didn't start the negotiation.

(2)Then reading your mail, and some forum about this message, I decided to re-apply (without de-apply or reload the pix)
the "crypto map outside_map interface outside" command, now I see more debug messages, but the negotiation fails.
(before there was no negotiation). I read quickly the new debug, and seemed strange to me, but at this point the failure was only config-related, infact today I changed the LAN2LAN SA configuration on the VPN3k, adding the PFS. (thanks Brian for your help!) and now everything works. 

However, If I understood well, the pix use 'strictly' the crypto map to start the VPN, but loosely accept the incoming VPN?
Why Pix accept the VPN without PFS from VPN3K, but VPN3K doesn't accept the VPN from the pix with PFS?
Moreover, with Cisco PIX Firewall Version 6.3(4), I need to re-apply the "crypto map [] interface" command to correctly load the new istances of crypto map, at this point I'm wondering if upgrade the pix towards 6.3(5) (or 7.0(4), if memory requirements are met), would fix this problem....

Thanks all for your help and patience

bye
Marco


-----Messaggio originale-----
Da: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net]Per conto di Andrew
Yourtchenko
Inviato: venerdì 25 novembre 2005 23.09
A: Peder @ NetworkOblivion
Cc: cisco-nsp Mailing List
Oggetto: Re: R: [c-nsp] lan-to-lan pix-vpn3k unidirectional problem


> you add a new crypto map entry, you ALWAYS have to de-apply and re-apply
> it for it to work correctly.  I've even run into a lot of instances
> where changing the crypto map without de-applying it kills the pix and
> it needs to be physically powered off and on (management is dead).  I
> generally use notepad and setup something like this.

In the early versions the being newly added crypto map entry would mean 
"encrypt everything". And since the set peer statement was absent, and 
transform set was absent - this would indeed nuke your SSH session from 
outside - it would try to encrypt it, but there were no rules.

It's been quite a while since you should no longer need to remove the 
crypto map off the interface before changing it - any entries that are 
incomplete, are inactive until their configuration is finished, so it 
should work. (CSCea89724 is a reference WRT when this was done - 
6.2.3/6.3.2 and later should work as I have described)

Indeed removing/reapplying the crypto map as you mentioned works as well.

If while changing the crypto map your _serial_ console went dead - then it 
would be a separate story with some different reason - which I can not 
think of - never seen this happening.

thanks,
andrew
_______________________________________________
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/

******************* DISCLAIMER *******************************
Le informazioni contenute in questa comunicazione e gli eventuali documenti allegati hanno carattere confidenziale e sono ad uso esclusivo del destinatario. Nel caso questa comunicazione Vi sia pervenuta per errore, Vi informiamo che la sua diffusione e riproduzione è contraria alla legge e preghiamo di darci prontamente avviso e di cancellare quanto ricevuto. Grazie.

This e-mail message and any files transmitted with it contain confidential information intended only for the person(s) to whom it is addressed. If you are not the intended recipient, you are hereby notified that any use or distribution of this e-mail is strictly prohibited: please notify the sender and delete the original message. Thank you.