I

Overview

Recently I gave a talk around Azure enterprise networks and became clear very quickly, is just how vast the topic really is and having just one session, was just not enough.
So, the idea here is to take the time to go through Azure networks and break down the topics surrounding it.

A key thing to remember, before diving into these topics or especially when you want to start building your Azure infrastructure, you need to plan it all out on paper first. So, whip out your crayons and draw how you want your environment to look and function before clicking create and building.

Resource Groups

Quite simply, if you have multiple components that make up your environment in the cloud, then best practice would be to group them into a resource group. Reasons for doing this could be departmental, dividing up networking from desktop admins or even separating a dev environment from your production environment.

Some of the key benefits to resource groups are:

    • You can deploy, monitor, delete, update and manage all your resources in one central location
    • You can deploy resources with certain dependencies, thus allowing them to be deployed in a certain order
  • Use Role-Based Access Control (RBAC) to provide access control
  • With the use of Resource Manager Template, you can deploy an entire environment to a resource group using a JSON file
  • With the use of resource groups, you can get an overview of the costs of all your resources inside a resource group
  • You can gain access to a resource group using:
    • Portal
    • PowerShell
    • Azure CLI
    • REST Api

Things to consider when using Resource Groups:

  • Resources inside your Resource groups can be cross regions
  • A resource can only be part of one resource group at one time
  • A Resource group is not an isolated container. Resources from other Resource Groups can still be accessed

How to create a Resource Group

So, I am going to show you really quick, how to create a Resource Group.

  1. First navigate to portal.azure.com and log in
  2. On the left-hand side there is a taskbar, and there you will see Resource Groups (see picture below), click it 
  3. Now that you have clicked Resource Group, the pane on the right-hand side would have changed. You are now in the Resource Group pane. From here you can create a new Resource Group.
  4. To create a Resource Group, click the Add button on the top left of the Resource Group pane 
  5. When creating your Resource Group, there is a purpose for it. For example, to group all your networking resources (and then only assign the networking team access) or perhaps it’s the production environment. So, when giving a name, think of the purpose of the RG and name accordingly.
  6. To create the Resource Group only 3 fields, need to be filled in:
      • Resource Group Name
      • Subscription
      • Resource Group Location

Conclusion

As you can see Resource Groups are a great way to group resources and even if you have a small environment its recommended to get into the habit of using resource groups. That way when your environment grows, you can create multiple Resource Groups and move you resources around to the relevant group.

For a more in-depth overview of Resource Groups, see the link below:

https://docs.microsoft.com/en-us/azure/azure-resource-manager/resource-group-overview

Virtual Networks

A Virtual Network is the equivalent of having your own virtual private datacentre. The difference is you don’t need to procure hardware, worry about cabinet space or cable management. Azure provides that functionality automatically in the back ground for you. And if you have a connection to your on-premise environment (more on this later), you can have both environments communicating seamlessly.

Additional info

Before we move onto the features of vNets, I wanted to take the time to explain some terminology before we dig into the real meat of vNet.

  • Difference between regions and availability zones – In a single region (e.g. West Europe) there can be multiple availability zones (datacentres).
  • What is a CIDR block?
    • Stands for Classless Inter-Domain Routing
    • A method for allocating IP Addresses and IP routing
    • Think of your common network address, 192.168.0.0/24, this is a CIDR block.
  • NSG means Network Security Group

Now onto the key features.

Key features

  • Create multiple Virtual Networks, while still keeping them isolated from each other
  • Connect your on-premise environment to your Virtual Network using a VPN service, like point-to-site and/or site-to-site and ExpressRoute
  • The ability to lockdown your Virtual Network with the use of Network
  • Communicate between Virtual Networks through the use of vNet-vNet peering
  • Filter traffic using Network Security Groups or a Network Virtual Appliance

Limitations

These are limitations that I thought were key, for a more detailed breakdown, see the link below and search for “Networking Limits – Azure Resource Manager).

These limits are per region, per subscription. If you happen to hit a limit, submit a ticket to MS support and in all likelihood they can up the limit for you.

https://docs.microsoft.com/en-us/azure/azure-subscription-service-limits

  • Max private address limit is 16384
  • Virtual limits default max is 50
  • NSG 100
  • The following IP address scopes can be used:
    • x.x.x/8 (16 777 216)
    • 16.x.x/12 (1 048 576)
    • 168.x.x/16 (65 536)
  • The following IP address scopes cannot be used:
    • x.x.x/4 (Multicast)
    • 255.255.255/32 (Broadcast)
    • x.x.x/8 (Loopback)
    • 254.x.x/16 (Link-local)
    • 63.129.16/32 (Internal DNS)

How to create a Virtual Network

  1. Open portal.azure.com and log in
  2. On the left-hand side there is a taskbar, and there you will see Virtual Networks (see picture below), click it 
  3. Now that you have clicked Virtual Network, the pane on the right-hand side would have changed. You are now in the Virtual Network pane. From here you can create a new vNet.
  4. To create a Virtual Network, click the Add button on the top left of the Virtual Network pane 
  5. When creating your Virtual Network, there is a purpose for it. For example, this particular vNet could be the online presence for your on-premise environment. Also, when creating a vNet, probably the most important consideration is the address space. Multiple vNets cannot have colliding address space, it has to be unique.
  6. Provide a name, address space, select a resource group that you created earlier, name for the subnet and an address range.
  7. Azure offers DDoS protection in the forms of a basic and standard option. To get additional information, click the link below. We will go into more detail in a later post.https://docs.microsoft.com/en-za/azure/virtual-network/ddos-protection-overview
  8. Now you have the option to allow a Service Endpoint to access this vNet. If you happen to be using one of the services provided my Azure, then it could be beneficial to allow it access to your vNet. This will allow you to secure your Azure service to your vNet and all traffic remains on the Azure backbone. Examples of services are:
    • Azure Storage
    • Azure SQL DB
    • Azure DB Warehouse
  9. Once done, click create

