Understanding Azure Networking: A Comprehensive Guide

by Bastiaan Van Den Bussche, Cloud Solution Architect, Hybrid Datacenter | DexMach

Introduction

Azure Networking, that’s saying goodbye to Wireshark, Tagged and Untagged VLAN’s, Routers, Switches, Cat5 and Cat6. We now talk about Virtual Networks, Subnets, Route Tables and NSG’s. This blog is here to help you understand the core basics and highlight some pitfalls of the new technologies, brought to us in Azure. Network, whether virtual or physical, is still at the core of our digital business, allowing us to talk to people and to systems. This medium is almost everything used during a breach, making it a key component to triple-check every day.

Azure Networking

Before we can deep dive in the full picture, it’s essential that we understand some key elements that are part of the Azure Networking Landscape. Allow us to quickly walk you through.

A Virtual Network is a networking range and network name that is defined in Azure, where two things are essential. On this level, DNS and Peering are configured. 

A subnet is a part of a virtual network, either equally as big or smaller, where three things are important. On this level, Routes, Network Security Groups and Private Endpoint Policies are configured.

A route table is a configuration item on a Subnet, defining what the next hop will be for a certain network range.

A Network Security Group is a small little ACL that lives either on the Network Interface or on the subnet, filtering traffic you defined in the list. This component is also used for Traffic Analytics or NSG Flow Logs.

A Private Endpoint is a network interface, attached to a service you are using in Azure. However, instead of accessing that service publicly through Azure mechanisms, a private endpoint allows you to keep the traffic private and disallow public access to the resource.        

Hub and Spoke Model

Now that we understand some core principles, it makes sense to continue and explain the Hub and Spoke model, as presented in the Well Architected Framework by Microsoft.

The hub and spoke model allows for scalability and centrally managed, shared network components. Whilst Azure is built to be super-quick, scalable, manageable, and probably some more, it can be a big risk and cost bleeder to not consolidate shared resources if they are intended for a shared purpose. Please see the below drawing of a very basic hub and spoke model. In essence it allows for segregation of duty, splitting up different environments.

The layout does not change if you either have a very big environment, multi-region footprint or if you self-manage your firewalls. It should all have a place in this bigger puzzle.

Now, we need full focus for the next couple of minutes because the following bit will deep dive straight into the core of Azure Networking.

As simple as the above drawing might seem – we would like to share three common mistakes we see in the field.

1.???????? Asynchronous routing.

2.???????? Private Endpoint Policies.

3.???????? Transition to a Network Mesh.

Asynchronous Routing happens when the route from your source to your destination is different than the route that your destination has to your source. Azure works with 3 types of routes. System routes, BGP routes and User defined routes. They have a hierarchy that is explained here, but this mechanism is at the bases of these problems.

In the below example, all is configured correctly for spoke 1, hence there is no routing problem.

The path from the HQ at the bottom, over the VPN gateway, through the firewall to the spoke, and all the way back is the same. This is because the route propagation on Spoke 1 is turned off, so routes from the VPN Gateway are not injected in the Route table of spoke 1.

However, when we look at the routing for spoke 2, a mistake was made. The path from HQ, over the VPN gateway, to the Firewall, ending up in the Spoke is different than the path back. Traffic back is routed from the spoke, directly to the VPN Gateway, skipping the firewall. This is because the Route propagation is set to true, so VPN Gateway routes are injected in the Route table.

Private Endpoint Policies is a strange default behavior where private endpoint by default do not follow the route table or the NSG that is applied to the subnet where the private endpoint is located. When you go to a Virtual Network in your environment, pick a subnet and click on it. In the below example, click on “default”.

A setup and config window pops open where you can configure the subnet parameters. If you scroll all the way to the bottom, you will find the “Network Policy for Private Endpoints”.

This is disabled by default and thus your private endpoints are not following the route table nor are they secured by the NSG of the subnet. Be careful when you change these settings because it immediately applies to all Private Endpoints in the subnet.

?

Transition to a network mesh is a risk that one should always be careful of. A Hub-spoke model implies that only the hub can peer with the spokes, and never should there be any contact between spokes directly. However, in an ever-changing landscape, where application owners are heavily involved, it might happen, for whatever reason, that peering exists between two spokes. This is unfiltered and unmonitored, which can never be the case.

The below resource graph query can help you quickly identify the Virtual Networks having more than one peer. Only your hub should have more than one peer.

resources
| where type =~ 'microsoft.network/virtualNetworks'
| mv-expand peering=properties.virtualNetworkPeerings
| summarize count() by name        

Conclusion

While a lot of networking mechanisms are hidden and managed by Azure, us Cloud Architects still decide where packets flow. However, as the above breakdown may have highlighted, it’s not without risk. Incorrect configuration adds additional attack surface, and misconfigurations can come from all directions. Even so, this foundational network explanation is only a tip of the iceberg. In a DexMach cloud foundation, we identity 5 pillars to have a correct Azure Landing Zone. They are Identity, Alerting, Network, Management and Governance. Each of those pillars requires an industrialized solution. They all have their pitfalls and configuration mistakes are always around the corner. Reach out if you are seeking additional guidance with any of these pillars!