Network Security Groups control the flow of data into and out of you virtual networks. In this video, Sharon shows you how to configure NSGs to allow and block traffic into your subnets or virtual machines.
- [Instructor] Network security groups in Azure control the flow of traffic to our virtual machines and through our subnets. For those of you who have set up firewalls and configured ACLs, or access control lists, network security groups, or NSGs, will feel very familiar. So exactly what is a network security group? Well, an NSG is a list of access control lists that either allow or deny traffic based on rules. The NSG can be applied to either a subnet or a virtual machine.
When applied to a subnet, the NSG rules apply to all of the virtual machines within that subnet. But only one NSG can be applied to a subnet, a virtual machine, or the network interface. And network security group rules can apply to either inbound or outbound traffic. Let's take a look at the NSG workflow before we actually dive into them. First of all, traffic enters the Azure virtual network. This could be a virtual machine as well. I've applied it to a virtual network here. The NSG traffic rules are loaded, and then the first rule is processed.
Based on the rule, the traffic is either allowed or denied. If it's the last rule, then that is the end of the process. Any further packets are dropped. If it is not the last rule, then we go back up and start processing the next rule and we just continue through that flow. Let's go ahead and jump into a network security group rule. It'll make a little bit more sense when we go to configure them. Now let's go ahead and actually take a look at our network security groups. You will notice here that I have three. One for each virtual machine that I created.
When you create a virtual machine, you have the option then to create a network security group, associate a network security group, or you can remove the network security group. I'm going to go ahead and work with Web2. When I created this virtual machine, I used the default selection for network security groups. We see that we have one network security group, and it's associated with a network interface, which in turn, as we now know, is associated with the VM. We have one inbound security rule and one outbound. Or so we think. I'm going to drill into our inbound security rule.
And you'll notice that we have one set at a priority 1000. And basically what this one does is allows RDP from any source to any destination on the RDP port. But when we create a VM, like I said, we have a default network security group already assigned for us, and there are some default rules that are automatically within that network security group. We have three of them and they are AllowVnetInBound, so this allows for a virtual network to virtual network communication. We are allowing traffic from an AzureLoadBalancer, and then we're denying all other inbound traffic.
I'm going to go ahead and close this for a moment and let's take a look at the outbound. Right now we do not have any rules that we've created. But there are some default rules. Again, we're allowing for virtual network to virtual network traffic. We are allowing all internet outbound, and we're denying everything else. And the virtual network and the internet, those are system tags that you can use. So instead of actually typing in the virtual network IP or the source, you can just go ahead and use that system tag. Same for internet.
I'm going to go ahead and close this. Let's go ahead and create an inbound security rule. I'm going to go ahead and click Add. And I'm going to create one for web traffic. As this is a web server. You'll want to use a descriptive name for your network security groups. Next is your priority. Microsoft does recommend using increments of 100. If I use 1100, then my RDP rule will be applied first, followed by our web rule.
And the reason Microsoft recommend using increments of 100 is to allow for the addition of more rules. Some of you may remember Basic and actually did the same thing there, where we'd space it out so we could add in more lines of code as necessary. I know some of you are probably cringing. Next, we can choose an IP or an IP address range, if you like to do that, or we can use a tag. And these are those system tags or source tags. So we have Internet, VirtualNetwork, or AzureLoadBalancer. It makes a little bit easier for you.
When you use Any, you reduce the number of rules. And then our service, in our case we're going to be using HTTP and so it automatically changed our protocol to TCP and our port range to 80. We could have gone ahead and chosen something different or used the custom. And before I go ahead and click OK, I'm just going to flip to the Advanced section, just so you can see the difference. Here we can add our source port range if we wanted to do so. I'm going to go back to basic. I'm going to allow this option and click OK.
This will take a few moments to create. And there we are, we now have our rule. One thing to keep in mind is you can only have 200 rules per network security group. 200 rules I think is a little obsessive, but you can do it. But if you need more than that, you're going to have to think about how you're going to arrange your network security groups. I'm going to go ahead and close this. The last thing I want to touch on is applying this network security group to multiple virtual machines. Right now it is only associated with that one network interface.
If I have 40 web servers sitting in my FrontEnd subnet, the last thing I want to do is go through and have to apply this 40 times. The easier way to handle this is to click on Subnets and associate this rule with that entire subnet. So if I click on Virtual network, I'm going to choose the Production network and then I'm going to go ahead and click on FrontEnd, as that's where all of our web servers are. And click OK. Now every virtual machine within that subnet will be allowing for traffic on port 80 to enter.
Remember, your virtual machine, by default when it is provisioned, will have a network security group unless you change that setting on provisioning. And it is easier to apply that network security group to a subnet, instead of each individual virtual machine. And you can probably recite it now, but planning is the key in Azure.
- Creating an Azure virtual network
- Creating a virtual network using PowerShell
- Deploying a VM into a virtual network
- Modifying IP addresses
- Working with Azure DNS
- Configuring NSGs
- Setting up load balancers
- Configuring Azure load balancers
- Creating an application gateway
- Setting up on-premises connectivity
- Adding gateway VPNs
- Validating VPN devices
- Configuring VNet
- Creating site connections