- CheckMates
- :
- Products
- :
- CloudMates Products
- :
- Cloud Network Security
- :
- Discussion
- :
- Re: Site-Site Tunnel between Azure Gateway and On-...
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Site-Site Tunnel between Azure Gateway and On-prem CP Gateway
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?
Blason R
CCSA,CCSE,CCCS
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Blason R
CCSA,CCSE,CCCS
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
![](/skins/images/6980CBA140F726D3EF221370390D7B61/responsive_peak/images/icon_anonymous_message.png)