- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Re: Question regarding logging for remotely manage...
- 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
Question regarding logging for remotely managed Gateway used for S2S VPN
Hello CheckMates
I have to establish a VPN S2S tunnel with a remotely managed CP-GW. To prepare, I have simulated the environment in my lab (R81.20 JHF 84) and noticed that no amount of NAT or packet manipulation let my "on-prem" SMS receive the logging originating from the VPN-GW.
After following this sk, it worked.
https://support.checkpoint.com/results/sk/sk111954
This leads me to the following questions below.
- Could someone please elaborate how and why this works on a technical level and if a more modern approach exists that I may have overlooked if the modern answer deviates from what is written in the sk?
- Additionally, what change or impact does this change to the implied_rules.def file have for the locally managed CP Gateways? How does the functionality of log connections change, if at all, and what steps should then be taken.
- Furthermore, why does port:257 not show up in the logging after the connection between the VPN-GW and SMS is established? Is it encapsulated in another protocol?
Thank you for your valuable time and input as always!
- Labels:
-
Documentation
-
Logging
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, log traffic should be handled via Implied Rules.
Have you gone through this SK to troubleshoot? https://support.checkpoint.com/results/sk/sk40090
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
We do NOT put management traffic through VPN by design.
The reason is that if your VPN goes down…so does your ability to manage the remote devices.
Changing implied_rules.def (the only way to do that at current) changes this behavior.
This is compiled as part of the policy pushed to all managed gateways (where implied rules are relevant).
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your response.
So if I understand correctly, TCP/257 is seen as management traffic and hits the implied rules that take priority over whatever is manually defined. However, why is this behavior different for logging? I am able to NAT CPD and related services to the SMS just fine, but failed to find a solution to send logs without the use of a VPN tunnel.
When I was able to forward TCP/257, it was seen (only once) in the logfile, but the logs were not added to the SmartConsole log browser.
If sending the logs over the VPN tunnel would not be recommended, what would be the correct solution?
Thank you for your time!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, log traffic should be handled via Implied Rules.
Have you gone through this SK to troubleshoot? https://support.checkpoint.com/results/sk/sk40090
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for your assistance! I had underestimated the importance of the following due to possible misphrasing of "on" possibly needing to be changed to "for":
Note: When NAT is configured on the Security Management object, make sure to check the 'Apply for Security Gateway Control Connections' checkbox.
I thought that I could manually manipulate this, but I appear to have been wrong.
Before letting the object auto-NAT and enabling this tickbox I noticed that the output of cpstat fw -f log_connection showed the private IP address of HQ-SMS on the remote gateway. After enabling the tickbox, I noticed that the output changed from private (10.0.1.100) to "public" (1.1.1.1) with a log connected status and the logs being populated in SmartConsole logging after matching the DST NAT rule to return the traffic flow.
If I have jumped to the wrong conclusion, I would be happy to hear it, as I cannot currently verify if the reboot of my system had any influence on the matter. Until then I consider my question fully answered and the issue resolved!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
You understand the issue correctly. 🙂
Note that we've improved this a bit in R82: https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_SecurityManagement_AdminGuide/Cont...
![](/skins/images/7A1782F19EEDD3757E1DDB3CF96B7DC3/responsive_peak/images/icon_anonymous_message.png)