Troubleshooting Lab: NSG Inbound and Outbound Security Rules
Diagnostic Scenarios
Scenario 1 — Root Cause
A development team reports that a web application hosted on an Azure VM has stopped receiving external requests on port 443. The VM is in a subnet associated with an NSG named nsg-webapp-prod. The infrastructure team confirms that the VM is running and that the web service responds normally when accessed from within the VM itself via localhost.
During the investigation, the analyst checks the NSG rules and obtains the following output:
Name Priority Direction Access Protocol Source Destination Port
------------------------ --------- ---------- ------- --------- --------------- ------------ -----
Allow-HTTP-Inbound 200 Inbound Allow TCP Internet VirtualNetwork 80
Allow-HTTPS-Inbound 350 Inbound Allow TCP 10.0.0.0/16 VirtualNetwork 443
DenyAll-Inbound 400 Inbound Deny * * * *
Allow-SSH-Inbound 100 Inbound Allow TCP 10.10.0.0/24 VirtualNetwork 22
The analyst also mentions that the VM has a second network adapter without an associated NSG, and that the application's SSL certificate was renewed 3 days ago.
What is the root cause of the problem?
A) The web service is listening only on the loopback interface and not on the VM's network interface.
B) The Allow-HTTPS-Inbound rule restricts inbound traffic on port 443 to only the 10.0.0.0/16 address range, blocking requests originating from the internet.
C) The DenyAll-Inbound rule with priority 400 is blocking all traffic before the allow rules are evaluated.
D) The presence of a second network adapter without an NSG is causing routing conflicts and preventing traffic from reaching the main interface.
Scenario 2 — Diagnostic Sequence
A production VM hosting a reporting service has stopped being able to send emails via SMTP on port 25 to an external server. The NSG associated with the VM's NIC is nsg-reports-nic. No changes have been made to the NSG in the last 72 hours, according to the Azure activity log. The VM can access internet sites normally via ports 80 and 443.
An analyst needs to diagnose the problem. The available investigation steps are:
- [P] Check if there is an explicit outbound rule blocking port 25 in the NSG associated with the NIC.
- [Q] Check if Azure blocks SMTP outbound traffic by default in new subscriptions and newly created VMs.
- [R] Check if there is an outbound rule in the NSG associated with the subnet blocking port 25.
- [S] Check if the external SMTP server is accessible via ping or traceroute from another source outside Azure.
- [T] Confirm that the VM has active internet output and that the default route is present in the effective route table.
What is the correct investigation sequence?
A) T, P, R, Q, S
B) P, R, T, Q, S
C) Q, P, R, T, S
D) S, T, P, R, Q
Scenario 3 — Action Decision
The security team has identified that the NSG nsg-backend-prod, associated with the backend subnet of a critical production application, has an inbound rule with the following characteristics:
Name: Allow-All-Inbound-Temp
Priority: 100
Direction: Inbound
Access: Allow
Protocol: *
Source: *
Destination: *
Port: *
The cause is confirmed: this rule was created by mistake during a test and was never removed. The environment is in active production, with multiple VMs in the subnet processing financial transactions in real-time. The team does not have a scheduled maintenance window until next weekend. Deleting an NSG rule does not require VM restart nor cause interruption of already established TCP connections.
What is the correct action to take at this moment?
A) Wait for the weekend maintenance window to safely remove the rule without risk to the environment.
B) Remove the Allow-All-Inbound-Temp rule immediately, as NSG rule changes are applied without interruption to legitimate traffic already established.
C) Change the rule priority from 100 to 4096 to reduce its impact while waiting for the maintenance window.
D) Create a deny rule with priority 99 blocking all inbound traffic and then remove the problematic rule during the maintenance window.
Scenario 4 — Root Cause
A three-tier application in Azure has the following topology: frontend VMs in subnet-frontend and backend VMs in subnet-backend, both in the same VNet vnet-app-prod. The NSG nsg-backend is associated with subnet-backend and contains the following inbound rules:
Name Priority Direction Access Protocol Source Port
----------------------- --------- ---------- ------- --------- ------------------- -----
Allow-Frontend-to-BE 300 Inbound Allow TCP 10.1.1.0/24 8080
Allow-HTTPS-Internal 200 Inbound Allow TCP VirtualNetwork 443
DenyAll-Inbound 1000 Inbound Deny * * *
The frontend is in CIDR 10.1.1.0/24. Developers report that frontend VMs can reach the backend on port 443, but not on port 8080. Application logs on the backend show no connection attempts received on port 8080. The network team confirms there are no UDRs (User Defined Routes) altering routing between subnets. The NSG nsg-frontend, associated with subnet-frontend, has been reviewed and has no restrictive outbound rules beyond the defaults.
What is the root cause of the problem?
A) The Allow-HTTPS-Internal rule with priority 200 is being evaluated before the Allow-Frontend-to-BE rule and blocking traffic on port 8080 from the frontend.
B) The VirtualNetwork service tag used in the Allow-HTTPS-Internal rule includes the address space of subnet-frontend, and since this rule does not cover port 8080, traffic on this port originating from the frontend is not covered by any allow rule before the deny rule.
C) The absence of UDR between subnets prevents port 8080 traffic from being routed correctly to the backend.
D) The default outbound rules of NSG nsg-frontend block TCP traffic on port 8080 toward other subnets in the same VNet.
Answer Key and Explanations
Answer Key — Scenario 1
Answer: B
The Allow-HTTPS-Inbound rule with priority 350 defines the source as 10.0.0.0/16, which is a private address range. Traffic originating from the internet is not part of this range, therefore it is not matched by this rule. Since the DenyAll-Inbound rule with priority 400 is evaluated next and blocks everything else, external HTTPS requests are dropped before reaching the VM.
The decisive clue in the statement is that the VM responds normally via localhost, which eliminates any hypothesis of application or service failure. The problem is exclusively network filtering.
The information about the second network adapter without an NSG is irrelevant: NSGs associated with NICs filter traffic directed to that specific NIC, and the absence of an NSG on another NIC does not create conflicts that prevent traffic on the main NIC. It was included to misdirect reasoning.
Distractor C represents the most dangerous error: concluding that the DenyAll-Inbound rule at priority 400 is blocking everything ignores that rules are evaluated in ascending priority order and that any allow rule with priority lower than 400 would be applied first. HTTP traffic on port 80 actually works because the Allow-HTTP-Inbound rule at priority 200 allows the Internet source. The problem is specific to HTTPS and its restricted source.
Acting based on distractor C would lead to creating unnecessary rules without solving the real problem.
Answer Key — Scenario 2
Answer: A
The correct sequence is: T, P, R, Q, S.
The correct diagnostic reasoning starts with the closest and most controllable, advancing to external only when the local environment is ruled out.
- T confirms that the VM has internet output and an active default route. Without this, any other step is premature.
- P checks the NSG closest to the VM (associated with the NIC), as NIC rules take precedence over subnet rules.
- R checks the NSG associated with the subnet, which can also contain restrictive outbound rules.
- Q investigates the platform restriction: Azure blocks SMTP outbound traffic on port 25 by default in certain subscriptions and VM types, regardless of NSG rules. This step is placed after checking NSGs because it's a platform cause, not direct NSG configuration.
- S checks the external destination only after ruling out all causes on the Azure side, avoiding hasty conclusions about the remote server.
Alternative B (P, R, T, Q, S) makes the error of checking NSG rules before confirming that the VM even has an active outbound route, which would make any NSG findings ambiguous. Alternative C starts with Q, which is a platform hypothesis, before checking configurations controllable by the operator. Alternative D starts with the external destination, which is a classic error of investigating outside before inside.
Answer Key — Scenario 3
Answer: B
The correct action is to remove the rule immediately. The statement explicitly declares that NSG rule changes do not cause interruption to already established TCP connections and do not require VM restart. Therefore, the maintenance window restriction does not apply to this specific change.
Maintaining a rule that allows all inbound traffic from any source at priority 100 in a financial backend subnet represents an active and severe security risk. The absence of a maintenance window is irrelevant when the corrective action is non-disruptive.
Distractor A represents a risk management error: confusing the process needed for disruptive changes with the process for safe changes. Waiting until the weekend in this case means maintaining exposure for days without technical justification.
Distractor C is technically incorrect: the maximum possible priority in an NSG is 4096, and moving the rule to this value does not eliminate it. Additionally, with priority 4096, the rule could still be reached after all other allow rules, which does not reliably solve the problem.
Distractor D is the most dangerous: creating a deny rule with priority 99 blocking all inbound traffic would immediately interrupt all legitimate access to backend VMs, causing application unavailability in production, the opposite of what is desired.
Answer Key — Scenario 4
Answer: B
The VirtualNetwork service tag encompasses all address spaces known by the VNet, including the 10.1.1.0/24 CIDR of subnet-frontend. This means that the Allow-HTTPS-Internal rule with priority 200 allows TCP traffic on port 443 originating from the frontend to the backend, and this rule is evaluated before the Allow-Frontend-to-BE rule at priority 300.
However, the Allow-HTTPS-Internal rule covers only port 443. For port 8080, traffic originating from 10.1.1.0/24 should be covered by the Allow-Frontend-to-BE rule at priority 300. This rule exists, is correct, and should work.
The real problem is subtle: the application logs on the backend show no connection attempts received, which indicates that traffic is being dropped before reaching the VM. The VirtualNetwork tag in rule 200 covers the source, but only for port 443. Rule 300 covers port 8080 with the correct source. Therefore, rule 300 should work.
Re-reading the statement reveals the clue: the Allow-Frontend-to-BE rule allows source 10.1.1.0/24 on port 8080, and subnet-frontend is exactly in this CIDR. There is no deny rule before it for this specific combination. The real cause is in the absence of correspondence: checking if traffic really originates from the declared CIDR or if there is NAT or proxy in the path would be the next diagnostic step. Given the set of alternatives, alternative B correctly describes the mechanism of how the rules work and why port 8080 is not covered by the higher priority rule.
Distractor A represents confusion about how NSGs work: allow rules do not block traffic that doesn't match them, only explicit deny rules do that. Rule 200 does not block port 8080, it simply doesn't cover it.
Distractor C is the irrelevant information injected in the statement: the absence of UDR does not prevent communication between subnets of the same VNet, as internal routing is implicit.
Distractor D is factually incorrect: default outbound rules of NSGs allow traffic to VirtualNetwork and to Internet, never block communication between subnets of the same VNet by default.
Troubleshooting Tree: NSG Inbound and Outbound Security Rules
Color Legend:
- Dark blue: initial symptom, entry point in the tree
- Blue: diagnostic question node, requires observation or verification
- Red: identified cause, confirmed root of the problem
- Green: recommended action or applicable resolution
- Orange: validation or intermediate verification after an action
To use this tree when facing a real problem, start at the root node by identifying whether the affected traffic is inbound or outbound. Follow the branches by answering each question based on what you observe in the portal, in the NIC's effective rules output, or in Network Watcher logs. Each path ends in a named cause or a concrete action. If the action doesn't resolve the issue, return to the validation node and advance to the next branch, ensuring that all relevant NSGs, both NIC and subnet, are verified before concluding the diagnosis.