Top 5 Issues To Look For When Troubleshooting Your Check Point Firewalls
We’ve recently taken a snapshot of alerts across all the customers using our indeni Insight service. It’s amazing to see what indeni finds in different devices, made by different vendors. I’d like to take the opportunity to share what we’ve found for Check Point firewalls in this post.
So, if you own Check Point firewalls, here are the top 5 challenges; you should look out for. We recommend printing this and taping to the wall. You’ll need it in your next outage.
Top 5 Challenges
1. NTP misconfigured – it’s amazing how this small configuration can be wrong in so many devices. It’s quite simple really – at the point when you’ve configured the NTP server everything worked flawlessly. Then somebody changed the NTP server’s IP, or a rule in the firewall, or a route in a router, or a… (you get the idea)…and it breaks. The trouble is, you don’t know it’s broken. If you’re lucky, you find out about it in an audit. If you’re unlucky, you find yourself scratching your head wondering why the logs coming out of your firewall are completely off.
Our Recommendation: run periodic checks to make sure the clocks are correctly set on all of your devices.
2.Policy install resulting in high CPU and a cluster fail over – a policy installation is a CPU-intensive process in many cases. The high CPU that results from policy installation may in turn result in the ClusterXL functionality misbehaving. We recommend looking out for traffic loss and/or cluster fail overs during policy installations and considering following SK32488.
Our Recommendation: if you notice flaky network traffic behavior post a policy install, take a look at SK32488.
3. Communication issues between the gateways and management – these result in a variety of issues. From the loss of logs (and firewalls logging locally) to VPN tunnel being taken down due to the gateway’s inability to check the CRL (which is on the management server’s certificate authority).
Our Recommendation: place the communication between gateways and management/log-servers on a separate, dedicated network and ensure that network isn’t touched. If it’s not possible to create this network physically, a logical one that is well communicated within the organization would help too.
4. Differences in configurations across cluster members – Check Point have been generous enough to allow its users to tune and configure every little knob in their products. The complication this presents, however, is that some configurations must be copied manually across cluster members or set differently in different members. If someone makes a change in one member and forgets to change the other, this can break. We’ve also seen many occasions where an RMA resulted in such a situation as a new device was brought on line.
Our Recommendation: don’t make changes to cluster members in the middle of the night 🙂 Seriously though, when clusters behave oddly, check routing, .def files, .conf files, kernel parameters, SecureXL configs, CoreXL configs,etc. and make sure the configurations match across the cluster.
5. Errors, drops, collisions and various traffic issues – while these are basic, you’d be surprised how easily they are missed. Errors normally result from wrong duplex settings while drops from bursty traffic or from lack of resources to handle the traffic that’s flowing (NIC resources or CPU/IRQ resources).
Our Recommendation: monitor the various interface stats closely and identify increases promptly.
Alternatively, you can use indeni to identify all of the above issues and hundreds more. For us, it’s all about avoiding outages by pin-pointing issues before they turn critical. It takes less than 45 minutes to install, no agents (download now) and we’ll be happy to help you do it (contact our support).