The answer is surprisingly simple – at the Checkpoint.com . On the home page there is a link to download their products Try Our Products (SPLAT, SmartDefense, Endpoint). You need a free General account in UserCenter, then you fill general questions form and get a link to download the real production image of whatever you chose to download. You get an evaluation license for 30 days at the same page , without any license upon install you get unlimited 15-days trial.

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 while
you 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.
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 :).

I happen from time to time to configure from scratch some Checkpoint UTM/Open Server that is thousand miles away. And from experience the best way to do it is when you have out-of-band fast access to the firewall. Of course not always such well-organized beforehand set up is available. Just like today when I was asked how to change IP address on the interfcae through which you are connected to the firewall.
Ok, to be more specific – client had been connected with his UTM through some ISP that included also IP addresses on the WAN (External) interface of the firewall. Time has come to change ISP and accordingly its IP addresses.
All went surprisingly well, my collegue added new IP address on the External interface as the Secondary IP and from then on he could access/manage firewall through this new IP without a hitch. There is one but though – SSL VPN service was still listening on the old IP and didn’t work because of that. So we had to remove the new IP as Secondary and put it as the Primary one. For this he asked my opinion , I set up some improvised lab and here is how to do it .

1) First, for unmanned location I set up in cron to do restart in say 10-15 minutes from now so if something goes wrong restart will discard any changes done in step 2;

2) Connected through the ssh I did the following two commands on the same line that when finished should not even disconnect you from the ssh. It brings down secondary IP (aliased interface) and assigns this IP to the External interface as the usual Primary one.