- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Checkpoint Gateways are not sending the logs t...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Checkpoint Gateways are not sending the logs to Checkpoint management server
Hi All,
We are using Checkpoint R77.30 firewall, Gateways are not sending the logs to Checkpoint management server, Is anyone has similar issue?.
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
- check management interface in GAIA GUI
- add no NAT rule from GW to Management
- add log rule (from GW to Management)
- check log port on Management ( netstat -na | grep 257)
- do you see log trafffic (tcpdump -i <ethx> port 257)
- check drops (fw ctl zdebug drop | grep 257)
- check log server in global properties
- check on GW the masters.cf file - the log server should be entered here
Otherwise open a Check Point case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Shira,
First of all I would define auto forwarding logs to MGMT server from the GW object. This will ensure that it will auto-forward logs.
To do it manually, you can use the command "fw fetchlogs <GW IP>" on the MGMT or any log server.
If you can't see the logs after the import of the logs, this might happen because they're no indexed. By default the days to index
on the MGMT is indexing log file that were closed in the last 24 hours. You can change it by using the following link:
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I think I have the same issue. My coffee machine at home doesn't want to make cappuchino sometimes. Maybe you know the reason for that?
Information, details about the setup, logs, configs and settings, your actions and tests? Nobody will be able to help you without some basic input information.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I had this happen when my management server died, and was off line for a couple of days while I rebuilt the RMA unit. I called support, and there is a way to go into each gateway and jog its memory. However, the simpler way was to do a policy push to each gateway/cluster that the management server managed.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
- check management interface in GAIA GUI
- add no NAT rule from GW to Management
- add log rule (from GW to Management)
- check log port on Management ( netstat -na | grep 257)
- do you see log trafffic (tcpdump -i <ethx> port 257)
- check drops (fw ctl zdebug drop | grep 257)
- check log server in global properties
- check on GW the masters.cf file - the log server should be entered here
Otherwise open a Check Point case.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You can add, make sure the Mgmt machine's main IP (object global properties) is on the same network as the GW. It doesn't seem to matter if the policies reach the GW when you push and both machines have the correct interface set to Mgmt. Unless the displayed IP matches it doesn't seem to work.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Heiko,
Sorry to come again with this but I have a similar issue. In my case, it's a Quantum Spark 1535. When I run "tcpdump -nni any port 257", I don't see anything. Looks like firewall isn't sending out any log. Any idea what could be the root cause ?
Thanks in advance for your help.
Regards,
Alain
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
One more tip, if your log server is separate from Mgmt then install database and then push policy.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
in addition to tips provided by Heiko Ankenbrand, check free space in your log server, if not create sufficient space. most of the cases below procedure saved my day.
- create a dummy Mgmt server Object with different IP in the Dashboard as a temp log server (Dummy_mgmt)
- From the Logs option under Cluster or gateway properties , untag the Management Server from the logger and add a temp_log (Dummy_mgmt)) server object
- Installed the Database & pushed the policy.
- Post that we have to revert back the changes and again installed DB & pushed the policy to the gateway. ( means untag current temp_log object and select original management or log server)
- check "netstat -na | grep 257" to verify port status. it should be in established state
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I like the idea but a dummy log server on the same IP can lead to problems. The problem is that the dummy and the original log server want to share port 257. There may be problems here.
Regards
Heiko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
If all these tips don't help, I'd open a ticket.
Regards,
Heiko
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
any non conflicting IP would work
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
See sk38848, sk40090, sk108707 & sk66381
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Rajesh,
Heiko has provided nice steps to troubleshoot this issue. After going through all this steps, definitely you will come to conclusion.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi All,
Finally issue has resolved, Thank you all for your help in fixing the issue.
Spacial thanks to Mr. "Aleksei Shelepov" for His great Suggestion
.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
how did you resolve the issue ? I had similar issue after upgrade to R80.10, and one of R77.30 SMS suddenly failed to receive log. Tried Reboot, reset SIC, log switch , but just not work (also try script to drop monitoring dB using the script in sk for 80.10).
R77.30 mgmt : no log
R80.10 mgmt; no log , no status , but can see the standby mgmt status
Sunny
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi
Log file was corrupted, I created the new log file and moved old logs to new log file, It worked.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I tried this solution, but not works, then i simply disable the "log" option in mgmt object's property, install policy, and then enable the option, and install policy again, then logging resumed.
the above works for the r77.30 mgmt and gateway
for my R80.10 mgmt and r77.30, after i install policy to one vs, the mgmt can receive log from all gateway. but still not be able to see gateways' status.
Sunny
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I ran into this just now after an upgrade. The new firewall didn't appear to be sending logs. However, it was sending them, just with the wrong timestamp, so the log server processed them with the incorrect time. I had to restart the NTP process on the gateway, and then things synced and the logs showed up in the proper place.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We are using R80.10 management server . In between we are observings logs are stopped getting forwarded to management server. At the same time we have observed the error in logger the corelation unit cant connect to one of its log servers. No need to stop the job.
We checked the connectivity and it was fine. However not able to telnet on port 257 from gateway to management server.
Can anyone please help to reaolve this issue?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello Team,
Can anyone please help to resolve this issue? We are frequently facing this issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
👍
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In many situation this short additional procedure (remember additional) helps.
1. Create of a "dummy" Check Point Host object pointing to public IP which is used as a Static NAT IP for original LogServer.
2. Enable Logging&Status function.
3. Edit each problematic gateway and add host from point 1 as a primary log server.
4. Install Policy on problematic Gateways.
5. With command, netstat -apn | grep ":257" on problematic GW You can now monitor if connection with SmartLog public IP is now in ESTABLISHED state. If You see such connection state, logs should be sent to and processed by SmartLog.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Team,
Mgmt: R80.40 HF 154
GW : R80.40 HF 154
Our MGMT server was down from last 2 days, now its up and running smoothly. Anyhow i am not able to see last 2 days logs in smartconsole as they were stored locally in firewall.
Can i move those logs from $FWDIR/log GW folder directly to MGMT server to view them in smartconsole?
any alternate ideas would be appreciated.
Earliest response would be much appreciated.
Regards,
Shira
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Shira,
First of all I would define auto forwarding logs to MGMT server from the GW object. This will ensure that it will auto-forward logs.
To do it manually, you can use the command "fw fetchlogs <GW IP>" on the MGMT or any log server.
If you can't see the logs after the import of the logs, this might happen because they're no indexed. By default the days to index
on the MGMT is indexing log file that were closed in the last 24 hours. You can change it by using the following link: