Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
israelsc
Contributor
Jump to solution

Use the same public IP for incoming and outgoing traffic for a server - VMSS Azure Check Point

Hello CheckMates community!

I would like to check with you if it is possible to fulfill a requirement that a customer sent us.
Our customer has some Azure VMSS firewalls with R80.30 and JHF GA Take 237 patch (https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_VMSS_for_Azure/Content/Topics-Azure-V...).

The customer needs to publish a server where a SFTP service (VM Server hosted on MS Azure) will be exposed with an inbound public IP (managed with the Azure External FrontEnd Load Balancer) and the customer needs that the same IP can be used for the outbound to the internet for that server, i.e. outbound to the internet using that same public IP (Same inbound and outbound public IP for the server in Azure).

Is it possible to do this?
I did not find any documentation related to this.

If not, is there any alternative that can be done on the Azure side?

I know this seems more of an Azure requirement, but I want to see if with Check Point something can be done.

I'll keep an eye out for your ideas.

Greetings to all!!!

 

0 Kudos
1 Solution

Accepted Solutions
israelsc
Contributor

Hello everyone,

Just to close this topic and mark it as the final solution: we finally discovered that this requirement is not possible with VMSS Firewall because these firewalls do provide an internet output but with a public IP from an active instance within the VMSS, it could be one or another, but not a static IP.
The solution to this requirement is to use an HA Cluster in Azure with a VIP (or using the deployment option with Multiple VIP). 
The HA cluster's VIP is a static public IP.

Link: https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Clust...

Best regards and thanks to everyone for the support.

View solution in original post

0 Kudos
7 Replies
natanelm
Employee
Employee

Hi @israelsc,

As you correctly pointed out, our official architecture uses the public IP of the GW instance for the outgoing traffic.

On Azure LB, there is an option to configure outbound-rules on the external LB, but it is not officially supported and I have never tested it.

I hope this helps.

Thanks,
Natanel

0 Kudos
israelsc
Contributor

Hello @natanelm thanks for your reply!!

About this option you mention: using outbound-rules in the external LB, I have a question

-Are any additional Azure resources required, in addition to the resources already preset by the Check Point VMSS template?
I mean, in addition to the Internal LB, VMSS Gateways, External LB, Public IP for VMSS Gateways instances, is any additional component required?

-Could you tell us a little bit about the outbound-rules?
-The Original Source IP would be the Backend IP of the origin server and the Translated Source IP would be the public IP of our choice? is that correct or how works outbound-rules in Azure?
Sorry, I know this a Azure likely question but it will help a lot if you answer me and help us.

We hope you can help us.
Best regards.

0 Kudos
natanelm
Employee
Employee

Hi @israelsc,

I'm not familiar with this Azure's feature, so I cannot promise anything, but based on the documentation, this is what I understand:

  • No, you do not need any additional Azure resources to use outbound rules, apart from the ones already preset by the Check Point VMSS template. You just need to configure the outbound rules in the load balancer settings.
  • Outbound rules allow you to control which virtual machines are translated to which public IP addresses, which protocols to provide outbound translation for. You can also use a public IP prefix directly with an outbound rule to scale your outbound NAT with multiple IP addresses.

Thanks

Carlos_Diaz
Employee
Employee

Hi @Israelc,

I hope this message finds you well. I've been looking into maintaining a consistent address for the connection, and while it may not be possible to keep the exact same address, I believe we can implement a solution that comes very close to what you're looking for.

Here's the proposed plan:

  1. External Load Balancer (XLB):

    • Assign a new IP address to the external load balancer.
    • Add the SFTP port required by your customer to the XLB.
    • The XLB will balance the traffic to the firewall pool, and the firewall will then redirect the traffic to the server.
  2. Outbound Traffic:

    • Set up a NAT gateway in another subnet with a static address.
    • This NAT gateway will handle outbound traffic.
    • Configure the customer's firewall to allow access to the NAT gateway for inbound traffic.
  3. User-Defined Route (UDR):

    • On the Frontend subnet, implement a User-Defined Route.
    • Use the customer's SFTP server as the destination address and route it to the NAT gateway.
    • This way, the customer will only see one address for the connection.

I believe this approach should address your concerns.

0 Kudos
israelsc
Contributor

Hello team,
Thanks for your comments and ideas.

In the previous answer, you talk about a NAT Gateway.

  • Is this an additional resource to the ones we already have?
  • Should this resource go with another subnet in the same inspection Resource Group where the firewalls are in Azure?

Regards

0 Kudos
Carlos_Diaz
Employee
Employee

The NAT gw is an adicional resource and it needs to be deployed in a different subnet.

0 Kudos
israelsc
Contributor

Hello everyone,

Just to close this topic and mark it as the final solution: we finally discovered that this requirement is not possible with VMSS Firewall because these firewalls do provide an internet output but with a public IP from an active instance within the VMSS, it could be one or another, but not a static IP.
The solution to this requirement is to use an HA Cluster in Azure with a VIP (or using the deployment option with Multiple VIP). 
The HA cluster's VIP is a static public IP.

Link: https://sc1.checkpoint.com/documents/IaaS/WebAdminGuides/EN/CP_CloudGuard_Network_for_Azure_HA_Clust...

Best regards and thanks to everyone for the support.

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.