Multiple External Interfaces for vSec on Azure

[Neil_Cav]

Hi,

Does anybody have any experience in creating multiple external interfaces for a vSEC in Azure? I'd like to have the ability to have multiple external ip addresses to NAT to numerous backend services. I can successfully create a second interfaces as per the article: How to add a network interface to a Check Point Security Gateway in Azure 

The interfaces works with a public IP, but only if I change the default gateway to point to it. So I have:

Front end subnet: 10.0.0.0/24 - interface: 10.0.0.4. Azure GW: 10.0.0.1 (public ip assigned in azure)

Back end subnet 10.0.1.0/24 - interface: 10.0.1.4: Azure GW: 10.0.1.1

front end subnet#2: 10.0.3.0/24 - interface: 10.0.3.5: Azure GW: 10.0.3.1 (public ip assigned in azure)

Web server subnet: 10.0.2.0/24 

web server #1 address: 10.0.2.5,  web server #2 address: 10.0.2.6

Default route via front end subnet - 0.0.0.0 via 10.0.0.1

So i'd like to be able to NAT from one public IP addresses used in front end subnet 1 to web server 1 and another NAT from front end subnet #2 to web server 2.

I can create NAT rules for the two web servers, but I can only connect to them when I change the default route, so I can connect to web server #1 via the public ip only if the default route is pointing at the the Azure GW for the subnet for the public IP for that interface. I suspect it's because the traffic is coming via one public IP address, but routing out via another (following the single default route).

Is there a way to do this with PBR?- so that any traffic originating from one interface is replied to on that same interface (kind of overriding the default route).

Or is there an easier way to use two public IP's on a vsec in Azure? I've tried adding multiple IP's on a single interface from inside Azure, but I can't see any traffic arriving on the second IP.

Thanks,

Neil.

[Arnfinn_Strand]

Hi.

The easiest would be to use secondary IP's for the GW's external NIC.

I have tested this a few months ago and when I had a NAT rule with the secondary private IP as Orginal Destination the GW would listen to it,and get the traffic destined to the secondary public IP.

If you don't use NAT (ie. hosting Mobile Access portal on the secondary IP) you would need an interface alias in Gaia for the secondary private IP for the GW to listen to it,and get the traffic destined to the secondary public IP.

AFAIK secondary IP's would likely be a problem if you have a GW cluster. Not sure if this is supported.

An alternative solution is to use Azure load balancer that "owns" the public IP's.

Arnfinn

[Neil_Cav]

Hi,

Just as I got your message I managed to get it working with the secondary public IP on the primary interface following a similar thread on here about a vSec on AWS - the principles of NAT on AWS & Azure seem almost the same, that the platform does the NAT of the public IP before it gets to the firewall.

I added the secondary private IP as an alias in network interfaces in the Gaia web interface. Seems to work a treat. 

Thanks.

[Jeroen_Demets]

I've used the alternative solution twice now: put an Azure Load Balancer in front of it. Our customer wanted multiple websites reachable over https. You can create 1 Azure Load Balancer and then create multiple frontend IP configurations (thus getting multiple public IP's) with port NAT forwarding towards the external nic of your vSEC gateway.

Then you need NAT rules again on your vSEC gateway. You have to make them manually and the destination is not your vSEC firewall object but a new one that you have to create with its private external IP-address (for example 10.0.1.10). And of course a firewall rule allowing that port to your firewall.

The vSEC firewall object will have a public IP in its general tab and that won't work with the NAT rule.

It's some work with this 2-times port NAT but it's what is presented in sk109360 and it works.

Using secondary IP's I fear you'll need a lot of them if you have more webservices to offer and don't know how good that is for stability/support.