Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
HansKazan
Contributor
Jump to solution

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!

0 Kudos
1 Solution

Accepted Solutions
PhoneBoy
Admin
Admin

Yes, log traffic should be handled via Implied Rules.
Have you gone through this SK to troubleshoot? https://support.checkpoint.com/results/sk/sk40090 

View solution in original post

5 Replies
PhoneBoy
Admin
Admin

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).

0 Kudos
HansKazan
Contributor

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!

0 Kudos
PhoneBoy
Admin
Admin

Yes, log traffic should be handled via Implied Rules.
Have you gone through this SK to troubleshoot? https://support.checkpoint.com/results/sk/sk40090 

HansKazan
Contributor

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!

 

0 Kudos
PhoneBoy
Admin
Admin

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... 

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events