VPN Gateways

One of the biggest concerns when you are in the process of moving to the cloud, is keeping connectivity to your on-premise environment or even just having the capability to have other networks connect to Azure environment.

Microsoft have tackled this in 3 ways, vNet-vNet, Site-to-Site and Point-to-Site. Each of these options do have a nominal pricing attached to them. See the following article for up-to-date pricing

I am going to delve into each one separately and how to do it.

vNet-vNet peering

As the name implies, you are connecting 2 (or more) vNets to each other. One of the biggest benefits of using vNet peering is the speed and security. All traffic is happening on Microsoft’s backbone and because none of that traffic is internet facing, its highly secure.

Other key benefits are:

Benefits

  • vNet peering can be cross region and different subscription
  • Can be used to create cross-region geo-redundancy and presence
  • Traffic on MS backbone
  • Traffic is secure and isolated

There are a handful of limitations to vNet peering:

Limitations

  • At this point in time vNets are non-transitive.
    • What that means, if vNet B has a peer with vNet A and vNet C. vNet A cannot see vNet C.
    • Now apparently this is on the roadmap but hasn’t been implemented yet.
    • Due to the vNet peering limitations you can run out of peering connections quickly. In these kind of scenarios, you could use UDRs (User-defined routes) to force traffic. This is an entire topic on its own, so check out this detailed article.
  • Although not technically a limitation, but if you want to setup vNet peering between vNets in different subscriptions, you would need to do this via PowerShell

Demonstration

Creating a peer between vNets is really quick and easy. The only prerequisite is making sure that your subnet has a gateway created, which is a simple one click.

  • Log into portal.azure.com
  • Navigate to Virtual Networks
  • Select the vNet you are looking to peer
  • Select Peering
  • Inside the peering panel, click Add 
  • Give the peer a name, select the subscription and the vNet you would like to peer with. There are additional options available which will be situational. 
  • And that’s it, Azure handles the routing, so now the vNets can communicate with each other 


Site-to-Site peering

Site-to-Site was designed to connect your on-premise environment to the cloud. Now technically you could sure Site-to-Site to connect two subscriptions together, it really isn’t necessary with vNet-vNet peering. Also, Site-to-Site are used on environments that aren’t big enough to have an ExpressRoute.

Benefits

  • Used to extend your on-premise network to the cloud
  • Ability to decide connectivity with either Policy-based VPN or Route-based VPN
  • You can have a multi-Site-to-Site setup, but this can only be done through PowerShell. See the follow link for more info.

Demonstration

  • Log into portal.azure.com
  • Click Create a resource 
  • Do a search for Virtual Network Gateway 
  • Select Virtual Network Gateway from the Marketplace and click create 
  • Provide a name
  • Choose the connection type, which in this case will be VPN
  • VPN Type, you can choose between Route-based (allow all traffic) or Policy-based (create a policy to dictate connectivity)
  • Choose the vNet that this will be setup on
  • Create a Gateway subnet address range. You can decide on the size of the subnet depending on the amount of devices that could possibly connect, as long as it’s within the scope of the vNets address pool
  • Create a public IP address. You can choose between the basic and standard option, cost will vary
  • Finally, once all done, click create. NOTE: this process could take up to 45mins.

Once the gateway has been created, follow the steps below to complete the Site-to-Site setup

  • Click on all resources and search by name for your newly created Virtual Network Gateway
  • Click on connections 
  • Click add on the panel on the right 
  • Add a name
  • Choose the connection type, which in this case is Site-to-Site
  • Create a unique shared key. This key will allow both VPN gateways to connect
  • Allocate this resource to a Resource Group
  • Finally, click create.

Once the Site-to-Site gateway has been created, and you have setup the shared key on your on-premise device, then the Site-to-Site VPN will connect.

Point-Site peering

And finally, there is Point-to-Site peering. This is typically used for remote users that need to connect to the Azure network or very small offices. The setup of a Point-to-Site VPN, requires a Virtual Network Gateway and once all the info has been correctly entered, a package is created that you install on a user’s machine.

Benefits

  • Ideal for remote users

Limitations

  • When you create a Point-to-Site connection you need to use a certificate. This certificate needs to be in the following format, Base-64 encoded X.509 .cer file

Demonstration

  • Log into portal.azure.com
  • Click Create a resource 
  • Do a search for Virtual Network Gateway 
  • Select Virtual Network Gateway from the Marketplace and click create 
  • Provide a name
  • Choose the connection type, which in this case will be VPN
  • VPN Type, you can choose between Route-based (allow all traffic) or Policy-based (create a policy to dictate connectivity)
  • Choose the vNet that this will be setup on
  • Create a Gateway subnet address range. You can decide on the size of the subnet depending on the amount of devices that could possibly connect, as long as it’s within the scope of the vNets address pool
  • Create a public IP address. You can choose between the basic and standard option, cost will vary
  • Finally, once all done, click create. NOTE: this process could take up to 45mins.

Once the gateway has been created, follow the steps below to complete the Point-to-Site setup.

  • Click on all resources and search by name for your newly created Virtual Network Gateway
  • Click on Point-to-Site configuration and click configure now 
  • Enter the IP address pool you want to use
  • Provide the name of your root certificate and then enter the certificate data. If you don’t have a certificate, then with Windows 10 or Server 2016, you can generate a root certificate and child certificate. Use the following link. Make sure that the child certificate is installed on the user’s device
  • Click save
  • Once completed you will now have the option to download the VPN client. Run this on the user’s machine and you will be able to connect to the azure network.