Logging not working for Azure CloudGuard gateways and SMS behind NAT

[Nocky24]

Our topology is as follows:

10.3.3.4/27 - BackEnd Subnet
Azure Firewall (R80.10)
10.2.2.4/27 - FrontEnd Subnet
|
Azure Check Point Cluster Public IP
|
( Internet )
|
1.2.3.4/29
On-Prem Check Point 5400 Series Appliance Cluster (R80.10)
10.1.1.1/24
|
10.1.1.5/24 (1.2.3.5/29 NAT IP)
SmartCenter/Security Management Server (R80.30)

As you can see our SMS is NATed behind our 5400 series appliances which it also manages. The management object has the private 10.1.1.5/24 defined as the IP in the General Properties tab and then public 1.2.3.5/29 is defined in the NAT tab, set to static IP, install on 5400 series gateway and Apply for Security Gateway control connections ticked.

This works for all of our other physical appliances - logging and CRL checking, all fine. However, this does not work for the Azure gateways as they persistently want to get to the SMS on the private IP, which doesn't work.

Things we've tried:

1. Editing the masters file by replacing the SMS name with the public IP of the management then locking the file changes using the chattr command. We've had limited success with this - if we make the change and restart the FWD service it will start working, but if we push policy again it will start using the private IP again. I'm looking for something more permanent.
2. Creating a dummy object with the IP of 1.2.3.5, tick Logging & Status blade, then select this as the logging server for the Azure gateways. The Azure gateways pick up the change, but they still persist in sending logs to the private IP.
3. Tried adding a NAT rule to the top of the NAT policy for anything from src:10.2.2.4/27 (FrontEnd Subnet) to dst: 10.1.1.5 (private SMS) then translate to dst:1.2.3.5 (public SMS). No luck here either.

I originally thought it was because we were using an older R80.10 template, but I've deployed a new R80.20 cluster in Azure and updated to the latest jumbo and we still get the same issue.

Running out of ideas now, any help/suggestions would be appreciated 🙂

[PhoneBoy]

Generally you should not need to chattr the $FWDIR/conf/masters file.
It looks like this SK might apply: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
In which case, you need to contact the TAC for a hotfix.

[Nocky24]

Thanks for the quick response!

In our situation it's the other way round. The gateway is trying the internal SMS IP (which fails), but the public IP of the SMS works. Reckon they'd be able to tweak it to account for this?

For info our SMS is on R80.30 as well.

[Wolfgang · Accepted solution]

Richard,

you can force your gateway to use a specific IP to send logs and getting policy whatever you defined in your management object.

Have a look at $FWDIR/conf/masters file on Security Gateway is overwritten during each policy installation

We used this in a customer environment with some strange NAT configuration beetween SMS and gateways (NAT is done by third party gateways).

Wolfgang

[Nocky24]

Thanks Wolfgang. Will this approach be any different from changing the IP in the masters file and locking it?

[Wolfgang]

Richard, yes, the change survive a policy install. As you wrote in your first post you experience problems after a policy install, regardless of locking the master file. With the configuration from the knowledgebase article never mind the configuration in SmartCansole, only masters file is used. Wolfgang

[Nocky24]

Sorry for the late reply, but just wanted to say thanks for the suggestion as this allowed me to force the gateways to use the IP specified in the masters file for it's logging server.  sk105280 and sk102712 were both really useful.

EDIT: Just for clarity, the config I was missing was setting the define_logging_servers parameter to False on the Azure gateway cluster object in GuiDBedit. I then pushed policy to the gateway, did a quick cpstop/cpstart and it started using the IP I defined in the masters file.

As mentioned initially though, it's odd that I should have to do this as this isn't some strange Third Party NAT scenario (unless you include Azure's NAT). This is CloudGuard gateways to an SMS sat behind a Check Point Appliance (SMS also manages this appliance). Glad it's fixed though!

[Luis_Miguel_Mig]

Do changes in $FWDIR/conf/masters  at a gateway take immediate effect?
I am asking it because my R77 gateways failover to the secondary sever log when there is a connectivity failure but some of them fail to return sending logs to the primary server log when the primary server log is back up.
I usually have to reinstall the policy to force the gateway to send the logs to the primary log server but I was wondering if I could resolve it locally at the gateway.

[Dror_Aharony]

I doubt that would be a proper way to resolve this.
I suggest a TAC ticket, as your primary Log-Server should almost immediately resume receiving logs once connection is resumed.
Which version is your Mgmt or Log-Server?
Does it happen only on R77.x GWs & not R80.x GWs?

[Luis_Miguel_Mig]

I am running R77.20. In my case, I don't mind if the $FWDIR/conf/masters is overwritten next time I push the policy.
It feels like a bug, because it is not working as expected and it only happens to the active members of the ClusterXL. Funnily enough the standby member resume sending logs to the primary log server.
I was just wondering if there was a graceful way to failover to primary log server or refresh $FWDIR/conf/masters  config in a way

According to sk98317,  I guess I could reset/delete the connection from the gateway to the log server on port 257, no?

[Dror_Aharony]

TAC/Support ticket definitely.
I can suggest upgrading GWs to our latest & greatest version of R80.40 or even R81.

There is quick way that refreshes the Gateway's log-connection via CLI, but I'm a bit hesitant to recommend it.
You can try that on both your Primary Log-Server 1st & then on the 'bad/active' GW itself.

Restarting the Gateway's FWD process by:
cpwd_admin stop -name FWD; cpwd_admin start -name FWD -path "$FWDIR/bin/fwd" -command "fwd"

Check log-connection status by:

cpstat fw -f log_connection

Restarting Gateway's FWD process may result in partial info in some log-updates, but may occur on communication failures/resumes between Primary/Backup Log-Servers anyway.

[Luis_Miguel_Mig]

Yeah, we are in the process to migrate to R80.40.
I prefer to keep installing the policy than restarting the FWD process but perhaps deleting the tcp connection to the secondary log server could be a good option too

[Dror_Aharony]

Great.
You can safely try restarting the FWD process on the Primary Log-Server. It's both quick & safe.
I guess you can try that too.
Restarting the GW's FWD is also very quick - quicker than installing the policy.
Your call.

[Luis_Miguel_Mig]

If I restart the GW's FWD it will cause a clusterXL failover, no?
If I restart the log server FWD it will have an impact in other gateways too

I have tried to delete the tcp session between the gateway and the log server following https://community.checkpoint.com/t5/Enterprise-Appliances-and-Gaia/How-to-manually-delete-an-entry-f... but not enough, the gateway keeps sending the logs to the secondary

Unfortunatelly there is nothing like tcpkill at the log server.

I

[Dror_Aharony]

1. No, Not related to Cluster (you're good).
2. Yes, that drops/restarts for a very short while (seconds) the Log-Server's ability to receive logs = FWD process
    (I assumed it's not receiving any logs, as it was "down" & we're trying to resume connection to it as fast as possible)