Can't Remote Access to Cloudguard Cluster (Azure)

[flachance]

Hi,

We have an OnPrem cluster of Open servers (GW1) and a Clouguard Cluster in Azure (GW2). All at R80.40.

There is a VPN tunnel between GW1 and GW2.

We can successfully Remote Access to GW1 with Endpoint VPN client.

But we can’t remote access to GW2. We can establish a connection but cannot access a resource on a subnet behind GW2.

We have an IP pool defined for office mode for GW1 (pool1) and one for GW2 (pool2).

Pool1 is included in the VPN domain of Gw1.

If I include pool2 on the VPN domain of Gw2, I can establish a remote connection, but I can’t access a resource behind Gw2. The only traffic I can see from the client are successful tunnel test. Otherwise there is nothing like it doesn’t even make it to Gw2.

If I don’t include pool2 on the VPN domain of Gw2, I still can establish a remote connection but still cannot access a resource behind Gw2. This time I see connection in the logs with the error “According to the policy the packet should not have been decrypted”

Anyone has Remote Access to Cloudguard Cluster in Azure working?

thanks

[the_rock]

Interesting...first off, do you have simple network diagram you can provide for this? Personally, I don't think this is a cloud issue, as that error ir very generic and present in any version really. By the way, when you see that log, what its really saying is that packer should have been encrypted, so question is, what does simple vpn debug show? Can you see in the log the policy in question? Does debug on the firewall show the same thing? I have a feeling if I did remote session with you, I might be able to help you better.

Andy

[flachance]

So we noticed that even when connecting with Remote client to GW2, it looked like traffic was still going via GW1.

It looks like maybe Secondary Connect is enabled by default. So on all our gateways we added this in trac_client_1.ttm to make sure Secondary Connect was disabled and that if we connect to GW2 it doesn’t try to go via GW1.

                :enable_secondary_connect (

                        :gateway (

                                :map (

                                        :true (true)

                                        :false (false)

                                        :client_decide (client_decide)

                                )

                                :default (false)

                        )

                )

So now when we connect Remote Access to GW2, it doesn’t go to GW1 but other than the Tunnel Test connection we see nothing in the logs of GW2. I think tunnel test connection works because it uses the public IP of the gateways but anything for internal IP doesn’t seem to make it to GW2.

Our setup is like this one

If in this case the VNET would be 10.0.0.0/16. Does the Office mode range needs to be part of the VNET? Like 10.0.20.0/24? Currently we have an office mode range outside of the VNET 192.168.137.0/24

[flachance]

just tried to change the office mode range to be inside the VNET and it made no differences

[Parauser]

I believe we have a similar issue.    Our checkpoint gateways  connect to an azure vwan hub over an ipsec tunnel and we cannot get any traffic to NAT and pass over the tunnel to any resource.   It has been open since December for us.    Checkpoint has shown very little concern here leaving us with a firewall that cannot pass any inbound traffic.    They have engineers look at it (each one starts over from scratch) and they all arrive at the point and say "it should work" but then don't actually take it to the next step to find out why it doesnt work.

I would not recommend Checkpoint in Azure.

[the_rock]

Hey there, I can try help you here. First off, I know its annoying having to explain it from scratch, but give me some basic details. What does capture show? Traffic leaves CP, but never gets to Azure side or something else? Did you guys do any basic debugs at all, what about logs? Im happy to do remote session to see if we can make some headways. You are welcome to message me privately.

Andy

[flachance]

We found the solution for our remote access problem last Friday. Although the client connected fine it was not obtaining the routes. 

we changed the :default value of automatic_mep_topology from true to false in the CloudGuard gateways trac_client_1.ttm file and it started working. Could be because of the frontend load balancer but I don't know.

we also had a hard time getting the site-to-site vpn going bewteen our on site Checkpoint and the one in Azure. These two SK have helped. sk32648 and sk102712.

[the_rock]

For remote access, did you make sure all the dns settings are correct from the gateway properties? Yea, that .ttm file, seems like it has to be changed sometimes, which is pretyt annoying. Here is a video that works so well for vpn setup between CP and Azure...follow this and never an issue.

Andy

IPSec Tunnel between Check Point and Azure - YouTube

[RickyDan]

I'm having an issue with CloudGuard remote access as well. Tunnel test traffic is failing with "According to the policy the packet should not have been decrypted" and I can't understand why. The implied rules for allow control connections are on and office mode is setup but vpn client disconnects after approx every 30 seconds. I tried solutions in sk44075 and sk106853 but nothing works so far.