NSG question

[samabc]

Question:

Your company has an Azure subscription that contains the following resources:
Virtual Machine Connected to subnet
TD1 10.0.1.0/24
TD2 10.0.2.0/24

TD2 allows ICMP in its inbound Windows firewall.

You create a network security group named TDNSG1 and add the following inbound security rules:
Priority Source Destination Protocol Port Action
300 10.0.1.0/24 10.0.2.0/24 TCP Any Allow
310 Any 10.0.2.0/24 TCP Any Deny

You execute an Azure Network Watcher Connection Troubleshoot operation for port 443.

The image shows that traffic over port 443 from TD1 to TD2 is Unreachable.

It appears that if TDNSG1 were associated with TD2 then that traffic would be allowed. Since TD1 cannot reach TD2 over port 443, it looks like that TDNSG1 is not being used.

However, the answer to the question states that TDNSG1 is associated with the network interface of TD2.

Please explain, thanks.

[JR-TutorialsDojo]

Hi samabc, thanks for reaching out.

While the Connection Troubleshoot result shows that traffic over port 443 from TD1 to TD2 is unreachable, this does not necessarily indicate that TDNSG1 is not associated with TD2. The inbound rules defined in TDNSG1 specifically target traffic destined for the 10.0.2.0/24 subnet, which is where TD2 resides. This suggests that TDNSG1 is intended to filter inbound traffic to TD2 and is likely associated with either its network interface or subnet.

If TDNSG1 were instead associated with TD1, the defined rules would not apply, as the destination would not match the rule criteria. Additionally, the successful ICMP connection from TD1 to TD2 supports the conclusion that both virtual machines are within the same virtual network and that TDNSG1 is actively filtering traffic to TD2.

The priority 310 deny rule applies exclusively to TCP traffic and does not affect ICMP protocols, which is why ICMP connectivity remains successful. The unreachable status for TCP port 443 is likely due to TD1 not being configured to listen for incoming connections on that port.

I hope this helps! Let us know if you need further assistance.

Best regards,
JR @ Tutorials Dojo

[samabc]

Hi JR, Thank you for this explanation but I still don’t understand.

I don’t think there is any question that TDNSG is not associated with TD1. I think the question really has to do with if it is associated with TD2.

Rule 300 specifically allows TCP traffic from TD1 to TD2 over any port – yet the image shows that traffic over port 443 from TD1 to TD2 is unreachable.

I would think that if rule 300 were being respected (by either machine, actually) that traffic would be allowed. But since that traffic is not allowed it makes me think that TDNSG1 is not being used.

> The unreachable status for TCP port 443 is likely due to TD1 not being configured to listen for incoming connections on that port.

If there are external factors influencing communication between the machines then the question about TDNSG would seem to be unanswerable.

Is it a true statement that if both machines are configured correctly to allow communication, and rule 300 is being respected by TD2, than TCP traffic should be allowed between TD1 and TD2?

• This reply was modified 6 months, 3 weeks ago by  samabc.

[JR-TutorialsDojo]

Hello samabc,

To clarify, yes, if both TD1 and TD2 are properly configured to allow communication, and TDNSG1 is actively associated with TD2, then rule 300 should allow TCP traffic from TD1 to TD2 over any port, including port 443. That rule explicitly permits traffic from 10.0.1.0/24 to 10.0.2.0/24 using TCP on any port, and it has a higher priority than the deny rule.

The fact that the Connection Troubleshoot result shows traffic as unreachable does raise a valid question. However, it doesn’t necessarily mean that TDNSG1 is not associated with the network interface of TD2.

It’s also important to pay close attention to explicit details in the scenario. For example, the statement “TD2 allows ICMP in its inbound Windows firewall” is clearly mentioned, which helps explain why ICMP traffic succeeds. In contrast, there is no mention of port 443 being allowed or selected as one of the inbound ports in the scenario. Even if the NSG permits traffic, the Windows firewall or the application itself must also be configured to accept connections on that port.

If all configurations are correct and TDNSG1 is associated with TD2, TCP traffic should be allowed as per rule 300. The key takeaway is that NSG rules alone don’t guarantee connectivity; they simply permit it. The actual success of a connection also depends on the destination VM being ready to accept it.

I hope this provides more clarity. Let us know if you need further assistance.

Best regards,
JR @ Tutorials Dojo

[samabc]

