Since Check Point R80 it's necessary not to connect Tufin SecureTrack to a Check Point Management using only OPSEC, but an HTTPS connection to the Check Point Management API is necessary also. This might result in a scenario shown here.
Problem and Symptom
- Monitoring the Check Point Management R80x has been configured successfully in SecureTrack i.e. connections using OPSEC and Management API are configured and certificates have been retrieved.
- Testing the connectivity by SecureTrack has been successful
- Starting the newly monitored Check Point Management has been successful, the icon is indicated with a green sign - so everything seems ok
- no revisions are retrieved
- in the file /var/log/st/checkpoint.get_checkpoint_conf_<IP>_<ID>.log an information is shown:
[main::c.t.s.c.GetCheckpointConf.handleVersionMismatch] [user:] Device Version Mismatch : The Device Got Version mismatch returning device version for updating db
[main::c.t.s.c.GetCheckpointConf.handleVersionMismatch] [user:] Server API version 1.5, Max supported API version 1.5, argument API version 1.1
Tufin SecureTrack seems to take the wrong version of the Check Point API. This isn't always the case, but it might happen. In this case, SecureTrack tries version 1.1, but the Check Point Server uses version 1.5. This needs to be adjusted, using these steps:
- Check if the file /usr/local/st/javatools/config.properties is present
- If not, create a new file using vi or another CLI editor and
- insert this line:
This defines the version SecureTrack shall take for monitoring Check Point Management R80.x.
The version shown above is fine for the logs above, but if necessary take another (correct) version
- Restart the monitoring of this device in SecureTrack by
# st restart <ID>
Shortly after these steps, a revision should show up in SecureTrack.