1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. Design Microsoft Azure Infrastructure and Networking for Azure 70-534 Certification

Virtual Networks

Contents

keyboard_tab
Introduction
1
Intro
PREVIEW1m 41s
Summary
8
Summary
1m 46s
play-arrow
Start course
Overview
DifficultyIntermediate
Duration57m
Students550

Description

This is the first of six preparation courses for the Architecting Microsoft Azure Solutions 70-534 certification exam. By the end of this course, you will have gained a solid understanding of Azure data center and VPN architecture. We will cover Azure’s use of Global Foundation Services for its data centers, virtual networks, Azure Compute (IaaS, virtual machines, fault domains), VPNs, and ExpressRoute. This session will also feature a high-level discussion of Azure services (load balancing options, Traffic Manager, and more).

Transcript

Welcome back. In this lesson, we will be talking about virtual networks.

We are going to start by talking about traffic within the context of virtual machines. We will cover IP addresses, DNS, and load balancing. And then we are going to look at the security elements of networking and we will be talking about network security groups and firewalls. And finally we will look at a couple of aspects of endpoint configuration.

Let's start off with virtual networks at a high level. A virtual network is a representation of a network in the cloud. It is a way to organize and isolate virtual machines controlling addresses, DNS settings, security policies and routing tables. If we were to set up a virtual network for a simple web application, we might use two subnets. One for the web servers and one for the databases. Each subnet allows us to break out the virtual machines based on their role allowing us to apply the same security rules to all of the VMs in the subnet and using role based subnets is a common practice.

A virtual network is defined by an address space. Different virtual networks distinguish each other by a set of addresses. It is a common practice in IP addressing that a private network can have one of three base addresses. We have the 192.168 range which allows for up to 65,536 reservable addresses. We have the 172.16 range for just over a million addresses and then we have the 10 range for over 16 million addresses.

Let's check out how to create a virtual network using the classic deployment model. From inside the portal, we can click on new and then we will select networking and then we want to follow that up by clicking on virtual network. For this demonstration, we are going to be using the classic deployment model as the resource manager method is not currently included in the certification path but you should know that there is another option and that's the resource manager way. Okay let's click on create. We need to give our network a name. We will select a name here and we can change our address space if we want to. However, let's just leave this to the default and we can change the name of our subnet. And let's do that for clarity. Okay the subnet range is already selected so let's just leave that as it is. And then let's change our region to west central US. And we can create our resource group here or if we already have one we can select it here as well. Great, now let's create our virtual network.

This may take just a moment and because of that I'm going to jump forward to when it is completed. You may see that throughout the course. Anytime something is going to be a long-running process, I'm going to jump froward to the end. If you find that it takes a little while when you are doing these things yourself, just know that that's normal.

Okay now that it is done we can check out the virtual network in the all resources list. Let's drill into it and there we go. We have our address space and we have our subnets. Let's add a new subnet here. Let's imagine we want one for our backend services so we are going to click add. And we will name it. Okay and then we will accept all of the defaults for everything else and click okay. That's it. That's really all there is to adding a new subnet. Virtual networks are extremely useful since they open up possibilities such as hybrid, on-prem to cloud networks as well as the possibility to allow secure traffic between multiple virtual machines and cloud services within Azure.

We will add a virtual machine to our network in a moment. However, before we do we should talk about IP address. A virtual machine has an internal address called a dynamic IP or DIP. It is assigned by the virtual network when the machine is provisioned. A DIP is assigned via the DHP service with a near infinite lease. However, it will be lost when the VM is stopped or de-allocated. A DIP is accessible only inside of the virtual network. A VM can have multiple virtual network cards and each of them can have its own DIP. I want to point out before we move on the next section we will be talking about cloud services. Cloud services are kind of the older way of doing things. Using the classic deployment model. The new way to handle things like creating a load balancer is different. However, at the time of this recording the classic mode is what's on the exam. So that's what we are going to be covering so this next section is going to be in the context of the classic mode.

It is important to understand that a VM in Azure sits behind what is effectively a load balancer. The load balancer by default acts as the public facing endpoint to the internet. It is what contains the public IP address. Behind this sits the VM, which has private virtual IP addresses. Traffic is routed via the load balancer to the VM and specific ports can be opened up on the load balancer and mapped to ports on the VM.

You could bypass this load balancer should you need to by creating an instance level IP address and this will serve as a public IP address allowing direct traffic.

A virtual machine is always created in the context of a cloud service. A cloud service is assigned a public virtual IP or a VIP to be reachable from the internet. It has a fully qualified domain name with the format cloud service name dot cloud app dot net in the Azure DNS to be accessible from the internet. It is possible to assign a custom domain name to a cloud service using a CNAME record to map the custom domain with Azure's fully qualified domain name. It is also possible to use an A record to map custom domain name but with one caveat. By default, the virtual IP address is dynamically assigned when the machine is provisioned and it is not guaranteed when the machine is provisioned again after a shutdown. It is a best practice to refer to the fully qualified domain name to ensure that you can actually reach the VM.

Let's talk about endpoints. A virtual machine endpoint is a port mapped to a public facing virtual IP to open up services to the cloud. For example to open up HTTP access to a VM, it is necessary to create an endpoint for the HTTP port which is port 80. By default a VM is created with two endpoints. One for RDP port 3389 and the other is for Powershell and that's port 5986. An endpoint can be a standalone or load balance thing. In the case of standalone, the mapping associates the public virtual IP address to a single private dynamic IP address. For a load balanced endpoint a mapping associates the public virtual IP address to multiple dynamic IP addresses. This mapping is done on an element outside of the virtual network and is called the Azure load balancer. This association allows for port remapping. For example, a public endpoint that handles HTTP traffic can map port 80 of the virtual IP address to port 8080 of the corresponding dynamic IP address on the VM.

