Tag: VNET

100 Days of Cloud — Day 11: Azure Virtual Networks (Part 2 — Peering)

Its Day 11 of 100 Days of Cloud, and as promised its part 2 of Azure Virtual Networks.

In the last post I covered creating a Virtual Network, having multiple subnets and also have NSG Rules govern how subnets within the same Virtual Network communicate.

Today’s post is about Virtual Network Peering, or Vnet Peering. This allows you to seamlessly connect 2 Azure Virtual Networks. Once connected, these networks communicate over the Microsoft backbone infrastructure, so no public internet, gateways or VPN’s are required for the networks to communicate.

Overview of Vnet Peering

Vnet peering enables you to connect two Azure virtual networks without using VPN or Public Internet. Once peered, the virtual networks appear as one, for connectivity purposes. There are two types of VNet peering.

  • Regional VNet peering connects Azure virtual networks in the same region.
  • Global VNet peering connects Azure virtual networks in different regions. When creating a global peering, the peered virtual networks can exist in any Azure public cloud region or China cloud regions, but not in Government cloud regions. You can only peer virtual networks in the same region in Azure Government cloud regions.

Once the peering connection is created, traffic routed through Microsoft’s private backbone network only, it never goes out onto the internet.

Naturally, Global Vnet Peering has a higher cost than Regional Vnet peering. Check out Microsoft’s Azure Pricing site for Virtual Networks here, which gives full details of the costs of each.

Benefits of Vnet Peering

The benefits of using virtual network peering, include:

  • Resources in either network can directly connect with resources in the peered network.
  • A low-latency, high-bandwidth connection between resources in peered virtual networks.
  • Use of NSG’s in peered Vnets to block access to other virtual networks or subnets.
  • Data Transfer between virtual networks across subscriptions, Azure Active Directory tenants, deployment models, and Azure regions.
  • Peering of Networks created using ARM Templates or using classic deployment models (Portal/PowerShell/CLI) to each other.
  • No downtime in either virtual network is required when creating the peering, or after the peering is created.

Demo

Let’s dive into a demonstration to see how this works. To do this, I’ll need to create 2 VMs in separate Virtual Networks. I’ll create these in separate regions also. Another thing I need to make sure of is that the Subnets do not overlap.

So I’ll jump into PowerShell first and use this command to create a Resource Group called “Prod_VMs”:

New-AzVM -ResourceGroupName “Prod_VMs” -Location northeurope -Name “ProdVM1” -VirtualNetworkName “ProdVM1” -SubnetName “ProdVM1” -SubnetAddressPrefix “192.168.2.0/24” -SecurityGroupName “ProdVM1” -OpenPorts 3389 -ImageName Win2016Datacenter -Size Standard_B2s -OsDiskDeleteOption Delete -Credential (Get-Credential) -Verbose

I’ll then use the same command with different input values to create the second VM in a resource group called “Test_VMs”:

New-AzVM -ResourceGroupName “Test_VMs” -Location eastus -Name “TestVM1” -VirtualNetworkName “TestVM1” -AddressPrefix “10.10.0.0/16” -SubnetName “TestVM1” -SubnetAddressPrefix “10.10.2.0/24” -SecurityGroupName “TestVM1” -OpenPorts 3389 -ImageName Win2016Datacenter -Size Standard_B2s -OsDiskDeleteOption Delete -Credential (Get-Credential) –Verbose

Once the 2 VMs are created, we need to note the Private IP Addresses they’ve been assigned. In the “Overview” screen on each, we note that they have been given the first available IP in their Subnets.

So it’s 192.168.2.4 for ProdVM1:

And its 10.10.2.4 for TestVM1:

And just to be sure, lets launch TestVM1 and see if we can ping ProdVM1:

Back in the Portal, I’ll go into the TestVM1 Virtual Network and in the left hand menu go to Peerings:

And when I click Add, this brings me into the options for adding Peering:

