After modifying the crypto settings on an existing IPSEC tunnel (like removing a crypto peer and adding a new one), the Ethernet interfaces just freeze, and only the console responds, and the PIX should be reloaded.
I have tested this on PIX-525 and 515 version 6.0(1).
Is this fixed in any later version?
Does any one know some procedure to avoid the freezing?
sorry again if this has been raised, though couldn't find any relevant info on Cisco site.
What exactly did you do? Just remove one of the configured peers in the VPN Map statement?
I've run into similar problems before, but in my case someone had accidentally removed an access list that specified what traffic to send over the IPSec connection. In my case the PIX assumed that ALL traffic was IPSec traffic and tried to process each packet that it received. When the PIX opened up the packet, it dropped it because it wasn't a valid IPSec packet... and of course that included network tests from the secondary PIX, which caused a failover to occur which was infected by the same problem.
The PIX appeared to be locked up, but I could still access it from the console. It was dropping pretty much all data. The only clue without scrolling through 65k of configurations was that the system log was filling up with messages concerning invalid IPSec data.
Not sure if it's at all related to your problem, but you never know ;)
Making configuration changes to the crypto map and reapplying it should not freeze your pix. Most of the times this is what happens:
crypto map vpn 10 ipsec-isakmp
crypto map vpn 10 match address 100
crypto map vpn 10 set peer xxx.xxx.xxx.xxx
crypto map vpn 10 set transform-set myset
access-list 100 permit ip 192.168.1.0 255.255.255.0 10.1.1.0 255.255.255.0
In the above config, while making changes if you remove the access-list 100 completely, then the corresponding "match address" in the crypto config is also removed and now after you add your access-list 100, the "match address" command misses in the config and when you reapply the crypto map to the interface, the Pix encrypts all the traffic since it is not able to find a specific access-list (match address) for this peer.
Mostly this should be the reason for your pix locking on you when you make the changes but I see that you had mentioned that your ethernet freezes. This should not be the case if you are telnetting to the inside interface where the crypto map is not applied.
This usually happens only when you telnet to the outside interface through a VPN Tunnel or SSHed into the pix.
Just to add to the confusion I have also used putty (ssh client) from outside and also expierienced the same sort of lockup. We were trying to change the ip address of the vpn peer and whenever we put the no command in it would freeze up and require a reboot. We eventually just added a second peer then removed the first one which then worked fine.
Best thing to do is whenever making changes to your crypto configuration, even if its a access-list, is to simply unapply the crypto map from the interface. This allow you to make your changes and verify before reapplying your crypto map to the interface. As ajagadee and dro stated, making changes to a live crypto map in a incorrect order will have undesirable effects.
I do not know the answer to the question, however I have experienced the same issue. I was In the PIX from a telnet session from an Inbound Citrix session. When I made a change to a crypto map statement my Citrix session would drop. I have not found the solution however I was running 6.0(1) code.
Login to the FXOS chassis manager.
Direct your browser to https://hostname/, and log-in using the user-name and password.
Go to Help > About and check the current version:
Check the current version availa...
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...