Network (NSG) Testing (AZ-500 Study Series)

Shone Pious
Nov 22
3 min read

In this blog:

Verifying SSH connectivity.
Creating a temporary Deny rule (HTTP on port 80).
Re-enabling port 80 (Allow rule with higher priority).
Clean up.

This lab builds directly on the environment created in my previous post, where I deployed a VNet, subnet, NSG, and a Linux VM.

Now that the environment is up and running, we can start validating how Network Security Groups behave by testing both allowed and denied network traffic.

➡️ Click here to see my blog on setting up the Azure environment for this lab.

➡️ Click here to see my blog on Private Endpoints and DNS zones.

Verifying SSH connectivity

The first test is to confirm that SSH (port 22) is allowed through the NSG.

From my local machine, I initiated an SSH connection to the VM:

ssh -i "C:\Users\shone\Documents\vm-frontend_key_1117.pem" shonep@20.162.93.224

✔️ The connection works, which confirms the NSG is correctly allowing inbound SSH traffic.

Below is the inbound ruleset for my NSG:

A few key observations:

Allow-SSH (port 22) has priority 100, meaning it is evaluated before any lower-priority rules.
SSH is open from ANY source, which would be insecure in production — but acceptable here for testing.
The NSG includes default rules such as DenyAllInbound (priority 65500).
No unnecessary ports are open, reducing attack surface exposure.

Keeping unused ports closed is crucial to prevent lateral movement, port-based attacks, and general exposure to the public internet.

Creating a Temporary Deny rule (HTTP

on port 80)

Next, I tested how NSG deny rules behave.

From the NSG pane, I selected + Create Port Rule, chose Inbound rule, and configured a Deny rule for port 80.

The updated ruleset now looks like this:

To test the rule, I ran:

curl http://<public-ip>

Since port 80 is explicitly blocked:

The connection hangs until timeout, confirming that traffic cannot reach the VM.

This shows the deny rule is functioning exactly as expected.

Re-Enabling Port 80 (Allow Rule with Higher Priority)

To further validate rule evaluation order, I created a new Allow HTTP (port 80) rule — but with higher priority (lower number) than the deny rule.

Updated ruleset:

Now when running the same command:

curl http://<public-ip>

This time, the result changes to:

Connection refused. This is not a timeout — it indicates port 80 traffic is now allowed through the NSG, but the VM itself isn’t hosting any service on port 80.