As I can see, I need to specify the Peering in both Directions. I can also see that I can specify to Allow or Block Traffic, so I can peer the networks but only allow traffic to flow in one direction.

So when I click “Add”, this sets up the Peering on both sides:

I can now see on “TestVM1” that I’m connected to “ProdVM1”:

And same on the other side:

Now, lets test ping connectivity from TestVM1 to ProdVM1:

And that is how to set up Vnet Peering of Azure Virtual Networks!

Important Points!

There a few things you need to know about Vnet Peering before we close this post out. Vnet Peerings are not transitive. So in a Hub and Spoke Topology where VnetA is peered with VnetB, and VNetA is peered with VnetC, this doesn’t automatically mean that VNetB can talk to VnetC. There are 3 options available to make this work:

  • VnetB would need to be peered directly with VnetC. However, lets say you have a large environment and would need to create multiple peerings. This would then create a Mesh Topology which is more difficult to manage in the long term.
  • The second option is to use Azure Firewall or another virtual network appliance in the Hub Network. Then create routes to forward traffic from the Spoke Networks to the Azure Firewall, which can then route to the other Spoke Networks. We saw in the “Add peering” screen the option to Allow “Traffic Forwarded from a remote Virtual Network”, this needs to be enabled.
  • The third option is to use VPN gateway transit on the Hub Virtual Network to route traffic between spokes. This is effectively the same option as Azure Firewall, but this choice will impact latency and throughput

Both option 2 and 3 can also be used to route traffic from on-premise networks when using Site-to-Site (S2S) or Point-to-Site (P2S) connections to Azure.

Conclusion

I hope you enjoyed this post on Azure Virtual Networks! Next time, I’ll create a P2S VPN Connection in order to connect directly to my Virtual Networks from my laptop via a Gateway Subnet.

Hope you enjoyed this post, until next time!!

100 Days of Cloud — Day 10: Azure Virtual Networks (Part 1)

It’s Day 10 of 100 Days of Cloud, and as promised in the last post, I’m going to talk about Azure Virtual Networks in today’s post and also the next post, so there will be 2 parts dedicated to Virtual Networks.

You’ll have seen Virtual Networks created as I was going through the Virtual Machine creating posts. So, what more is there to know about Virtual Networks? I mean, it’s just a private network in Azure for your resources with block of Subnets and IP Addresses that can be used to provide network connectivity, right?

Well yes, but that’s not all. Let’s dive into Virtual Networks and learn how they are the fundamental building block for your networks in Azure.

Overview

An Azure Virtual Network (VNet) is a network or environment that can be used to run VMs and applications in the cloud. When it is created, the services and Virtual Machines within the Azure network interact securely with each other. This is what we saw in the Default NSG Rules — any resources within the Virtual Network can talk to each other by default.

Virtual networks also provide the following key functionality:

  • Communication with the Internet: Outbound Internet connectivity is enabled by default for all resources in the VNet.
  • Communication between Azure resources: This is achieved in 3 ways, within the Virtual Network, through Service Endpoints, and through Vnet Peering.
  • Communication with On-Premise resources, using VPN (Site-to-Site or Point-to-Site) or Azure Express Route.
  • Filter Network Traffic: Using either NSG’s or Virtual Appliances such as Firewalls.
  • Route Network Traffic: You can control where traffic is routed for each subnet using route tables, or use BGP (Border gateway protocol) to learn your On-Premise routes when using VPN or Azure Express Route.

A Virtual Network contains the following components:

  • Subnets, which allow you to break the Vnet into one or more segments.
  • Routing, which routes traffic and creates a routing table. This means data is delivered using the most suitable and shortest available path from source to destination
  • Network Security Groups, which I covered in detail in Day 9.

One Vnet, Multiple Subnets

So I talked above about having multiple Subnets in a Vnet. This isn’t a new concept for anyone who has ever managed an On-Premise environment with multiple subnets — chances are at some point you would have expanded the network from good old “192.168.1.0/24”.