> The key takeaway is that NSG rules alone don’t guarantee connectivity; they simply permit it

This means you are asking the student to guess about unnamed configurations and externals, which the student can not possibly know.

I believe this question needs to be reworded and the student needs to be given all the information they need to make a definitive answer.

Thanks,
Sam

[JR-TutorialsDojo]

Hi samabc,

Take note that there are questions in the actual exam that are difficult, tricky, and ambiguous. You have to be prepared to look for specific keywords or key phrases in order to find the most suitable answer. This is the style that we are trying to mimic in our practice tests. Some of the questions do not explicitly show the obvious keywords or phrases that will easily point to the answer.

Let us know if you need further assistance. The Tutorials Dojo team is dedicated to help you pass your exam on your first try!

Regards,
JR @ Tutorials Dojo

[moeman]

Hi, just a follow up to this question.

How do you know that TDNSG1 is associated with the NIC of TD2, and not the subnet of TD2?

Thank you!

• This reply was modified 6 months, 2 weeks ago by  moeman.

[JR-TutorialsDojo]

Hello moeman,

Thank you for reaching out.

The rules for the NSG specifically apply to TCP traffic and do not explicitly address ICMP. However, since the ICMP test is successful, this implies that the NSG does not block ICMP traffic. This behavior suggests that the NSG is enforced at the NIC level, where ICMP traffic is implicitly allowed because there are no deny rules for that protocol.

I hope this helps! Feel free to reach out if you need further assistance.

Best regards,
JR @ Tutorials Dojo

[moeman]

Thank you again,

Sorry 1 more questions, could the NSG be at the subnet level, and there are no NIC NSGs?
This way the the ICMP test would still work.

Kind regards,

[JR-TutorialsDojo]

Hello moeman,

Yes, NSG can be associated only at the subnet level, with no NSG assigned to the NIC.

Regards,
JR @ Tutorials Dojo

[asimoomatia]

I also have a query on this question. I understand and follow the reasoning provided: “Connection Troubleshoot result shows that traffic over port 443 from TD1 to TD2 is unreachable, this does not necessarily indicate that TDNSG1 is not associated with TD2”.

However I do not understand what allows one to conclude that TDNSG1 is associated with TD2. To my mind, if we assume that the unreachable status for tcp port 443 is simply due to TD2 not listening on that port, then the observed Network connection monitor results (pass for ICMP, fail for 443) would apply regardless of whether TDNSG1 was associated with TD2 or not. So what am I missing here? What is it that allows us to conclude that TDNSG1 is definitely associated with TD2?

Thanks

• This reply was modified 3 weeks, 5 days ago by  asimoomatia.
• This reply was modified 3 weeks, 5 days ago by  asimoomatia.

[JR-TutorialsDojo]

Hello asimoomatia,

Thank you for sharing your thoughts on this item.

What allows us to conclude that TDNSG1 is associated with TD2 is the way the scenario is constructed: the NSG rules explicitly reference 10.0.2.0/24 as the destination. NSGs only filter traffic when they’re applied to a subnet or NIC. Since the rules are scoped to TD2’s subnet, the only way those rules would be evaluated is if TDNSG1 is indeed associated with TD2’s NIC (or its subnet).

Please refer to this: https://learn.microsoft.com/en-us/azure/virtual-network/network-security-group-how-it-works

I hope this helps! Let us know if you need further assistance.

Regards,
JR @ Tutorials Dojo

[asimoomatia]

Hi,

Thank you for your reply. W.r.t. “the only way those rules would be evaluated is if TDNSG1 is indeed associated with TD2’s NIC (or its subnet)” – what has allowed you to conclude that the rules would be evaluated? As per my understanding the network watcher tests would be the same even if TDNSG1 wasn’t attached to TD2?

I’ll outline my thinking, perhaps this will help pinpoint where i’m getting confused:

1. Say TDNSG1 is setup as per question with TCP allowed between TD1 and TD2

2. In my scenario TDNSG1 is NOT explicitly attached to TD2

3. TD2 is not configured to listen to port 443 (as per the suggested root cause of TCP traffic not being reachable)

In the above scenario I think network watcher test for ICMP would still be successful and the test for TCP connectivity would still fail even though TDNSG1 is not associated with TD2 – meaning I am not able to able to determine “TDNSG1 is associated with the network interface of TD2”. Have I misunderstood something / am I overlooking some info in the question?

Thanks!