All right, before we move on to actually creating a VM, let's talk about access control lists and security groups. When an endpoint is created, all traffic is permitted to the endpoint and access control list provides the ability to selectively permit or deny traffic from a virtual machine endpoint. For example you can specify a network access control list for an RDP endpoint created on a virtual machine which will lock down access for certain IP addresses. You can specify network ACLs or access control lists for endpoints but you can't apply them to an entire virtual network or specific subnet. You can selectively permit or deny network traffic for a virtual machine endpoint by creating rules that permit or deny. Permit and deny rules must be listed in the proper order of precedence to have the correct control over the network traffic.

Network security group basically is a list of ACL rules that allow or deny traffic. Network security groups can be associated with either subnets or individual virtual machine instances within that subnet. When a network security group is associated with a subnet, the ACL rules apply to all virtual machine instances in that subnet. A network security group is a top level object meaning it can be defined independently from any network or virtual machine. When you are creating rules, it helps to be able to reference common IP addresses with a shortcut. Azure provides us three default tags. Default tags are system provided identifiers to address a category of IP addresses. You can use them to reference the entire address space of your network. For example you can use the virtual underscore network tag or the Azure underscore load balancer tag to reference Azure's infrastructure load balancer. And there is the internet tag which is for IP address spaces outside of the virtual network and are reachable by the public internet. All network security groups contain a set of default rules. The default rules can't be deleted. However, they are assigned the lowest priority. So they can be overridden by rules that you create. While connectivity to the internet is allowed for outbound traffic, inbound traffic is blocked by default. There is a rule that allows Azure's load balancer to probe the health of your VMs and role instances. Though you can override this rule if you are not using a load balanced set. Endpoint based ACLs and network security groups are not supported on the same VM instances. If you want to use a network security group and have an endpoint ACL already in place, then you have to remove the endpoint ACL first.

Okay let's get to the good stuff and actually create a network security group. We are going to start off in the portal and we are going to click on new and then we are going to search for network security group. And we will see it here in the list. So we can click on that and it will open up the security group blade. We are going to select classic because again the exam is still mostly based on the classic mode. However, that will probably change in time. And then we will click create.

We need to give the security group a name. So we will select ours as web traffic. And then we will select a resource group and click create. It will take just a moment to create and deploy and once it is complete, we will be able to see it under our all resources list.

If we click on it here, we get the expanded blade for it. Under settings, we have inbound and outbound rules. Let's add an inbound rule. We will select it from settings and click add. And then we will give it a name and we will change the service to HTTP. So port 80 and then we will click okay and it is going to create this rule for us. Now let's create one more for HTTPS. We will go ahead and do that and we can see our HTTP rule now exists and after just a moment so does our HTTPS rule.

If you are new to Azure, it looks like here there are only two rules. However, if we click on the default rules, you can see we have some more. Let's check out our outbound rules and you can see we don't have any. However, we do have some default outbound rules.

We have our security group. Let's go back to the virtual network that we created earlier and apply it to one of the subnets. We will click on subnets and let's select our front-end subnet and you can see the subnet blade doesn't have a security group listed here. We will click on that and we are going to select our web traffic security group. This is going to allow internet traffic to hit any of the virtual machines on this subnet and that's port 80 and 443.

Okay we've talked about virtual networks and virtual machines and we've created a virtual network in our previous demo so let's go ahead and create a virtual machine and then add it to our network. We will start by clicking new and then compute and then we will select server 2012 R2 data-center. We will fill out this basic info here. We will give our instance a name. Need to set a user name and okay and then we need to set a password and we add the verification for the password. Great and now we will set the resource group. Okay. And we can change the region here. We are going to use West Central US. All looks good and we will click next.

When this loads, it will have a select the VM size. We will just use the default and so we are going to click next again.

We will change the disk type to standard. We really don't need SSD for this demo. And next we will use a storage account since we already have one, we are gonna select that. However, you can also create a new one here if you need to and next we need to select the cloud service domain name. This is that public facing endpoint on the load balancer that we talked about earlier. And we will edit this and click okay. Next we need a virtual network. Azure is offering to create a new one here. However, we have our one from earlier with our couple of subnets. So that's the one that we want to select. We will use the front end subnet. However, you can see that we could select either, great. Everything looks fine. So let's scroll down and click okay.

All right jumping ahead to when it is complete. Now let's try and connect into our VM. We click on connect. It is going to download the file. Okay it has failed. Why it has failed? If you remember, we set up a security group that allows incoming traffic to port 80 and 443. However, we are trying to connect on the RDP port of 3389. So let's go back and add a port to our security group. We will add a new rule and we will set it for RDP. Okay, perfect.

Now let's go back and try and connect and see if our traffic is able to make it through the firewall. So we connect. Great right off you should notice that we are prompted for user credentials which didn't happen last time. We will supply our credentials and there we are. We have successfully connected.

I know we have covered a lot in this lesson. Maybe now is a good time to take a break. However, if you are ready to keep going then let's move on to talk about virtual machines in our next lesson.

About the Author

Students37945
Courses17
Learning paths15

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.