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.

1. Search for Network Security Group- select and Click Create from the next screen

2. Check your Subscription 

3. Select your Resource Group 

4. Name the NSG
   (first initial)(first 4 last name)-nsg1 

5. Select YOUR Region

1. Select  Review + Create 

2. If validation says Passed, click Create 

3. Now Wait for resource to create 

4. Select Go to resource – Either from the deployment window or the Notification Menu as we did before.

5. Observe the default Inbound and Outbound Rules. Rules are applied in order of priority-
   the lower the number the higher the priority. 

1. From this NSG select Subnets from the Left 

2. Select Associate 

3. Select your Vnet1 and Select your Sub1 

4. Click OK 

5. Return to your Resource Group from the Azure Portal menu

6. 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

1. Return to your Azure Portal with the VM Overview page

2. Select Networking form the left-hand options

3. Locate your NSG1 Rule – Should be the set of rules on the top

4. From the Right Select the blue box with Add Inbound port rule

1. The Add Inbound Security Rule Menu will appear to the right

2. Add the Rule- ALLOW_SSH  Destination port Ranges: 22 Action: Allow
   Priority: 100 Name: Allow_SSH (Image Above)

3. Click Add from the bottom

Wait for the security rule to be created then Launch Putty where you Select your saved session 

If the session fails immediately, wait a sec for the Network rules to fully update and try again.

Remember Azure brought us the   #BSoD

When you get the message displayed to the right, select Yes.

From within Putty , open your previously Saved Session and l

eave Putty Open . We will use this session in the next post.

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.