[edit: I think I misunderstood the original question but have cleared it up in my next post. Leaving this here 'cause everyone likes to learn PCaps.]
Wall of text incoming. 🙂
Since this is going across a VPN, you'll likely want to use 'fw monitor' and, if you're using https://tcpdump101.com you'll want to select the "New -F" version since you're on R80.40. Also, we're going to pretend that your Management/SMS IP address is 10.20.30.40, the Internal IP of your P81 is 192.168.192.168 and that we don't care about what Layer-3 protocol or Layer-4 ports we're capturing - We want them all. Take a look at the following screenshot which will show you what the command will look like. I've highlighted three items to pay attention to:
You will need to change the Source IP Address and Destination IP Address to match with your actual infrastructure. Also, take note that this version of 'fw monitor' captures both Pre- and Post-Encryption so you'll be able to see the packets as they pass through the VPN - There's no need to change anything here, I just wanted to highlight that for you.
Take the command (fw monitor -F "10.20.30.40,0,192.168.192.168,0,0") and run it on your R80.40 gateway - Do not do this from the management station or you'll end up with a recursive packet capture which may fill up your SSH buffer and that's not good. Once the command has loaded, send TCP traffic (SSH, SmartConsole, whatever) from the management station to the internal IP address of the P81 gateway. You should see something like the following:
[i] 10.20.30.40.12345 -> 192.169.192.168.22
[I] 10.20.30.40.12345 -> 192.169.192.168.22
[e] 10.20.30.40.12345 -> 192.169.192.168.22
This indicates that the packet has passed the wire and into the Check Point kernel (i), passed the first chain of inspection (I) and entered into a VPN tunnel (e). (There's a lot more happening but this is the basic version of what's happening). I'm 99.9% certain that this is already happening based on the screenshot of the logs you posted (In IT, never say 100% 😉) which is a good sign.
Next is to verify that the P81 is receiving the packets properly. Unfortunately, I'm not familiar with these devices but if they have either a packet capture tool (like tcpdump) or, even better, a kernel-level network flow diagnosis tool (like 'fw monitor') then we can use that to see what's happening to the packet. If it doesn't, here's something goofy you can try which will help narrow down whether this is an issue with traffic or the actual application (SSH, CPMI, whatever) connection:
On the remote (P81) side, instantiate a Linux box/VM. On that box, install the 'socat' utility. Run the command 'socat TCP-LISTEN:23,fork TCP:192.168.192.168:22' <-- This will create a LISTEN socket on TCP/23 of the Linux host and redirect any traffic it receives to 192.168.192.168 on TCP/22. Once configured, use an SSH client (like PuTTY) and connect to 'Linux_host_IP_address:23' and you should be prompted to log into the P81 box over SSH. If it works, then the service (SSH in this case) is working and it's a network issue. If not, then run a PCap on the Linux box (use tcpdump in this case) and see what's happening to the packets. Keep in mind that you can redirect any Layer-4 port with socat so, in theory, you could do this with CPMI but that will make things much (MUCH) harder to manage and I would only do this in a lab, not production.
Let me know if you need more info and I'll do my best to help out but free time isn't a commodity I have a lot of right now, sorry. Real-life, my job and all that jazz... Always gets in the way. 🙃
With all that being said, are you able to just peer CPMI over the WAN? It's all encrypted anyway.
Gr@ve_Rose
