Site-Site Tunnel between Azure Gateway and On-prem CP Gateway

[Blason_R]

Hi Team,

Curious to know if Azure GW can be managed trough On-prem Management server? I guess it should because eventually it would speak with gateway on CP Ports. 

As well as can we configure Tunnel between Azure & On-prem CP again managed with Onprem Management server? Or is it better to have Separate Mgmt server on Azure?

[Tommy_Forrest · Accepted solution]

You can certainly manage Azure based gateways on prem.

Couple of things.

Make sure your Azure gateway policy is not in the same CMA as your local VPN gateway policy.  It can cause you some heartburn, though I don't recall all of the details (did this about 3 years ago before moving to Express Route) think it had something to do with conflicting domains.  But don't quote me on that.

If your management is behind a NAT, then you'll want to create some dummy objects pointing back to your CMA(s) using their externally assigned IP address.  This is so that you have an object to assign the gateway for logging and such.

In my experience, it was SUPER stable.  In the 18 months we ran over VPN to Azure it was -rock- solid.

Also, don't deploy a Virtual Machine Scale Set if you're doing VPN on those gateways.  Stick the old school cluster build.

[Tommy_Forrest]

Oh yeah - and I couldn't find an edit button) -

To be clear, we managed the gateways via SIC over the internet, not over the tunnel itself.  Hence the dummy objects.

[Blason_R]

Correct and that can be achieved this and policy will be pushed over public IP address from my on-prem mgmt server and I need statically NAT the Mgmt server and specify the public IP in mgmt NAT option.

Thanks for the help appreciated

[mdjmcnally]

Where have the Management Server behind a Check Point Gateway that then has a VPN Tunnel to another Check Point Gateway that also managed by the same Management Server then use the $FWDIR/lib/crypt.def to exclude traffic to the Remote Check Point as otherwise will find that the traffic attempts to go over the Site to Site VPN.
That's helpful to do whether the Remote Check Point in Cloud or a Physical Box.
That or have the VPN's go via a separate Gateway that on a Separate Management Server.

[Tommy_Forrest]

That shouldn't be an issue because your management traffic should be hitting the gateway's public IP's.  Not the internal IP's that are in the encryption domain.

[mdjmcnally]

Check Point automatically adds the remote gateway IP into what it see's as the Encryption Domain.
Thus if the Management Traffic goes via a Check Point Gateway that has a VPN to the Gateway that want to manage then it see's it as part of the VPN Tunnel and end up having to exclude using the crypt.def file.
I know because actually had to do this to ensure that the traffic to the Remote gateways didn't try and go over the VPN Tunnel, and yes that was going to the External Interfaces of the Boxes.

[Tommy_Forrest]

In my case, none of this was necessary.

Our MDS will attempt to talk to the Azure gateway via the internet.  Which is a separate set of gateways (and CMA for that matter) than what the VPN traffic will traverse.

[mdjmcnally]

That's because as you said your Management Traffic is going via a different Gateway to your VPN.
In my post then was saying when it DOES go via the same gateway as the Origional Posters query talks about VPN to an OnPrem but doesn't state that this is seperate to how the Management will go out.
I designed afterwards discovering this so that the VPN and Management traffic terminate at different Gateways so like you I don't have to edit the crypt.def however isn't clear if same or different for the Origonal Poster hence why posted that may need to look at that if the same gateway for VPN and Management.