Azure VNet Peering Gateway Transit and Traffic Blocking Analysis

AZ-700 By islever Editorial Last updated

Design and implement VNet connectivity and routing

Short answer

The correct evaluation is Yes, Yes, No. VM1 can reach VM4 via the site-to-site gateway chain; VM2 uses VNet1's gateway via remote gateway settings; VM1 cannot communicate with VM5 due to blocked traffic and lack of transitive peering.

Question

HOTSPOT
You have the Azure environment shown in the exhibit.
[sampleXML/xmlfile-28_1.jpg]
You have virtual network peering between Vnet1 and Vnet2. You have virtual network peering between Vnet4 and Vnet5. The virtual network peering is configured
as shown in the following table.
[sampleXML/xmlfile-28_2.png]
For each of the following statements, select Yes if the statement is true. Otherwise, select No.
Hot Area:
[sampleXML/xmlfile-29_1.png]

Key Takeaways

Tests understanding of 'Allow Gateway Transit' and 'Use Remote Gateway' chaining versus 'Block all traffic' and the non-transitive nature of VNet peering.

Determines if VMs can communicate across peered VNets with gateway transit and block settings. The answer is Yes, Yes, No based on Azure networking rules.

Common mistake: Learners often assume VNet peering is transitive, believing that if A peers to B and B peers to C, A can talk to C. This is false. They also misinterpret 'Block all traffic' as only affecting inbound traffic, whereas it affects traffic originating from the protected VNet.

Expert Analysis

This question tests the mechanics of Azure Virtual Network (VNet) peering, specifically focusing on gateway transit, remote gateways, and traffic blocking settings. The environment contains two distinct peering pairs: VNet1-VNet2 and VNet4-VNet5, with no direct peering between these groups.

The first statement asks if VM1 can reach VM4 via a site-to-site connection. VNet1 has 'Allow Gateway Transit' enabled, meaning it shares its VPN gateway for traffic destined to peers. VNet2 has 'Use Remote Gateway' enabled, directing its outbound traffic through VNet1's gateway. Since VNet1 is connected to VNet3 (presumably via another gateway or route), and assuming the exhibit shows a path from VNet1 to VNet4 (often implied in these hotspots as VNet1 being the hub or connected to the on-premises network which connects to VNet4), the traffic flow relies on the gateway chain. However, the critical logic often tested here is whether the gateway transit works across non-adjacent peerings. In this specific exam pattern, if VNet1 is the gateway provider for VNet2, and VNet1 also has connectivity to the network segment where VNet4 resides (or if VNet1 is peered to VNet3 which holds the gateway to VNet4), communication is possible. The comments confirm that VM1 can reach VM4 because the gateway transit allows VNet2 to use VNet1's gateway, effectively bridging the networks if the underlying connectivity exists.

The second statement asks if VM2 can reach VM4 using VNet2's gateway. This is true because VNet2 is configured to 'Use Remote Gateway,' pointing to VNet1's gateway. Therefore, any traffic originating from VNet2, including that destined for VNet4, is routed through VNet1's gateway infrastructure. If VNet1 has a path to VNet4 (e.g., via another peering or on-premises link), the traffic flows.

The third statement asks if VM1 and VM5 can communicate. VNet4 and VNet5 are peered, but VNet5 has 'Block all traffic to the remote virtual network' enabled. This setting prevents traffic originating from VNet5 from reaching VNet4. While return traffic might technically be allowed depending on stateful inspection, the prompt implies general communication capability. More importantly, there is no peering between the VNet1/2 group and the VNet4/5 group. Even if routing existed, the 'Block' setting on VNet5 prevents VNet5 from initiating traffic to VNet4. Furthermore, without a direct peering or transitive routing path (VNets do not support transitive peering), VM1 cannot reach VM5 directly. The consensus answer YYN reflects that while the gateway chain works for the first two, the isolation/blocking and lack of transitive peering prevent VM1-VM5 communication.

Official Reference

https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering

This link opens the official vendor documentation in a new tab.

Exam Strategy

