The problem: who can reach the store?
Imagine Campux runs a small online store. A web server receives customer requests. A data server holds orders. An administrator sometimes needs to sign in to fix a problem. Should every computer on the internet be able to reach all three? Of course not. Before deploying them, we need an address plan and rules for the paths between them.
An IP address is a network address for a device or service. A virtual network (VNet) is an Azure address space you choose for private connectivity. A subnet is a smaller range inside it. The ranges organize resources; they do not, by themselves, block traffic. An NSG (network security group) is where you write allow and deny rules for a subnet or network interface.
One network, three jobs
VNet: 10.20.0.0/16
Web: 10.20.1.0/24 — receives approved customer traffic.
Data: 10.20.2.0/24 — accepts only the application traffic it needs.
Management: 10.20.3.0/24 — contains an admin VM with no public RDP port.
These are example private ranges. A public entry would be a separately configured service such as an application gateway; merely drawing a “web subnet” does not expose a site. We will decide each permitted path explicitly.
Read the address plan
The slash in 10.20.0.0/16 tells us how much of the address stays fixed. A smaller slash number leaves more room. Our /16 VNet can contain the three separate /24 ranges above. Think of the VNet as a street district and each subnet as a numbered block. A block's name does not provide a lock.
A /24 contains 256 addresses in total. Azure reserves five in every subnet, so 251 can be assigned to resources. The number is useful for planning; you do not need to convert binary by hand to follow this class. Make ranges large enough for growth and check that they will not overlap networks you intend to connect later.
Pause and check: If the data server is in a separate subnet, can the web server reach it automatically? Do not guess from the labels. The answer depends on the effective security rules and routes. Azure NSGs include a default rule that allows VNet traffic, so separate subnets are not automatic isolation.
Write a rule for one path
Two words first. TCP is the protocol most applications use to hold a conversation across a network. A port is a number that says which program on the destination should answer: 443 for HTTPS websites, 3389 for Remote Desktop, 1433 for SQL Server. An NSG rule names both.
Suppose the web server must reach a database VM on TCP port 1433. On the data subnet's NSG, allow that port from the web subnet's address range, then write an appropriately scoped deny for other VNet sources if the default VNet allow would otherwise admit them. Check the complete effective rules before claiming the data server is isolated. If your database is Azure SQL Database instead of a VM, it does not simply sit in this subnet; private access uses a private endpoint and DNS configuration.
An NSG rule asks four practical questions: which direction, from where, to which destination and port, and allow or deny? Azure checks matching rules from the smallest priority number upward and stops at the first match. For the same inbound RDP traffic, a deny at priority 100 wins before an old allow at 200. The cleaner long-term fix is to remove the unnecessary allow as well.
Default NSG rules permit traffic within the VNet and outbound traffic to the internet, while unmatched inbound internet traffic is denied. Defaults can be overridden by your rules, and actual outbound connectivity also depends on routing and how the resource is configured. No public IP means an internet client has no direct public address for that VM; it does not mean every path to the VM is blocked.
Find the exposed admin port
In this simulated incident, a management VM has a public IP and an old rule allowing RDP (port 3389). Put a higher-priority deny in front of it, then choose a dedicated Azure Bastion path. The game changes a diagram, not your Azure subscription.
Finish the management fix
The game's deny stops the pictured internet probe, but it does not erase the old allow rule. In a real change, remove that obsolete rule, verify the intended admin connection works, and then remove the VM's public IP. Azure Bastion can broker RDP or SSH to a private VM. Standard Bastion deployments use a separate, dedicated subnet named AzureBastionSubnet of at least /26; the VM stays in its management subnet. Bastion itself has configuration, access rules, and cost to review.
An application security group (ASG) is an optional label for VM network interfaces. It lets an NSG rule refer to “web servers” instead of a changing list of VM addresses. The ASG is not a firewall by itself; only a rule using it changes traffic. Later classes will apply these ideas to specific services.
Routes answer a different question
An NSG asks whether a packet is allowed. A route decides where an allowed packet goes next. A user-defined route can send traffic to a real network appliance, for example, but pointing a default route at a missing appliance can stop the subnet's outbound traffic. A peering connects VNets privately; it does not make a chain of peered VNets automatically transit through each other. When a connection fails, check both effective security rules and effective routes, plus DNS and the destination service.
A private endpoint gives a supported Azure service a private address in your VNet. It is different from placing the service itself inside your subnet. For example, an App Service app uses VNet integration for outbound access to private resources; a private endpoint is a separate inbound private-access feature. You will practice those designs later. For today, retain the distinction between address plan, traffic rule, and next hop.
Draw it and predict the packet
Draw one box for
10.20.0.0/16. Inside, draw web10.20.1.0/24, data10.20.2.0/24, and management10.20.3.0/24. Mark them “address ranges,” not firewalls.Draw a web-to-data arrow labeled TCP 1433. Write which data-subnet NSG rule would allow it, and which other sources you would deny after checking the default VNet allow.
Add a public IP to the management VM and an old inbound allow for 3389 at priority 200. Put a matching deny at priority 100 above it. Which rule wins? Then cross out the old allow and the VM's public IP. Draw a separate
AzureBastionSubnetfor the broker.Suppose an allowed packet still disappears. Write “effective routes” beside the arrow. This is where you inspect the next hop, rather than changing NSG rules at random.
If you use an existing Azure subscription, view a VNet's Subnets, an NSG's inbound/outbound rules, and a VM network interface's effective rules/routes. This exercise requires no resource creation or route changes.
Network security groups and default rules · VNet and subnet planning · Bastion subnet requirements · App Service VNet integration
Say it aloud or write three sentences before comparing.
Address range, permission, and route are separate decisions. A subnet name alone is no security control. The public entry and private admin path also need their own explicit configuration.
Predict a packet, then read its configuration
Use the fictional evidence below. Steps 1, 2, 4 and 5 are on paper. Step 3 runs the free hub-and-spoke lab, which creates networks and rules but no machines, so nothing in this exercise measures a live connection.
Web subnet: 10.20.1.0/24 Data subnet: 10.20.2.0/24 Rule under review: allow web → data TCP 1433
Draw the source, destination and port of the request: a web server in 10.20.1.0/24 opening a TCP connection to port 1433 on a database server in 10.20.2.0/24.
Predict, before you look anything up: which NSG sees this request first, the web subnet's outbound rules or the data subnet's inbound rules? Which rule number would you expect to match?
Open the hub-and-spoke lab and run it. Its checkpoints print the peering state and the NSG rules in priority order. Write the same kind of table for your 1433 rule: priority, source, port, allow or deny.
Label your result honestly: configured, not tested. The lab builds no VMs, so no packet ever travels. You have checked the address plan and the rule order, which is what an auditor reads first.
On your own: the database moves to port 5432 (PostgreSQL) and a second web subnet, 10.20.4.0/24, needs the same access. Rewrite the rule without widening it to the whole VNet.
Check your reasoning after you finish
Outbound from the web subnet is allowed by the default rules, so the data subnet's inbound NSG is the one that decides. An NSG rule is one check: DNS, the route, the database listener and its login still matter, and allowing TCP 1433 grants no database login. For the variation, list both web ranges as sources (or use an application security group) on port 5432, not 10.20.0.0/16.
Examination
First check your map above. Then answer four drills and two realistic situations. Write your own answer before revealing each explanation.
C. A /24 is 256 addresses, and Azure reserves five of them — the first, the last, and three for its own gateway and DNS plumbing — leaving 251. B is the answer from classic on-premises networking, where only two are lost; it is the trap for anyone who learned subnetting before the cloud. The five-address reservation is small, but on a tightly sized subnet it is exactly the margin that turns "room for a few more machines" into "renumber everything."
A. Next hop None discards traffic to that destination. The NSG can allow a packet while a route still prevents delivery. Traffic can clear every security rule and still never leave, which is why effective routes is the blade you open once effective security rules already look clean. B misstates how NSGs evaluate — lowest priority number first, not creation order, the fact from Drill 03. C invents a hidden behaviour: an ASG is only a label an NSG rule can reference, nothing more, and it cannot act on its own. D ignores that a route is exactly the kind of silent, ruleless failure the question describes.
Lowest-number-first with first-match, internet denied by default, and lower numbers override higher. The two false statements are the dangerous ones: the default rules cannot be deleted — only outranked by a lower-numbered rule, which is a safety net — and an NSG attaches to a subnet or a network interface, most usefully the subnet so one fence guards everything inside. Miss the first-match rule and you will write a deny that a lower-numbered allow silently swallows, which is the next drill.
NSG inbound — campux mgmt subnet
Pri 100 Allow RDP 3389 source: Any
Pri 200 Allow HTTPS 443 source: Internet
Pri 300 Deny RDP 3389 source: Any
Priority 100. Because Azure evaluates lowest-number-first and stops at the first match, the Allow RDP at 100 matches inbound RDP and wins — the Deny at 300 is never reached. D is the seductive misreading: the deny looks protective, but a rule that never gets evaluated protects nothing. If the VM also has a public IP and no other control stops it, internet clients can reach RDP on that VM.
Consider the consequence. Management ports exposed to Any are among the most-scanned, most-brute-forced targets on the internet; this one line is how a network is compromised within hours of going live. The fix is not to add another deny — it is to delete the broad allow and, if RDP is needed at all, permit it only from a specific known address, or reach the box a safer way entirely. Reading rules in priority order, not top-to-bottom, is the skill this drill trains.
"For a day" is how permanent holes are born. The rule that opens 3389 to Any tonight is the rule still open next quarter, because closing it depends on someone remembering, and management ports exposed to the whole internet are scanned and attacked within hours — not days. The promise is sincere and irrelevant; the risk lands long before anyone forgets to keep it.
Refuse the shape, not the need. The developer needs to reach a machine, which is reasonable; opening it to the planet is not the only way. If a temporary rule is truly warranted, scope it to their specific source address, never Any — a fence with one named gate, not a missing wall.
Offer the real answer. Reach the box without a public port at all: a bastion host that brokers the connection through the portal, or just-in-time access that opens the port to one address for a fixed window and closes it automatically. The good version of "for a day" is a mechanism that expires on its own, not a human promising to undo a risk they can already no longer see.
Grant the appeal, then show what it costs. One subnet is fewer objects, true. But a subnet is the boundary where security attaches, so collapsing three trust levels into one throws away the very line you would need to say "the database may be reached only by the web tier." A single subnet-level rule set is harder to use for different tiers, although interface-level NSGs and host controls can still restrict individual machines.
Name the concrete failure. In one flat subnet, a compromised web server may be able to reach the database or management VM if their effective rules allow it. Separate subnet-level NSGs make those tier boundaries easier to apply and audit. Separate subnets with deliberately configured NSGs can make a breach of the web tier face a blocked path to the data tier — the blast-radius thinking from Class Seven, applied to the network.
Reframe "simple." Three subnets divided by role is not more complex; it is complexity placed where it does work. The plat is drawn once and enforced automatically thereafter, whereas a flat network is simple only until the first incident, when its simplicity is exactly what makes the incident total. Survey by trust level, and simplicity and safety stop being in tension.
What you can now explain
- A VNet is a regional private address space; subnets divide that space by purpose.
- A /24 has 256 addresses; Azure reserves five, leaving 251 assignable.
- Separate subnets alone do not isolate traffic. Check the attached NSGs and their effective rules.
- For a matching NSG rule, the lowest priority number wins first. Remove obsolete broad allows after the immediate fix.
- Routes decide the next hop; Bastion needs its own dedicated subnet, and the managed VM should not keep an exposed RDP port.
Carve a VNet into subnets that make sense, and say what an NSG does and does not protect.
Play the lesson above to stamp this class.