I have a PIX 535 w/failover, 6 interfaces (inside, outside, syslog, state full, and 2 not used) My configuration is 35 pages printed. We are an enterprise entity running off a single firewall. I am logging informational to a kiwi syslog over udp to filter the monster that the pix creates for a log. The PIX has a gig of ram. I am using turbo access lists.

Problem:

The cpu usage goes to 99% and stays there for 15-20 minutes if I make any changes to a object group. This slows traffic but not to a halt. If I make more than 5 changes in 20 minutes it will slow significantly and traffic will timeout through the PIX. We have the w32.korgo.V virus here and when it was on 6 different machines it would bring the PIX to a halt. It tries to make connections to other IP's on port 445 and we have 445 blocked on the firewall. Even though those 6 machines were infected and getting denied by the PIX every time they attempted to connect outside it, this would cause the pix to slow down enough to time out all traffic and most attempts to connect to the PIX itself. We blocked 445 on the router before the pix and the cpu immediately dropped to 6% usage and stays below 10.

It is not just the virus but a number of things that will cause the pix to slow lately and I do not see any errors or unexplained syslog messages. Cisco has sent us a new 535 w/failover and the same thing happened on the new boxes. This same config has worked perfectly for 5 months with nothing like this happening. I keep getting "escalated" to a different engineer in Cisco, but I am convinced that the smartest Cisco people do not work for Cisco. Does anyone have any ideas without me sending the config?

Using the turbo acls, I can see a CPU spike when changes to object groups because the acl has to be recompiled, but it should only take seconds, not 15-20 minutes.. I think that could be what is compounding the problem if you try to make multiple changes in a short period of time.

ICMP is blocked at the internal router yes. I have never had a problem with the PIX performance in the past. I am not making any more changes now than before, but for some reason the performance is shot.

Finally! I found a solution. For anyone else who may run into this problem:

Having problems with high CPU on the PIX when an access-list compiles using object-groups?
Very large ACLs ( >200k) may not compile, or have very poor performace
Solution: Upgrade to 6.3(3.107) or higher, and disable turbo-acl and add the new CLI
access-list <acl_name> object-group-search

Try this by disabling turbo acl and adding the access-list <acl_name> object-group-search command.
1. no access-lsit compiled
2. access-list <inside_out > object-group-search,access-list <outside_access_in > object-group-search, and one for each acl

Featured Post

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

I recently attended Cisco Live! in Las Vegas, a conference that boasted over 28,000 techies in attendance, and a week of hands-on learning hosted by a solid partner with which Concerto goes to market. Every year, Cisco displays cutting-edge technol…

On Feb. 28, Amazon’s Simple Storage Service (S3) went down after an employee issued the wrong command during a debugging exercise. Among those affected were big names like Netflix, Spotify and Expedia.

Both in life and business – not all partnerships are created equal.
As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …

Both in life and business – not all partnerships are created equal. Spend 30 short minutes with us to learn:
• Key questions to ask when considering a partnership to accelerate your business into the cloud
• Pitfalls and mistakes other partners…