Azure Lab pt4 - Network Security Groups
In this post, we will work with NSGs directly, and even do a bit of troubleshooting. This is a very simple example, but it should help to illustrate another area you can troubleshoot network connectivity and access. This example will consist of direct connection to our VM, but NSGs deal with all network traffic to and from resources in Azure VNets. NSGs contain security rules allowing or denying traffic inbound or outbound. NSGs can be attached at the Subnet or Network interface level.
From this NSG select Subnets from the Left
Select Associate
Select your Vnet1 and Select your Sub1
Click OK
Return to your Resource Group from the Azure Portal menu
Find your VM and click into your VM and stay on the Overview page
Now we are going to do a bit of troubleshooting. This next piece will hopefull illustrate some of the areas you can check, if the intended access is available. Now, open the Putty application and Double-Click that saved session created in the last post. After a few seconds you should see a Netowkr Error.
Return back to your VM window in Azure and select Networking. You will see all Security Rules applied. You May notice SSH is allowed on the Ubuntu1-nsg, which is attached to the Ubuntu Network Interface, but isn’t configured on the Network Security group attached to your Subnet. Traffic Flowing into a VNet hit the Subnet NSG first then on to the NSG at the Network Interface. The opposite is true on the reverse
As stated in the beginning, NSGs can be attached to the Subnets inside VNets, or directly to the VM network interface. Traffic flowing into the VNet will hit any NSG attached here first. As with thiis example. If there isnt a NSG it will move on to the VM Interface. But remember, the reverse is true for traffic flowing out of the VM. It would be VM interface first, and then on to the Subnet NSG. When dealing with VMs, bringing up the VM overview page is an excellent way to quicly see what is being applied. Now, let’s move on to Private Endpoints.