Cross-site communication problem

[junior_kakou]

Good evening,
here is my problem:
I have 2 sites A and B, site A has a CP 3600 behind which run 2 AD servers, a web server and 1 SQL server.
on site A there's no firewall, but an AD server connected behind a Mikrotik router. the site-to-site vpn between the Mikrotik routers works well and the AD servers on sites A and B synchronize directly.
i installed a NetBackup backup server on site B, no communication problems between the NetBackup server and site B's AD server.
but it's impossible to reach the servers at site A on port 1556 and 13724, even though they're open on the servers and the CP.
a Mngnt_master object is created for the backup server on site B 172.16.0.6 and the objects for the servers on site A 192.168.1.X. a rule is created in the firewall to let the connection go through, but it doesn't work.

i'd like to know if the problem comes from the CP, then how to open the ports correctly on the CP.
thank you.

[PhoneBoy]

On one hand, you say Site A has a 3600, yet on the very next line you say "site A has no firewall, but an AD server behind a Mikrotik router"...which is it?
A simple network diagram showing all the mentioned components would help tremendously.

What troubleshooting has been done so far on this issue?
Do you see logs on the Check Point that the traffic has been accepted, for instance?
Have you use a tcpdump or fw monitor to verify the traffic is leaving the gateway through the VPN tunnel?
Have you run any debugs on the traffic in question?

The following (which I got from AI Copilot, but looks correct) might help to understand what is going on.
Please make sure to follow the mandatory guidelines to minimize the potential impact of this operation:

Mandatory Guidelines:

• The kernel debug is a heavy operation and might cause a machine to hang or even crash.
• Perform this operation only during a maintenance window due to the high impact it might have.
• Ensure you have a console connection available in case the machine hangs.
• Validate before and after the operation that the state of the machine is stable (no high CPU, etc).

Debug Procedure

1. Connect to the command line on the Security Gateway / each Cluster Member three times - open three separate shell windows:

   • 1st shell window: to run the VPN user space debug and the kernel debug.
   • 2nd shell window: to run the FW Monitor traffic capture.
   • 3rd shell window: to run the TCPdump traffic capture.

2. In each shell window, log in to the Expert mode.

3. Start the FW Monitor traffic capture in the 2nd shell:

   fw monitor -F "<Source IP>,<Source Port>,<Dest IP>,<Dest Port>,<Protocol Number>" -o /var/log/fw_mon_traffic.cap
   

   • Example:

     fw monitor -F "192.168.1.1,0,192.168.2.1,0,0" -o /var/log/fw_mon_traffic.cap
     

   • This captures traffic between192.168.1.1and192.168.2.1.

4. Start the kernel debug in the 1st shell:

   • Configure the applicable kernel debug filters for VPN peers to decrease the number of debug messages:

     fw ctl set str simple_debug_filter_vpn_1 '<IPv4_Address_#1_of_VPN_Peer>' -a
     fw ctl set str simple_debug_filter_vpn_2 '<IPv4_Address_#2_of_VPN_Peer>' -a
     

   • Example:

     fw ctl set str simple_debug_filter_vpn_1 '192.168.1.1' -a
     fw ctl set str simple_debug_filter_vpn_2 '192.168.2.1' -a
     

   • Start the kernel debug and save its output in a file:

     fw ctl kdebug -T -f > /var/log/kernel_debug.txt
     

5. Start the TCPdump traffic capture on the external VPN interface in the 3rd shell:

   tcpdump -p -e -n -i <Name of VPN Interface> -w /var/log/tcpdump.cap
   

   • Example:

     tcpdump -p -e -n -i eth1 -w /var/log/tcpdump.cap
     

6. Replicate the issue or wait for the issue to occur. Make sure the problem was replicated.

7. Stop the kernel debug in the 1st shell:

   • PressCTRL + Cto stop the kernel debug.
   • Reset the VPN and Firewall kernel debug flags:

     fw ctl debug 0
     

   • Reset the SecureXL debug flags:

     fwaccel dbg resetall
     

   • Reset the kernel debug filters:

     fw ctl set int simple_debug_filter_off 1
     

8. Stop the VPN user space debug:

   vpn debug off
   

9. Stop the TCPdump traffic capture in the 3rd shell:

   • PressCTRL + Cto stop the TCPdump capture.

10. Collect the debug files:

    • /var/log/fw_mon_traffic.cap
    • /var/log/kernel_debug.txt
    • /var/log/tcpdump.cap

These steps will help you collect the necessary debug information for traffic between two IP addresses across a site-to-site VPN.

BE AWARE

Important - To prevent negative impact on your production environment, double-check the provided information in the Administration Guide for the involved product.

Learn more:

1. sk180488 - How to collect a debug for VPN issues
2. sk41317 - How to read an IKE.elg debug file
3. R80.40 Site to Site VPN Administration Guide - vpn-debug

[junior_kakou]

Hello PoneBoy;
Sorry I made a mistake in the description. It's site B that doesn't have a CP behind the mikrotik router. communication in the site-to-site VPN works fine. the communication problem is between the CP and the server on site A's coast. port 1556 is open on the servers of sites A and B. a telnet (site A, telnet 172.168.1.2 1556) from a server on site A to site B works fine. But the reverse doesn't work, telnet 192.168.1.2 1556 (site B).

thanks

[PhoneBoy]

Problem is understood.
Following questions:

• What troubleshooting has been done so far on this issue?
• Do you see logs on the Check Point and/or Mikrotik related to the traffic?
• Have you used packet captures at various points to see where the traffic "disappears"?
• Have you use a tcpdump or fw monitor to verify the traffic is leaving the gateway through the VPN tunnel?
• Have you run any debugs on the traffic in question on the gateway, the instructions for which I provided above?