Re: Pix hangs when crypto config is changed

pax_2111 · ‎12-10-2002

Hi,

maybe this has been rasied previously.

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.

dro · ‎12-10-2002

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 ;)

-Joshua

ajagadee · ‎12-10-2002

Hi,

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.

Regards,

Arul

pax_2111 · ‎12-10-2002

The issue you raised with access-list is obvious and it applies also to IOS VPNs. But with PIX it's completely different; let me explain further.

Suppose I have crypto map vpn 10 set peer 10.1.1.1 and I want to change it.

I write crypto map vpn 10 set peer 10.1.2.1 and the config shows

crypto map vpn 10 set peer 10.1.1.1 10.1.2.1 (two peers).

Now I want to remove the 10.1.1.1 peer by no crypto map vpn 10 set peer 10.1.1.1. Right? Here it freezes. What I guess it cannot purge the SAs of a deleted peer.

Only console responds and only a reboot will recover your system. Note also that I am telnetting through the inside interface.

I have tried this on two PIX 525 in failover, and once the active freezes, the failover Ethernet is also frozen and the standby doesn't kick in.

Imagine that the failover PIXs are in an ISP :-) and disabling and reenabling crypto on the interface is not an option.

With IOS VPNs I haven't encountered a single issue like this.

Thanx for your replys guys.

ptiedemann · ‎12-12-2002

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.

kdurrett · ‎12-10-2002

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.

Kurtis Durrett

tmoreo · ‎12-11-2002

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.