When evaluating VNet peering scenarios, always draw the topology. Check for three things: 1) Is there a direct peering? (No transitivity). 2) Are gateways involved? If so, check 'Allow Gateway Transit' on the source side of the transit and 'Use Remote Gateway' on the destination side. 3) Are there NSGs or Peering settings like 'Block all traffic' that explicitly deny the flow. Trace the packet from source to destination step-by-step.

Frequently Asked Questions

Does VNet peering support transitive routing?

No. VNet peering is not transitive. If VNet A peers with VNet B, and VNet B peers with VNet C, VNet A cannot communicate with VNet C unless they are directly peered.

What does 'Block all traffic to the remote virtual network' do?

It prevents traffic originating from the local VNet from flowing to the peered remote VNet. It is useful when you want to disable communication temporarily without deleting the peering.

How do Allow Gateway Transit and Use Remote Gateway work together?

Allow Gateway Transit must be enabled on the VNet hosting the gateway (VNet1). Use Remote Gateway must be enabled on the peered VNet (VNet2) that needs to send traffic through that gateway.

More AZ-700 FAQ →

Discussion 35 contributions

Compiled from public community threads and reader submissions, lightly edited for clarity. Handles and vote tallies are shown as recorded, and comments reflect the views of individual contributors.

From public community threads 30 of 35

  1. Anonymous learner 👍 31
    YYY / tested in lab VM1 and VM5 can communicate. 'Traffic to remove virtual network : Block' setting in Vnet5 does not block communication between VM5 and GW4, while it blocks communication between VM5 and VM4.
  2. Alessandro365 👍 12
    YYY, tested in lab. vnet5 peering is disabled, but remote gateway is enabled, allowing the vm5 to be accessed from other vnets. Only VM4 cannot access VM5 (peering blocked). Note that BGP needs to be configured, user routes does not work.
  3. sam881989 👍 10
    The answer is correct it is YYN tested in lab! The remote gateway and allow gateway transit only applies to Vnet peering in this case between Vnet 2 and Vnet 1, and another is between Vnet 4 and Vnet 5. Because the connection between the Vnet 1, 3, and 4 is using BGP no option to set remote gateway and transit gateway. All the routes are forwarded to Vnet 2 and Vnet 5 but because Vnet 5 is blocking the traffic to Vnet 4 VM1 can't reach VM5 but rest all can reach each other.
  4. tester2023 👍 7
    YYN To test the 'block' on the peering between vNet4 and vNet5 I did the following: Deployed two vNets. On the second vNet, I selected the "Block all traffic to the remote virtual network" and the Portal displays "Resources in vnet-2 cannot communicate to resources in the vnet-1" When I do a Connection Troubleshoot test, it fails with "Traffic blocked due to the following network security group rule: DefaultRule_DenyAllInBound". When I set the peering setting to "Allow (default)", the Connection Troubleshoot is successful.
  5. arnaudhelin 👍 7
    Hi everyone, I tried a lot of configuration to test the last point. With wireshark on both sides, and traffic flow always on (ping and http request), the result is quite clear even if it is not logical at the first look. When you choose the option BLOCK on one side, the entire communication is blocked. If you want to have the "expected" behavior (vm4 to vm5 ok but not the other way), you must set a NSG with an explicit rule wich allows the traffic.
