An Azure Virtual Network, or VNet, provides a private network for Azure resources. Subnets organise address ranges inside it, network security groups filter traffic, and routes determine where packets go. These components solve different problems; creating a subnet alone does not isolate an application from every other subnet.
This beginner tutorial uses an illustrative two-subnet application. The goal is to explain a connection before troubleshooting it: which machine starts it, which address and port it targets, which rules apply, and whether the destination is listening.
Plan the addresses before creating resources
Consider a VNet named vnet-training with address space 10.20.0.0/16. Within it, reserve 10.20.1.0/24 for a web subnet and 10.20.2.0/24 for an application subnet. These are example private ranges, not required values.
Keep subnet ranges inside the VNet and avoid overlaps. Think ahead about other networks you may connect through peering or VPN. An address plan that works for one isolated lab can become a problem when a second environment uses the same range. Microsoft’s VNet overview explains the supported connectivity patterns.
What an NSG actually checks
A network security group evaluates rules using properties such as source, destination, protocol and port. Rules have priorities; lower numbers are evaluated first. An NSG may be associated with a subnet or network interface. When both apply, you must consider both sets of rules.
Default rules include permitted virtual-network traffic and a final inbound deny rule. Therefore, two subnets are not automatically separated by a deny boundary. NSGs are stateful: a permitted connection’s response traffic is tracked, and existing flows can behave differently from new connections after a rule change. See Microsoft’s NSG rules reference.
Design one narrow application flow
Suppose a web VM needs to reach a training application on TCP port 8080 in the application subnet. Write the intended flow as web subnet → application subnet → TCP 8080. Add a specific allow rule for that flow, followed by an appropriate deny rule for unwanted inbound traffic to the application subnet. Review required platform and administration traffic before introducing the deny.
Do not open every port merely to make a failed test pass. If the exercise needs administration access, plan a separate restricted path. Your application rule and your administrator access rule should each have a clear purpose.
Routes choose a path; they do not open a port
Azure supplies system routes, and you can associate a route table containing user-defined routes with a subnet. Route selection considers the most specific matching address prefix, with further precedence rules when prefixes are equal. A route to a virtual appliance is useful only when that appliance and its forwarding configuration can carry the traffic.
Changing a route cannot make a stopped application listen on port 8080, and an NSG allow rule cannot repair a missing route. Consult the Azure routing guide when examining effective routes.
Practice lab and expected observations
- Prepare an authorised sandbox. Record the intended resources and their costs before deploying any VMs or paid networking services.
- Create the network plan. Define the VNet, web subnet and application subnet. Keep a labelled diagram with the example ranges.
- Deploy only the required test endpoints. Run a simple application listener in the application subnet. Confirm locally that it is actually listening.
- Apply the intended NSG boundary. Allow the web-to-application TCP 8080 connection and review how lower-priority rules affect other sources.
- Test the allowed case. From the web endpoint, make a TCP or HTTP request to the application’s private address and port.
- Test a denied case. From a separate authorised test source, attempt a connection excluded by the policy. Record the observation without weakening the intended rule.
- Retest after a change. Start a fresh connection when evaluating a changed NSG rule. Document the before-and-after configuration.
These are proposed validation steps; successful results depend on your actual configuration. Save the source address, destination address, port, timestamp and error for each attempt. A failed ping alone does not establish whether an HTTP service is reachable.
Do not assume internet access is automatic
An outbound NSG allowance and an internet route are not, by themselves, a complete outbound connectivity design. Use an explicit outbound method where required, such as NAT Gateway, and account for its cost. Microsoft has changed default outbound behaviour for new VNets; check the current default outbound access guidance before following an older tutorial.
A practical troubleshooting sequence
First verify the destination address and DNS resolution. Next check whether the service is listening, then inspect the guest firewall, effective NSG rules and effective routes. Finally check the return path and any intermediary appliance. Write down which layer each test rules out.
If the connection succeeds but the service returns an authorisation error, move to the Microsoft Entra ID guide. For a storage endpoint, also review the storage access guide. A deployment runner may face the same connectivity boundary; the Pipelines versus Actions guide explains that context.
To place networking within a broader administration learning plan, review Azure training in Vizag at Softenant. Retain your diagram and test log as evidence of your own practice.