cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Highlighted

CloudGuard Azure with Express Route connectivity

Hi CheckMates gurus

I have to design and implement a CloudGuard Azure cluster for one of my customers and I am struggling to solve what seems like an impossible task, so I'm asking for your help, maybe someone had this problem already and there is no point for me re-inventing the wheel. (Or maybe I don't fully understand how Azure works and in fact there is no problem). Here are the details:

 

- Customer has an Azure environment up and running, with 6 vNets deployed in the UK South region and communicating one to the other via vNet peering. There are between 2 and 10 subnets defined in each vNet

 

- They have also an On-premise deployment, in a hosted environment, linked to Azure via a 1 Gb ExpressRoute link (going to 2Gb early next year)

 

- Traffic between the On-premise systems and the Azure vNets is controlled via a 5800 cluster deployed in the hosted environment.

 

- As far as I know, they have not yet implemented any User Defined Routes, relying only on the systems default routes and the routes injected in the vNets by the Express Route Virtual Network Gateway

 

- Security in the Azure environment is configured for most of the subnets via Network Security Groups.

 

- I am supposed to deploy an Azure CloudGuard cluster to control outbound traffic between some of the subnets (initially two, one in a Production vNet and one in a Development vNet) and the Internet. As per the training material and the various SKs dealing with the Azure CloudGuard deployment, this can be achieved by creating UDRs for those subnets, with a 0.0.0.0/0 default route forcing the traffic through the cluster.

 

And here is where the problem appears, as by doing this I assume (right , wrong, I don't know) that I will kill the traffic from those subnets to the On-premise systems  through the ExpressRoute circuit. As per Microsoft Virtual network traffic routing article:

 

“If multiple routes contain the same address prefix, Azure selects the route type, based on the following priority:

  1. User-defined route
  2. BGP route
  3. System route”

so the 0.0.0.0/0 route in the UDR will have precedence.

Initially I thought that I can solve this problem by adding some more specific routes for the On-premise networks in the UDRs and have the Express Route gateway configured as next hop, but again, according to the same Microsoft article, this is not allowed:

 

You cannot specify a virtual network gateway created as type ExpressRoute in a user-defined route because with ExpressRoute, you must use BGP for custom routes.”

 

So my question is how can I have an Azure subnet send all Internet-bound traffic to the CloudGuard cluster, while continuing to send traffic destined to the On-premise networks via the Express Route link?

 

I found an SK article - sk110993 Securing ExpressRoute traffic in Microsoft Azure – that is somehow related to this customer environment, but implementing it would mean that all traffic  between the particular Azure subnets having a UDR table defined and the On-premise networks will be have to traverse the CloudGuard cluster and will be “firewalled” twice (as mentioned above, there is already cluster in the hosting datacentre controlling traffic to Azure)

 

Do you know is there is any other solution to this conundrum? Would having the CloudGuard cluster peered via BGP with the ExpressRoute Virtual Network Gateway eliminate the need for UDRs (but how can you force traffic to the CloudGuard cluster without having a 0.0.0.0/0 route added to an UDR?)

Or even after adding the 0.0.0.0/0 route via the UDR, more speciffic routes injected by the Express Route virtual network gateway will still be present in the routing table associated with that subnet and in fact there is no issue to worry about?

 

I would very much appreciate some ideas / thoughts about this, as I need to give the customer an update on the progress of my design fairly soon…

Thanks and best regards,

Valeriu 

3 Replies

Re: CloudGuard Azure with Express Route connectivity

Hi Valeriu ,

do you have a VM in one of the subnet you´d like to change the default route ? If so, you can check the effective route on the NIC of this VM. Check if you have specifc routes for the On Prem networks (injected by the Express Route). if so, you could change the default route via UDR and the traffic to the On Prem networks is still routed via the Express Route.

We did a on Prem Connection via a MS VPN gateway, and in this case the VPN gateway has injected the On Prem networks, not sure if a Express Route connection is doing the same.

Matthias

0 Kudos

Re: CloudGuard Azure with Express Route connectivity

Hi Matthias and thanks for your swift reply...

Apparently VPN VNGs and Express Route VNGs are treated differently in Azure when it comes to using them as next hop for a User Defined Route

And yes, the Express Route gateway should inject te routes for the On-Premise networks, otherwise the customer's Azure VMs couldn't communicate through the Express Route. (As mentioned before, they have not created any UDRs and routing works based on the the routes having "default" as source, being them System / Azure created or BGP / ExpressRuoute created.

(not a very fortunate term "default" used by Microsoft when describing the source of a route in the routing table associated with a subnet... Anyone comming from a "normal" networking environment will think "default" equals 0.0.0.0//0)

Best regards,

Valeriu

Re: CloudGuard Azure with Express Route connectivity

Me again... I think I got it, after deploying a Cloud Guard cluster in Azure and going through the troubleshooting steps...

The key words in the first statement quoted from the Microsoft article are "the same address prefix"...

So the 0.0.0.0/0 route in the UDR pointing to the primary CloudGuard cluster internal interface will actually "kill " and make invalid the system default route - 0.0.0.0/0 next hop Internet - generated when the sunet has been created... All other routes - BGP, vNet peering - will remain in place, will remain active and traffic for the On-premise networks will continue to use the Express Route path...

False alarm... 

Valeriu

0 Kudos