Azure 101: Networking Part 1
Welcome back to the Azure 101 series. In the previous blog posts, I covered two of the most commonly asked for topics from customers: Governance and Monitoring. These topics cover a number of services within Azure and so I wanted to make sure that all of you at the very least understood what those services were and through a simple video demonstration how they worked. This blog series is not meant to go into much depth as there are many other training mechanisms available to go into depth about a specific service and for some of you, you may actually have access to a Cloud Solution Architect like myself that can help teach you everything that you need to know.
In this blog post we are going to continue talking about some the these services that almost all customers should be aware of as they are either designing, architecting or potentially deploying applications and systems into Azure, by focusing on Networking. Some of you might be thinking that this particular topic is not going to be of any interest to you, but I assure you, I have run into very few customers who have not needed to use at least one of the many networking services that are available. In fact, if you are deploying Infrastructure as a Service (IaaS) based systems or deploying a system that requires any kind of Hybrid connectivity, then networking is going to be of extreme importance.
This is a very hefty topic and there are a lot of available services within Azure to use, so like I have done with the Monitoring blog post, I will be breaking this one up into two parts. In this one we will focus on the basic networking infrastructure that you will be laying down to allow for devices to talk or not talk to one another. In the second one, we will talk about some of the networking devices that are available for use from Azure. Let’s get started with a list of these basic foundational networking services that I will be demonstrating in this particular blog post:
- Virtual Networks & Subnets
- User Defined Routes & Network Security Groups
- VPN Gateways
- Azure Firewall
All of these services can be used to make up what your network would look like within the Azure regions and then can provide both private and public access to resources or devices that exist within.
Virtual Networks & Subnets
Everything begins with the Virtual Network. You do not have the ability to create Virtual Machines in Azure without there being a Virtual Network to place it in. You do not have the ability to connect to your On-Prem DataCenters for Hybrid traffic to flow to without there being a Virtual Network for the VPN connection to talk to.
NOTE: The only reason for not needing a Virtual Network in your Azure subscription, is if you are developing or deploying a Native Cloud application that is leveraging all Platform as a Service based Azure services and you do not require any level of private connectivity.
A Virtual Network is your basic networking infrastructure where you segment your customer defined private IP ranges (CIDR), where these segments are called Subnets. Once the network has been defined and deployed within Azure, networking traffic using an IP within the defined CIDR ranges can flow openly between any devices that those IPs have been assigned to. We will talk about the devices that can be placed into Virtual Networks and Subnets in Part 2. These Virtual Networks are not just self-contained networking pockets, they are also connection points for you to provide a much larger environment for your enterprise to use.
For example, the Virtual Network is the entry point for one or more Virtual Private Network (VPN) connections to other networks outside of Azure, such as your On-Prem DataCenters. In addition, you can also connect multiple Virtual Networks together across multiple Azure regions to provide you with a Software Defined or Cloud Defined Geographically distributed network and this is just the beginning of what you can do. We will take a look at how you can control and secure this Azure based network traffic in the next section.
So with that, let’s take a look at the VNet interface within the Azure Portal
[embed]https://vimeo.com/293448043/9da2033e4d[/embed]
User Defined Routes & Network Security Groups
The next area to discuss is the two features that are used within the scope of the Virtual Network that allow you to control and secure the traffic that is flowing in and out of your Virtual Network and these are called User Defined Routes (UDR) and Network Security Groups (NSG).
A UDR is nothing more than a flat table of Next-Hop based routes where you define the source type of traffic and source endpoint and then specify what it's next hop our route should be. The most common use case of this is for traffic coming into a public endpoint may be routed to a virtual application for Intrusion Detection/Prevention services, before going to the actual intended web/application server. So the UDR is how you will control traffic within the scope of your VNet, because UDRs are directly tied to your virtual networks as you saw in the video above.
A NSG is flat table of stateless firewall rules that can be placed on either a NIC card within a Virtual Machine or Virtual Appliance or it can be assigned to an entire Subnet. You can actually layer NSGs on top of one another to provide a more secure architecture for certain devices within a Subnet, where as other can be left more open. A typical NSG will require the following pieces of information:
- Name
- Priority
- Source IP Range
- Source Port
- Target IP Range
- Target Port
- Traffic Direction (Inbound/Outbound)
- Allow/Deny Action
Both of these services can be managed separately, but as you saw in the video on Vnets, they are directly applied to them. So with that, lets take a look at each service individually:
[embed]https://vimeo.com/292861646/70f401936b[/embed]
Virtual Private Gateways
The next area of networking that I want to discuss, is Virtual Private Gateways and it is these combined set of services that allow you to provide traffic flow to/from your Virtual Network and any external network, such as your On-Prem DataCenter. There are three different kind of Virtual Private Gateways that are supported with two of them going across the internet through an IPSEC tunnel where as the last one requires a physical circuit between Azure and your external network there by ensuring that the connection and traffic flow is truly private.
No matter which version of the gateway you plan on implementing, there are three resources within Azure that you will need to implement and then connect to one of your Virtual Networks. The first is the most important and that is what is called a "Gateway Subnet". This is a specialized Subnet within your Virtual Network that can only be used for connecting Virtual Private Gateways to a VPN connection of some kind. Only one Gateway Subnet can be created per Virtual Network, but assuming you provide the Subnet with enough of an IP range, than that single Subnet can be used for multiple VPN connections.
The last two resources that are required are the Gateways themselves, the Local Gateway and the VPN Gateway. The Local Gateway is where you define the configuration of your external network's VPN access point with the most important piece being the external IP of that device so that Azure knows exactly how to establish the VPN connection. The VPN Gateway is the Azure resource that you tie into your Gateway Subnet within your Virtual Network. Once you have all three items configured and the connection has been made, then traffic should flow.
Now, I mentioned above that there are three different kinds of Virtual Private Gateways, but I never really mentioned what the main differences are:
- Point to Site - This VPN connection will run through an IPSEC tunnel over the internet. The endpoints will be a software defined VPN connection such as you would install on your laptop and then still connecting to a VPN gateway within Azure. This allows for a dedicated connection to Azure from your external network and is great for allowing your developers or contractors access to Azure when necessary.
- Site to Site - This VPN connection will also run through an IPSEC tunnel over the internet with endpoints being your external network's VPN device and the VPN Gateway within Azure.
- Express Route - This connection runs over a dedicated pair of physical circuits that will connect your external network to Azure. THis can be done through a number of different approaches depending on how your external network is setup and can be implemented using a large list of supported network vendors. See the document list below for more information.
So with all of this information as a starting point, let's take a look at how all of these pieces are plugged together within the scope of Azure:
[embed]https://vimeo.com/293569694/c1825bf84d[/embed]
Azure Firewall
The last area of networking that we should discuss in this blog post is the brand new service, Azure Firewall. You might be a little confused here if you have read all the way through this blog post, because you might remember me describing the NSG as a stateless firewall that gets applied to Subnets or NICs. So what exactly is an Azure Firewall and how is it different from the NSG?
The official statement from the Azure documentation is the following:
Azure Firewall is a managed, cloud-based network security service that protects your Azure Virtual Network resources. It is a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability.
As you can see from that statement, there are definitely some differences between the Azure Firewall and the NSG, but what are the major ones?
- Stateful Service
- Not applied to a single NIC or Subnet
- Highly Available and Scalable based on demand
- All network filtering rules can be applied across multiple subscriptions and virtual networks
- White Listing capabilities for outbound HTTP/S traffic based on FQDN
Lets' take a look now at what the service looks like within the Azure Portal.
[embed]https://vimeo.com/293454308/73e41e2adb[/embed]
Conclusion
As I stated at the top, the Azure Networking set of services are vast, so this set that I have provided here are only the first set and are primarily focused on networking infrastructure, not specific device types. In the second part of this blog post, we will start focus on specific networking devices available within the scope of Azure, such as the different types of Load Balancers, and Domain Services like Azure DNS and Azure Traffic Manager. We will also spend some time talking about how you can provide public endpoints for either individual VMs or Load Balancers within the scope of your Virtual Network.