SmartLSM Security Profile with Secondary Management Servers

[Antonio_Martins]

Hi CheckMates,

Should I add Secondary Management server on "Fetch Policy" section in SmartLSM Security Profile?

Should I add dedicated SmartEvent server on "Logs > Log Servers" section in SmartLSM Security Profile?

Thank you

[Tal_Paz-Fridman]

Hi 

Adding my colleague @Liat_Cihan and @Gal_Osherov  for their input.

Thanks

Tal

[Gal_Osherov]

Hi,

First, bear in mind the following limitation regarding HA in SmartProvisioning:

"When working with LSM managed Security gateways in a Management High Availability environment, creating and working with LSM gateways must be consistent, they can only be used in the Security Management server they are created in.
Using the secondary Security Management server might lead to inconsistent actions/status related to LSM objects."

Now to answer your questions:

1. You should add the secondary server to the servers list in the "Fetch Policy" section. This way, you can create a SmartProvisioning object linked to this profile on any of the servers, and it will fetch the policy when the server it was created on is up (according to the limitation above).

2. If you are using the SmartEvent server as a log server and would like to forward your logs to it, then you should add it as a log server in the SmartLSM Security Profile editor. If you won't, they will be forwarded to your management machine.

[Antonio_Martins]

The LSM managed Security Gateways in a Management HA environment limitation is not referred in R80.40 limitations... Nevertheless, if I disconnect Primary Management server all the Gateways status is "Not Respoding":

If I issue a "Get Status Details" I see this:

Provisioning Status: Unknown
Message: Security Gateway didn't sync at it's Next Sync Time

Should I 'Push Policy', 'Push Settings and Actions' or both?

[Gal_Osherov]

Hi again,

Actually, the limitation I quoted from my last message was copied from sk160753 "Check Point R80.40 Known Limitations".

Going back to the limitation, did you create the gateways in the primary management server or the secondary?

If the gateways were created in the primary server, and you failover to the secondary, what you are describing is the behavior expected according to the limitation.