I’ve been doing Checkpoint quite a lot, actually for years now. And this inevitably involves communicating with the Checkpoint Technical Assistance Centre (TAC) . And whileyou can easily come up with impression that it is pretty bad (look around at cpug.org) for heated flames about that), my view is that a lot depends on you. The way you manage the ticket and interaction with the Checkpoint TAC is often more important than anything else for successful resolution of the case.
To assist in that I prepared this list of things to do and have in mind before you actually call the TAC and open a case. In my experience following these simple steps will shorten the time and save you nerves substantially.
1. Understand and state the problem exactly.
Clearly defined problem is half the solution. The problem should be described in measurable terms not qualitative ones.Not "VPN tunnels flap and fail all the time" but "VPN tunnel between this and this peers is coming up for 3-5 minutes then goes down for 10 minutes also communication between sites stops and I see in SmartViewTracker the following... "Not "If I enable URL filtering all works slow" but "If I enable URL filtering it takes 40 seconds to load the same page that I load in 3 secs without URL-filtering, my download rates from different sites decrease by such and such numbers and in logs I see …"Screenshots of the error messages are very welcome.
2. "… burden of proof is on the defendant" – gather all needed info even before you get asked to.
Have you worked in a TAC ? No ? Then let me illustrate. The answering Supporter has no slightest idea what the equipment is on your site, what the IP addresses are, whether load-balancers/nat-devices/traffic accelerators are involved, not to mention yours being the 10th case today, in short - he/she knows nothing about your topology, but you ,on the other hand ,having worked for years with the same set up come to think that this knowledge is a known fact to everyone. So please don’t – when approaching the TAC think of it as preparing a presentation that describes your network topology in 10 minutes to a complete stranger on the street (no need to practice this though :)). Topology info you will most probably need to supply: IP addresses of interfaces and routes of all the devices that are involved in the traffic having a problem.All NAT/IPS/load balancing/acceleration tempering going on in your network .Changes in topology that were done just before the problem occurred.
3. Provide Cpinfo files from all the Checkpoint devices involved.
Checkpoint Support engineer most probably has no access to your firewall. And still she/he has to fully understand its configuration and state. The closest to accessing the firewall thing is providing Cpinfo file. If you have a distributed Checkpoint setup do it for all devices as well. It is also advisable to make sure that all your devices have the latest Cpinfo utility installed [sk30567]. Unfortunately regular users can’t download it from Checkpoint Usercenter you will need at least Partner account with them.
NOTE Regarding handing over files to the Checkpoint TAC. When you supply them Cpinfo files you provide complete information about your firewall – its rules, objects and their properties etc. Think of it as if you were giving them the one-to-one copy of the firewall. So if you have some privacy/confidentiality reservations take it into account .
4. Do a packet capture that also includes the problematic traffic.
Should you have any sort of case demanding serious debug be prepared to attach to the case captured traffic while replicating the problem. Of course consider the load on the firewall but usually to see if there are any drops on the traffic Checkpoint will ask you to do fw monitor –o capture.cap . Supplement this capture with output of fw ctl zdebug drop > dropped.txt
5.If opening the case through the Checkpoint website and the problem is rather urgent do a follow up call [ Contact list](https://www.checkpoint.com/about-us/contact-us/
When you open a case it is being put in the queue of all other cases waiting to be assigned to Support Engineers. It happens on FIFO basis (each severity level has its own queue I guess). So it may wait there for few good hours. In such cases and when the case justifies it you may call the TAC and ask the person (not demand) to speed up assigning your case to the Technical Engineer. I used this procedure and usually the case was assigned to someone 15 minutes after my call.
6.Provide correct and most available means to contact you back.
Nothing can be more disheartening for a Supporter than to get a case and then chase you for hours/days.
7. If you work for Checkpoint Partner or proudly hold CCSE/CCSE+ certs do actually some debug yourself ;).Working for Checkpoint Partner (as I do) in my opinion not only gives us immediate unrestricted access to the TAC but also the responsibility to do as much as possible to debug the problem ourselves (moreover it sucks to look amateurish) . I should state that I don’t always follow this advice but always try to.Make the “The NGX Advanced Technical Reference Guide (ATRG) “ [sk31221] your night reading and you will decrease the number of open tickets by 50% guaranteed . When you do relevant debug even without being able to understand results you save many hours of waiting for the TAC Supporter to just ask you for the very same debug and its logs.
8. In case of emergency call 911 and ask for remote session.
In urgent cases when you experience heavy downtime be prepared and even ask for remote session with the Supporter that got your case. Checkpoint have the TeamViewer-alike software that will allow them to connect to your workstation while it is connected to the firewall. Also the last time I checked this software had no (identifiable) keyloggers/Trojans so don’t worry :).
Follow me on https://www.linkedin.com/in/yurislobodyanyuk/ not to miss what I publish on Linkedin, Github, blog, and more.
