Microsoft Azure Hub-Spoke Implementation.

So this is my first post  about implementing a Hub-Spoke model in Azure IaaS.

From my point of perspective this is the only way to go about implementing a scalable infrastructure that's cost effective and won't lock you up with complexity later on.

So lets talk about a network implementation called Hub-Spoke. The goal of this model is to have your main generic services centralized and accessible in the Hub (it's own dedicated environment with of course a dedicated HUB network).

So what would we define as a generic service?

• NVA's (Network Virtual Appliances) Barracuda NextGen or CloudGen firewalls for instance, WAF's (Web Application Firewalls)
• Active Directory Domain Controller(s)
• Remote Desktop Gateways
• SecOps appliances such as NextPose or Qualys.
• Management, Instrumentation and Discovery Services.
  
• etc.

I'll continue now with describing a basic setup.

The first basic step is to define your HUB's networking needs. I'd recommend using only 1 vnet per HUB don't get creative it doesn't benefit doing anything more.

Connectivity requirements:

• VPN Gateway?
• ExpressRoute Gateway?
• Or 3rd party appliance? 

My personal recommendation would be to go with a third party appliance to manage most of your networking layer 3 needs and combine it with for example a service like the express route in Azure. Depending on your location this is the best way to guarantee low latency networks. (if you're in a country like the Netherlands express route is only needed when entertaining legacy applications that aren't secure enough yet to connect via the internet. Loosely coupled is the way to go!)

Why not a Native solution? Simple, what if you decide to leave Azure? Wouldn't you want to be able to reuse key technologies without having a lock-in with you're current cloud providers NVA solution? Again this depends on the kind of scenario you're in.

So I'm used to work with Barracuda. (they were the one of the first to have a NVA available in the Azure Market Place)

And in line with cloud strategy they are the most cost effective solution giving the most worth for your operational budget.

On the other hand, they are also cost effective versus other vendors like F5 (Cool stuff but very expensive and you can do stuff cloud natively which negates the technological benefits and the extra cost of F5, this is personally where i think Barracuda makes a stronger business case.)

 

Virtual Network Requirements:

• 3 dedicated IP spaces starting with 2 /22 networks and a /28 for the gateway subnet (YES /28 not smaller.) minimal. 

Why three? Let me elaborate this, one space that's unique for your Azure Gateway. Don't have a need for it yet? Still reserve it for future use and implement it anyway. Just don't provision the Network Gateway Resource yet.  (The azure Gateway concept is going to be changed soon! I will revise the document as needed with the new concepts as Microsoft announces them)

The second we will use for NVA's (DMZ / Semi-trusted). In this area we prefer to use as minimal routing (Azure Route Table) as possible and let the fabric handle as much as possible when it come's to routing.

And last but not least the third IP Space will be used to implement a trusted subnet for your services that you will be hosting. For example, domain controllers that spokes will want to talk to.

Motivation:

Reasoning behind using 1 virtual network with 3 IP spaces is simple, the Azure Networking layer is a very different beast then your used to. say bu-bye to traditional Routing, Mac addresses are funny things that don't really do anything anymore, adding custom routes on your machine won't work , oh and it's not really layer-2 or 3 but something else and a plethora of other reasons which i won't divulge here.

You can use Route-tables to force network traffic to a NVA. And you can restrict subnet access by using a NSG (Network Security Group) These are just the examples that Microsoft Azure provides us to compensate for this change in networking behavior.

Microsoft did something that's very annoying but also very logical. They simplified a lot in networking for you, it just takes an effort to understand it if you come from a traditional networking background. (my 2 cents: Don't ask how they do it just accept they do it for you!)

Spokes,

Spokes are the consumers of services provided from the HUB and can run the business workload(s), they are isolated and even more restricted on a network layer. (let me be clear when I'm talking about a hub or spoke it's a context difference and not a different capability or resource.)

For instance you would want to force all internet traffic towards the hub NVA for inspection. (IPS/IDS/AV/Malware/Etc.)

This way you can safely delegate  the spoke with certain permissions to a business without the worry that they might open up shop in the spoke with things you rather wouldn't want...

Append Azure NSG's/ASG's with that and you can also monitor and enforce more limitations on your traffic flows.

Connectivity options:

You can connect your spoke with multiple methods to the hub. Depending on your needs it's a different connectivity method but the basics can stay the same.

• NVA VPN 2 NVA VPN (i wouldn't recommend this)
• Expressroute Connection (i wouldn't recommend this either)
• VPN Gateway Connection 
• VNet Peering (Recommended)

Network Virtual Appliances:

So why wouldn't i recommend putting a NVA VPN in the spoke? You have one in the hub, licenses are expensive the cost of using a propitiatory solution to host your network connectivity is expensive and redundant.  But what about the lock-in? The constant trade-off is the amount of effort vs cost in the cloud.

So how do we connect those spokes to the hub? The easiest solution is to use VNET Peering.

Implementing Azure's native VNet peering is cheaper and a lot faster, it also reduces the amount of maintenance needed for admins. And if you need to move to a different cloud like Amazon it has the same easily implemented methodologies, same principles different resources names. (and yes a little different network layer :-).

Express route Connection:

This should only used to connect to an hub. Al do a standard azure Express route circuit allows for X connections (check out Microsoft documentation on it's limits). You would have to deploy an azure express route gateway and a expressroute connection to the subnet to get the routing capabilities and connectivity to the hub.

It's more complex to maintain and introduces routing complexity in the spoke(s), also you would have to match the circuit configuration with the desired bandwidth needs which bring another monthly cost factor with it.

So this is only sensible in a scenario to connect your hub to your private data center.

VPN Gateway:

Depending on your bandwidth needs this could be a fine cheap solution. You could connect the VPN gateway in azure with each other or directly connect to the NVA. Keep in mind that using this method requires 'forced tunneling'.

VNet Peering:

This solution provides the most excellent routing capabilities within Azure itself. It's got a high throughput and also runs fully on the Microsoft Azure data-center backbone. And as such is isolated and protected.

An VPN Gateway with a Site-2-Site VPN also runs on the public backbone of Microsoft, but has less guarantees when it come's to performance (latency and throughput penalties).

In my next post i will introduce a detailed picture design of how a hub with a spoke could look and will start sharing the first nugget.

Also I'll post another nugget of experience in using a NVA with a VPN overlay to simplify your networking needs!

Which will be a Virtual Network with Sample RouteTables and NSG using a CICD pipeline for the HUB.

Keep checking this site for new information!

Why CICD? Because you want consistency, speed and re-usability with a push button!