Skip to main content
In this lesson we’ll learn how to create Network Security Group (NSG) rules in Azure, how each component of a rule works, and how rules from multiple NSGs are evaluated together. This guide keeps the original step sequence and diagrams while improving clarity and SEO for quick reference. Key concepts covered:
  • What to specify when creating NSG rules
  • Service tags and why to use them
  • Portal walkthrough: create NSG, add inbound/outbound rules
  • Subnet vs NIC NSGs and Effective security rules
  • Practical outbound example using service tags

​
NSG rule components (at a glance)

The image shows a form for adding an inbound security rule in a network security group (NSG) setup, specifying criteria like source, destination, port range, protocol, action, and rule name.
Lower numeric priority means higher precedence — the rule with the smallest numeric priority is evaluated first.

​
Service tags — simplify rule maintenance

Managing IP ranges for cloud services is error-prone. Azure service tags are predefined labels that represent groups of IP address ranges used by Azure services (for example: VirtualNetwork, Storage, Internet, LoadBalancer). Use service tags in your source/destination fields to avoid maintaining large IP lists — Azure updates these tags automatically.
The image illustrates the use of service tags in a Network Security Group (NSG) to manage network traffic, showing rules to allow Azure service traffic while denying internet outbound access. It highlights actions, sources, destinations, and ports in a table format, along with benefits like predefined labels and automatic updates.

​
Hands-on: Azure portal walkthrough

This example uses a set of VMs in a VNet where NSGs have not yet allowed inbound SSH. By default, inbound SSH from the Internet will be blocked until you create an appropriate NSG rule.
The image shows the Microsoft Azure portal interface, specifically the network settings for a virtual machine named "vm-nsg-lab-1". It lists details like public and private IP addresses and configurations for network security groups.
Attempting to SSH directly to a VM without an NSG allowing SSH will fail:

​
Create an NSG

  1. In the Azure portal, go to Network Security Groups → Create.
  2. Provide a name (for example, NSGLab01) and the target region (e.g., East US), then click Review + create and complete creation.
  3. Open the NSG resource to inspect default rules.
Default inbound rules include (examples): Default outbound rules typically include:
  • AllowVNetOutbound
  • AllowInternetOutbound
  • DenyAllOutbound (catch-all)
These defaults explain why VMs inside the same VNet can communicate, but inbound Internet traffic is blocked unless explicitly allowed.

​
Associate the NSG

  • Associate your new NSG to the target subnet (or to a NIC for per-VM interface control). In this walkthrough, the NSG is associated with the subnet containing the VMs.

​
Add an inbound rule for SSH

  1. Go to the NSG → Inbound security rules → Add.
  2. Configure:
    • Source: Any (or restrict to a specific IP, My IP, a service tag, or an Application Security Group)
    • Source port ranges: * (or specify if needed)
    • Destination: Any
    • Service: SSH (auto-populates TCP port 22)
    • Action: Allow
    • Priority: 100 (lower number = higher precedence)
    • Name: AllowAny_SSH_Inbound
    • Optional: add a description
  3. Click Add.
Opening SSH (port 22) to Any exposes the VM to the Internet. Restrict the Source to known IPs or use Just-in-Time VM access where possible.
A caution symbol may appear in the portal indicating the rule is open to the Internet — use that as a reminder to minimize attack surface.
The image shows the inbound security rules for a network security group in Microsoft Azure. It lists several rules with priorities, names, ports, protocols, sources, destinations, and actions (allow or deny).
After adding the rule, you should be able to SSH to the VMs in that subnet:
Because the rule was applied at the subnet level, all VMs in that subnet inherit the SSH access.

​
Effective security rules and NIC-level NSGs

You can apply NSGs at both the subnet and network interface (NIC) levels. Traffic must be allowed by every applicable NSG for the flow to succeed; a Deny at either level blocks traffic.
  • Example workflow:
    1. Create a second NSG and assign it to the NIC of VM3.
    2. If SSH is allowed at the subnet level but denied at the NIC NSG, SSH to that VM will fail.
To inspect the combined effect of subnet + NIC NSGs:
  • Go to the VM → Networking → select the NIC → Effective security rules. This displays aggregated inbound/outbound rules and which rule ultimately allows or denies traffic.
The image shows a screenshot of the Microsoft Azure portal displaying a list of virtual machines, including details such as name, subscription, resource group, location, status, operating system, size, public IP address, and number of disks.
The image shows a Microsoft Azure portal indicating that a deployment named "CreateNetworkSecurityGroupBladeV2" is complete. It provides options to view deployment details, go to the resource, and manage cost alerts.
The image shows the network settings of a virtual machine in Microsoft Azure portal, detailing network interfaces and IP configurations alongside various networking options and settings.
The image shows the "Effective security rules" interface for a network security group in Microsoft Azure, displaying inbound and outbound rules with details about priorities, source and destination ports, protocols, and access status.

​
Outbound example using service tags (deny Internet, allow Storage)

This example demonstrates how to block general Internet outbound access while allowing Azure Storage access by using service tags. From the VM, a curl to a blob returns binary content (use --output or -o to save instead of printing binary to terminal):
To block Internet outbound but allow Storage:
  1. In the NSG attached to the VM/subnet, add an outbound Deny rule:
    • Source: Any
    • Destination: Service Tag → Internet
    • Destination port ranges: *
    • Action: Deny
    • Priority: 200
    • Name: Deny_Internet
  2. This will override the default AllowInternetOutbound (priority 65001) because 200 is a smaller number and thus has higher precedence.
The image shows the Azure portal interface, specifically the network settings for a virtual machine, where an outbound security rule is being configured. The rule involves setting parameters like source, destination, protocol, and port ranges.
After adding the deny rule, outbound Internet access from the VM is blocked:
To permit Storage access while Internet is denied:
  1. Add an outbound Allow rule:
    • Source: Any
    • Destination: Service Tag → Storage
    • Destination port ranges: 443,80 (or the ports you need)
    • Action: Allow
    • Priority: 100 (higher precedence than Deny_Internet)
    • Name: Allow_Storage
You may specify multiple ports or CIDR ranges separated by commas (for example, 10.1.1.0/24,10.1.2.0/24) if you prefer IP-based rules. After adding the Allow Storage rule:
Service tags make this simpler because Storage includes all necessary Azure storage IP ranges; you don’t need to keep a manual list of IPs.

​
Summary

  • Use predefined Services for common ports or Custom for custom ports. You can specify single ports, ranges, and comma-separated lists for complex needs.
  • Priority numbers are evaluated ascending; lower numeric values take precedence.
  • NSGs may be applied at both Subnet and NIC levels. Traffic must be allowed by all applicable NSGs—any deny blocks the flow.
  • Prefer Service Tags to reference Azure services (Storage, Internet, VirtualNetwork, etc.) to reduce administrative overhead and rely on Azure-managed IP updates.
  • Always minimize exposure when allowing management ports (SSH/RDP). Restrict sources or use Just-in-Time access where possible.

Watch Video