We’ve seen how a Virtual network and Subnet are created automatically when you create a Virtual Machine using default settings. Let’s expand on that and create a second VM on a new subnet in an existing Vnet to see how it behaves.

Referring quickly back to Day 8, I created a “Prod_VMs” resource group and Virtual machine. This used the default settings as I ran this PowerShell command to create:

New-AzVM –Name ProdVM1 –ResourceGroupName Prod_VMs –Location northeurope -Verbose

This in turn created a ProdVM1 Vnet which contained the following subnet:

So now, I’m going to create a second subnet called “ProdVM2” within this Vnet. And seeing as I’m in the Portal already, I’ll add it from there! So I click on the “+ Subnet” button to begin the process. As I can see below, it asks me for the following information:

  • Name of the new Subnet
  • Subnet Address range (this needs to be within the address range of the Vnet). I can also add a IPv6 range if required.
  • NAT Gateway — this is needed to specify a Public IP Address to use for Outbound connectivity. I’ll leave this blank for now
  • Network Security Group — this associates the Subnet with an NSG. I’ll choose the resource group NSG here.
  • Route Table — needed for routing traffic for our subnet. Again, I’ll leave this blank.
  • Service Endpoints — this option allows secure and direct access to the endpoint of an Azure Service without needing a Public IP Address on the Vnet. You can read more about Service Endpoints here.
  • Subnet Delegation — this option means to can delegate the subnet specifically for a specified Azure resource, such as SQL, Web Hosting or Containers.

Once I have all options filled in, this is what I see:

And when I click save, this is what I see in the Portal under my Virtual Network:

Now I have a new subnet, I’m going to deploy a new Virtual Machine to that Subnet. I’m going to open PowerShell to do this, and I’ll enter this command to create the VM, specifying the Vnet, subnet and NSG I want to deploy it to:

New-AzVM -ResourceGroupName “Prod_VMs” -Location northeurope -Name “ProdVM2” -VirtualNetworkName “ProdVM1” -SubnetName ProdVM2 -SubnetAddressPrefix “192.168.2.0/24” -SecurityGroupName “ProdVM1” -OpenPorts 3389 -ImageName Win2016Datacenter -Size Standard_B2s -OsDiskDeleteOption Delete -Credential (Get-Credential) –Verbose

And if I check the Resource group, I can see my 2 VM’s with all resources present. Note that I don’t have a Virtual network or NSG dedicated to VM2:

Now, before I go any further. We can now see from the above how important it is to define your naming convention correctly in Azure when creating resources. This is indeed a lab environment which I’ll deleting, but in a Production environment you’ll need to know how to identify machines correctly.

Testing using NSGs

What I want to test now is connectivity between resources in the same Vnet to prove this works. I RDP into the 2 machines (which are on different subnets). A quick “ipconfig” on both gives me the IP Addresses of both, and they do indeed correspond to the subnets I created:

Now I’ll ping the machines from each other:

And it’s successful, so this proves that even though the 2 machines are in different subnets, they can communicate as the NSG Rules for traffic inside the Vnet allow this.

Now let’s mess this up a little! I’ll go into my NSG and add a rule denying Ping/ICMP from ProdVM1 to ProdVM2:

And if I try again to ping, it times out:

Conclusion

So as we can see, Virtual Networks are the building blocks of building your Azure Networks and resources from the ground up. They need to be planned properly to ensure the network design both meets your needs from a functionality and security standpoint. You also need to ensure the networks you create in Azure does not overlap with any of your On-Premise networks in the event you are operating in a Hybrid environment.

I did say that this was Part 1 of Virtual Networks — the next post is Part 2 where I’ll be delving into Vnet Peering, which allows you to connect to resources across Virtual Networks located either in the same region or across regions. and showing how that works.

Hope you enjoyed this post, until next time!!