Checkpoint Firewall VSX container is not created


Article ID: 222797


Updated On:


CA Spectrum DX NetOps


We have been trying to monitor a Checkpoint VSX firewall with multiples virtual FW, we are able to see the physical FW but the container and the virtual FW are not being created, we have tried in an older version of Spectrum (10.4.0) and were able to create the FW with the same SNMP configuration on both versions.

We have followed the recommendation in the next URL:


In Spectrum 10.4.0 the CheckPointFirewall model is creating CheckPointApp and in Spectrum 21.2.1 it is creating CheckPointR80App. The reason for this is device firmware version is R80.30 which is not included in Firmware_Version_List default value.

Basically, the model type CheckPointApp and CheckPointR80App are the same. But they have some different things below. Some MIB objects in CheckPointApp have data type: OctetString; however, these objects in CheckPointR80App have different data type: Counter 64 such as vsxCountersPackets ( and other vsx Objects. Why did we create CheckPointR80App? Some old Checkpoint devices have vsxCountersPackets which have data type: OctetString and they work well with CheckPointApp. Then we found some new Checkpoint devices which have MIB object: vsxCountersPackets whose data type is Counter64 (number), which causes Spectrum to be crashed when polling vsxCountersPackets because Spectrum treats vsxCountersPackets as OctetString. So, we have created CheckPointR80App which is the same CheckPointApp but it can deal with vsxCountersPackets has data type: Counter64. So, if there is a Checkpoint device, check the data type of object vsxCountersPackets: If it is OctetString, the correct model is CheckPointApp. If it is Counter64 or Integer (number), the correct model is CheckPointR80App. Now, how does Spectrum choose the correct model for a Checkpoint device? Spectrum reads the MIB object: svnVersion and checks its value in the Firmware_Version_List. If yes, Spectrum creates the model CheckPointApp. If no, Spectrum creates the model CheckPointR80App. - SVN version

svnVersion OBJECT-TYPE
       SYNTAX  DisplayString (SIZE (0..255))
     ACCESS  read-only
     STATUS  mandatory
      "SVN version"
     ::= { svnInfo 1 }


Release : 21.2

Component : Spectrum Discovery & Modeling


At present, CheckPointR80App is not fully available. We propose this workaround:

(a) Adding R80.30 to the Firmware_Version_List so that CheckPointApp is created.
(b) Below KB for avoiding crashes with CheckPointApp

Here are the detailed steps:

On the SpectroSERVER machine

1. Make an OnLineBackup (OLB) of the SSdb in case you need to restore it to its original condition.

2. Stop the SpectroSERVER application.

3. Launch the MTE (Model Type Editor) from the Spectrum Control Panel (SCP)

4. In the Navigation pane, select the Model Types tab. Type "checkpoint" in the filter field and select CheckpointApp.

In the Contents pane, select the Attributes tab. Type "firmw" in the filter field and select the Firmware_Version_List and click on the Edit button.

5. Click on the Edit button.

6. Click on the + button.

7. Click on the Edit button.

8. Type R80.30 and click on the OK button.

9. Click on the OK button.

10. Click on the OK button.

11. Click on File and select Commit do Database.

12. Click on the OK button.

13. Click on File and choose Exit.

14. Start the SpectroSERVER application.


On the OneClick server machine

15. Download the attached file (table-checkpoint-vsx-counters.xml), or from the KB 191749.

16. Stop the Spectrum Tomcat service.

$ cd $SPECROOT/tomcat/bin/

$ ./

17. Move the original $SPECROOT/tomcat/webapps/spectrum/WEB-INF/topo/config/table-checkpoint-vsx-counters.xml file to a different location, outside the tomcat folder.

18. Copy the downloaded file (table-checkpoint-vsx-counters.xml) to the $SPECROOT/tomcat/webapps/spectrum/WEB-INF/topo/config/ directory. Ensure it has the same permission and ownership as other files in the same folder.

19. Start the Spectrum Tomcat service.

$ cd $SPECROOT/tomcat/bin/

$ ./

20. Discover the Checkpoint firewall. The container will be modeled.

Additional Information

Perform the Device Certification prior to discovering the Checkpoint firewall.


If you have a Distributed SpectroSERVER (DSS) environment, you will need to synchronize the Catalog from the MLS (where you modified the Catalog through the MTE) to the other remote landscapes.

1. Make an OnLineBackup (OLB) of the MLS (where you modified the Catalog).

2. Also make an OnLineBackup (OLB) of the other remote landscapes.

3. Copy the SSdb backup from the MLS to the other remote landscapes. You can rename and place it in the $SPECROOT/SS-DB-Backup/ directory, for example.

4. Stop the SpectroSERVER on the remote landscape.

5. Extract the SSdb backup from the MLS.

$ cd $SPECROOT/SS-DB-Backup/

$ gunzip SSdb-MLS_yyyymmdd_hhmm.SSdb.gz

6. Also extract the SSdb from the current remote landscape.

$ gunzip SSdb_yyyymmdd_hhmm.SSdb.gz

7. Load Catalog only from the MLS SSdb backup (you must run from the $SPECROOT/SS/ directory).


$ ../SS-Tools/SSdbload -i -c ../SS-DB-Backup/SSdb-MLS_yyyymmdd_hhmm.SSdb

8. Load Models only from the current remote landscape SSdb backup.

$ ../SS-Tools/SSdbload -m ../SS-DB-Backup/SSdb_yyyymmdd_hhmm.SSdb

9. Start the SpectroSERVER on the remote landscape.


Also, read this community thread about other ways to synchronize the Catalog:


1630097842459__table-checkpoint-vsx-counters.xml get_app