Show 25 more comments
  1. mauchi 👍 7
    To me YYN seems correct. I think the last option is a NO, bc the statement says "VM1 and VM5 can communicate" to me it implies a bidirectional communication. And the table states that Vnet 5 blocks traffic going to a differnt vnet, such as vnet1, thus (bidirectional) communication between them its not possible.
  2. Aiwa23 👍 7
    it blocks communication from VNET5 to VNET4 but allows VNET4 to VNET5
  3. A_way 👍 6
    Could you pls clarify? This is referring the vnet peering settings not NSG
  4. geuser 👍 5
    I say YYN No becuase: Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings.
  5. Opala79 👍 3
    I think it would be NNN because the option "Use remote gateway" of VNET 1 is disabled, someone disagrees ?
  6. Verytutos 👍 3
    Appeared on Exam 05 Sep 2023
  7. mm2 👍 2
    YYY: for 3rd: - Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings. When this setting is selected, traffic doesn't flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through a network security group rule that includes the appropriate IP addresses or application security groups.
  8. fourfour 👍 2
    - Select Block all traffic to the remote virtual network if you don't want traffic to flow to the peered virtual network by default. You can select this setting if you have peering between two virtual networks but occasionally want to disable default traffic flow between the two. You may find enabling/disabling is more convenient than deleting and re-creating peerings. When this setting is selected, traffic doesn't flow between the peered virtual networks by default; however, traffic may still flow if explicitly allowed through a network security group rule that includes the appropriate IP addresses or application security groups.
  9. sapien45 👍 2
    How about you read Microsoft documentation for a change ? Instead of expecting being certified by spoonfeeding you the responses : https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-manage-peering Disabling the Block all traffic to remote virtual network setting only changes the definition of the VirtualNetwork service tag. It doesn't fully prevent traffic flow across the peer connection, as explained in this setting description. YYY
  10. Asher 👍 2
    Y = VM 1 can reach VM 4 via site-to-site which will have routing Y = peering on VNET2 is set to use remote gateway and VNET1 is set to use it's gateway for transit N = although VNET4 and 5 are peered, peerings are not transitive so a peering between vnet1 and 5 would be needed for this to work? Block on VNET 5 can be ignored as it won't apply to return traffic only traffic originated from VNET5?
  11. Takloy 👍 2
    YYY For the 3rd question, if you read carefully and look closely to the chart, it means Traffic to remote network from VNET5. Meaning, From VNET5 to any of the remote networks will be blocked but not inbound. This is why the answer is Yes.
  12. Anonymous learner 👍 2
    That's not true. 'Block' option is about NSG's VirtualNetwork tag whether it contains network address of Vnet4 or not. When you choose 'block' and create security rules on VM5's NSG, VM5 still can communicate with resources in Vnet4.
  13. mingorad 👍 2
    correct is YYY ; traffic to remote virtual network is blocked on Vnet5 so from Vnet5 to exterior not from Vnet4 to Vnet5
  14. Rowdy_47 👍 2
    Answer is YYY the "Traffic to remote virtual network" only applies to traffic between peered VNets.
  15. Pratheeshp 👍 2
    How about the the return traffic VNET5 to VNET4 ?
  16. lvz 👍 2
    so what is your find man?
  17. KappiilGupta 👍 1
    What each side is doing VNet1: Allow gateway transit = Enabled means “I have a gateway and I’m sharing it.” Use remote gateways = None means “I use my own gateway, not someone else’s.” VNet2: Use remote gateways = Enabled means “I don’t have a gateway, so I’ll use VNet1’s.” Allow gateway transit = None means “I have nothing to share.”
  18. pattj2 👍 1
    This is correct because going by the possible data flow between the VNets, the three options have to be routed through Vnet1, of which the use of remote's gateway (VNet3 S2S) is not permitted
  19. GokuSS 👍 1
    YYN, for 3rd questions, does this explanation makes sense? "VM1 can reach VM4 through GW1, but not VM5 as VNEt1 does not use remote Gateways."
  20. asdasd123123iu 👍 1
    Agree. We don't have an information that traffic between vm5 and remote networks has been allowed on NSG so by default it will be blocked.
  21. Hullstar 👍 1
    there isn't a peering configuration for VNet3 and the default is not to allow. Wouldn't the answer be NYN
  22. ACSlearning1 👍 1
    How can "VM1 and VM5 can communicate" be yes if "use remote gateway" is set to none on vnet1?
  23. xRiot007 👍 1
    How about the the return traffic VNET5 to VNET4 ? - No need to care about the return
  24. lvz 👍 1
    I think this should be the answer. Someone need to confirm.
  25. TJ001 👍 1
    that is only for peering not for BGP

Reader comments & corrections

No reader corrections yet — spotted an error or have a note? Share it below.

Log in to comment, report an error, or add a note about this question.

Private Endpoint UDR Routing Prerequisite

S-grade

Minimum Azure Service Endpoints for Peered VNets

S-grade

Logging Application of Specific NSG Rules

S-grade

Azure DNS Private Resolver Minimum Deployment

S-grade

Practice All AZ-700 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-700 Practice Test →

← Back to AZ-700 Study Guide