HOTSPOT - You implement the planned changes for NSG1 and NSG2. For each of the following statements, select Yes if the statement is true. Otherwise, select No. NOTE: Each correct selection is worth one point. Hot Area:
I think the Answers should be: YYN
VM1 has inbound rules, so no restriction on outbound.
VM2 has outbound rules, so no restrictions on inbound.
Hence VM1 can establish RDP to VM2.
VM2 —ping—> VM3: Yes(no restriction other than outbound RDP)
VM2 —RDP—> VM3: No(outbound RDP is not allowed on VM2)
Please correct me if I am wrong.
Tmrw I have my exam.
I agree that is YYN:
1-The rule is configured inbound from VM1 and VM2 will allow the traffic because of stateful firewall inspection, the traffic is allowed to come in. If the traffic is initiated from VM2 them it wouldn't work.
2-ping will be allow because the vnets are already peered
3-No, traffic is initiated from VM2 and the outbound rule will block it.
Feel free to correct me if I am wrong.
Ill say Y Y Y
Vnet 2 and 3 are peered so NGS shouldnt consider them different Vnet to apply restrictions unless you block the traffic
https://blog.aelterman.com/2021/01/08/defaulting-azure-virtual-network-peering-from-allowing-to-denying-traffic/
From VM1, you can Esablish a Remote Desktop sesion to VM2: Yes
They are in the same subnet and VM1 doesn't have restriction on outbound and VM2 doesn't have restriction on inbound
From VM2, you can ping VM3: No
Rule 400 only permit ping from 10.0.2.0/24 to 10.0.1.0/24. VM3 has 172.16.1.4 IP address
From VM2, you can establish a Remote Desktop sesion to VM3: No
Rule 200 only permit virtualNetwork (VNET1) destination RDP and VM3 is in VirtualNetwork VNET2
Sorry I can't update the answer and I have to make a new post:
Finaly I think is : YYN
From VM1, you can Esablish a Remote Desktop sesion to VM2: Yes
They are in the same VNET and VM1 doesn't have restriction on outbound and VM2 doesn't have restriction on inbound
From VM2, you can ping VM3: Yes
Rule 400 only permit ping from 10.0.2.0/24 to 10.0.1.0/24. VM3 has 172.16.1.4 IP address, but there are implicit rules: any(port) any(protocol) virtualnetwork(source) to virtualnetwork (destination). The VNETs are peered and ping works.
From VM2, you can establish a Remote Desktop sesion to VM3: No
Rule 200 blocks RDP traffic
N - There is an TLS handshaking process to establish an RDP connection between 2 VMs.
Both inbound and outbound rules must allow TCP protocol && Port 3389 (default for RDP) to open for both VMs.
Inbound itself (or outbound itself) is not enough for the connection because of the handshake steps.
Y
N
In Existing Environment section, it said "No network security groups (NSGs) are associated to the network interfaces or the subnets.".
Then, in planned changes section, NSG1 is attached to VM1's NIC and NSG2 is attached to VNET1/Subnet2. Thus, VM3 has no NSG attached to its NIC nor its subnet. There is no single inbound rule allow any traffic.
I tested in Lab. From VM2, you can NOT ping VM3 AND you can NOT establish a Remote Desktop session to VM3.
So, my answer is YNN.
1. From VM1, you can establish a Remote Desktop session to VM2.
No because NSG2 outbound rule will prevent the RDP connection
2. From VM2, you can ping VM3.
Yes because No rules prevent this ping.
3. From VM2, you can establish a Remote Desktop session to VM3.
No because NSG2 prevent his RDP connection
"1. From VM1, you can establish a Remote Desktop session to VM2.
No because NSG2 outbound rule will prevent the RDP connection"
You're wrong! It's only outbound rule attached to Subnet2 (which contains only VM2). So from VM2 this rule indeed would block RDP connection to VM1 (or any other), but from VM1 it doesn't apply, as then it's inbound rule from VM2(subnet2) perspective.
When there is no restriction means that default it is allowed.
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview#default-security-rules
https://learn.microsoft.com/en-us/azure/virtual-network/network-security-groups-overview#default-security-rules:~:text=You%20can%27t%20remove%20the%20default%20rules%2C%20but%20you%20can%20override%20them%20by%20creating%20rules%20with%20higher%20priorities.
No: Traffic is allowed from NSG1 but blocked by NSG2
VM1-->--NGS1--X--NSG2----VM2
Yes: No rules applied; networks are peered
VM2-->--NSG2-->--VM3
No: NSG2 blocks traffic by the very same rule tha blocks from VM1 (same ip range)
VM2--X--NSG2----VM3
Seeing so many conflicting answers, I tested this in my lab.
Initially, without testing, my answer was No, Yes, No but I was surprised with the test results.
I have basically replicated the scenario given and double checked that everything was configured correctly. Here are the results:
- From VM1, I can RDP into VM2
- From VM2, I can ping VM3 (only if I disable Windows Firewall) - not sure what the state of the firewall is on this VM but I assume it's off because the question focuses on the NSG rules and your understanding of them.
- From VM2, I can establish a RDP session to VM3.
Therefore, I would say the answer is Y, Y, Y.
If you wonder why the NSGs don't apply, is because the traffic is not leaving the VNETs since they are peered, so everything is considered "internal" traffic just like if the VMs were on the same VNET/Subnet.
The only point that you can argue is Box2, where if you don't intentionally disable Windows Firewall or allow ICMP on the VM itself, the answer would be NO as ping is blocked by default in Windows Firewall, so you need to take your chances here. Either read the question as if they were testing your understanding of the NSGs and how the rules would apply given the scenario in question, or read it like a sysadmin would and don't make assumptions. For instance, if they don't say Windows Firewall is off on VM3 then assume it's not as the default configuration has all firewall profiles turned on.
Y/Y/Y if you make an assumption and turn off Windows Firewall or Y/N/Y if you don't assume anything.
NSG Rules :
NSG1 (VM1 Level)
vm1 can be pinged by any servers in Vnet
vm1 cannot accept RDP from vnet1/subnet2 (vm2) [vm2 to vm1 not possible]
---------
NSG2 (Subnet Level ) [10.0.2.0/24]
vm2 cannot RDP any server [Source : 10.0.0.0/16]
vm2 can ping vm1
-------------
Q1.From VM1 to VM2 (RDP) : No [blocked by NSG2]
Q2. VM2 to ping Vm3 : No NSG rule, but 2 different Vnet1 to Vnet2
as per Default NSG Rules : Yes
Q3.vm2 to vm3 (RDP) : No [blocked by NSG2]
Given Answer is Correct...
Box1 = NO, here's why VM1 cannot connect to VM2. Let's check the data flow rules. Vnet1 and Vnet2 are peered so they can communicate between them. NSG1 is tied to VM1's NIC; NSG1 will block RDP connections attempts originated from [vnet1/subnet2]; that is an inbound rdp block rule on VM1, so nobody from subnet2 can RDP to VM1, however that's not what we are looking for. Now let's check NSG2: it is tied to [vnet1/subnet2] so it applies to VM2. NSG2 is blocking RDP connection attempts orignitated form the whole VNET1 (10.0.0.0/16 includes the following range: 10.0.0.0-->10.0.255.255) so RDP packet will never reach VM2.
A voting comment increases the vote count for the chosen answer by one.
Upvoting a comment with a selected answer will also increase the vote count towards that answer by one.
So if you see a comment that you already agree with, you can upvote it instead of posting a new comment.
humnahibataynge
Highly Voted 2 years, 4 months agopythonier
2 years, 4 months agohumnahibataynge
2 years, 4 months agodejedi
1 year, 4 months agoPanapi
1 year, 10 months agoqwerty100
Highly Voted 2 years, 3 months agoqwerty100
2 years, 2 months agoqwerty100
2 years, 2 months agoSeMo0o0o0o
Most Recent 3 months agoDiligentSam
2 months, 2 weeks ago155e6a0
3 months, 1 week agoFatFatSam
3 months, 2 weeks ago23169fd
7 months agoGrycek10
5 months, 2 weeks agoWeepingMaplte
7 months, 2 weeks agomkhlszf
8 months, 1 week agoAmir1909
9 months, 3 weeks agotashakori
10 months ago[Removed]
1 year ago[Removed]
1 year agoFr3ggel
1 year, 2 months agoDBFront
1 year, 2 months agoViggy1212
1 year, 3 months agosardonique
1 year, 3 months agorodrigo2186
1 year, 4 months agoKverma7
1 year, 4 months agoJosete1106
1 year, 5 months ago