Allow Gateway Transit on VirtualNetworkB for Point-to-Site Access

AZ-104 By islever Editorial Last updated

Configure secure access to virtual networks Configure and manage virtual networks in Azure

Short answer

B Allow gateway transit belongs on VirtualNetworkA, not B; VirtualNetworkB needs Use remote gateway, and the Windows P2S client must be reinstalled.

Question

Note: The question is included in a number of questions that depicts the identical set-up. However, every question has a distinctive result. Establish if
the solution satisfies the requirements.
Your company's Azure subscription includes two Azure networks named VirtualNetworkA and VirtualNetworkB.
VirtualNetworkA includes a VPN gateway that is configured to make use of static routing. Also, a site-to-site VPN connection exists between your company's on-
premises network and VirtualNetworkA.
You have configured a point-to-site VPN connection to VirtualNetworkA from a workstation running Windows 10. After configuring virtual network peering between
VirtualNetworkA and VirtualNetworkB, you confirm that you are able to access VirtualNetworkB from the company's on-premises network. However, you find that
you cannot establish a connection to VirtualNetworkB from the Windows 10 workstation.
You have to make sure that a connection to VirtualNetworkB can be established from the Windows 10 workstation.
Solution: You choose the Allow gateway transit setting on VirtualNetworkB.
Does the solution meet the goal?
  1. Yes
  2. No Correct Answer

Key Takeaways

The question tests which side of a VNet peering receives each gateway setting, and the trap is assuming 'Allow gateway transit' can be enabled on the remote (gateway-less) network to fix a P2S connectivity failure.

In Azure point-to-site (P2S) VPN peering scenarios, gateway routing only flows when 'Allow gateway transit' is enabled on the VNet that owns the VPN gateway and 'Use remote gateway' is enabled on the peered VNet. The proposed fix inverts those settings, so the Windows 10 workstation still cannot reach VirtualNetworkB.

Common mistake: Choosing 'Yes' (option A) — learners assume that enabling a gateway setting on VirtualNetworkB automatically extends the VirtualNetworkA VPN gateway to it, ignoring that gateway transit is always offered by the network that hosts the gateway.

Expert Analysis

Why the Answer Is Correct

The solution does not meet the goal, so the answer is B (No). 'Allow gateway transit' is an option that can only be meaningfully enabled on the VNet that actually hosts the VPN gateway — here VirtualNetworkA — while VirtualNetworkB must have 'Use remote gateway' selected so it consumes that gateway. Applying 'Allow gateway transit' on VirtualNetworkB is a setting that has no effect on how the VirtualNetworkA gateway routes P2S clients, and it may even be unavailable or rejected when VirtualNetworkB has no gateway of its own. Additionally, as several commenters point out, after any peering topology change the Windows P2S VPN client package must be downloaded and reinstalled so the updated route table is applied on the workstation.

Why the Other Options Are Wrong

Option A (Yes) is wrong because a single setting on VirtualNetworkB cannot accomplish what the goal requires: the gateway that serves the Windows 10 P2S client lives in VirtualNetworkA, so no configuration on the peered network can substitute for correct transit/remote-gateway pairing. The statement in the scenario that on-premises access to VirtualNetworkB already works indicates the peering's gateway-transit/remote-gateway options and 'Allow forwarded traffic' are already functioning, which further confirms the real gap is on the client side (the stale VPN client package), not on VirtualNetworkB's peering settings. Enabling 'Allow gateway transit' on a network without a gateway neither advertises routes to VirtualNetworkB nor refreshes the client's route table, so connectivity from Windows 10 remains broken.

Community Comment Notes

The community is essentially unanimous that the answer is No. Quantigo cites the official guidance that "If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again", while eduardovzermeno and thalasi both state that "Allow gateway transit" belongs on VirtualNetworkA and VirtualNetworkB needs "Use remote gateways" enabled. Ponpon3185 observed that because on-premises traffic already reaches VirtualNetworkB, "Traffic forwarded is enable" on the peering, and cosmicT73 drew the same conclusion — the remaining step is reinstalling the P2S client. Note that d0bermannn's observation that existing point-to-site connections "need to be recreated" after reconfiguring peering points to the same client-side refresh.

Official Reference

These links open the official vendor documentation in a new tab.

Exam Strategy

In peering + VPN case studies, first identify which VNet owns the gateway: gateway transit is offered by that VNet, and the peer must select 'Use remote gateway'. Remember that changing peering topology invalidates Windows P2S client packages — if gateway settings already appear correct, the fix is reinstalling the client, so a single-setting 'solution' is almost always No.

Frequently Asked Questions

Why is enabling Allow gateway transit on VirtualNetworkB wrong for a P2S client?

Gateway transit is offered only by the VNet that hosts the gateway (VirtualNetworkA). VirtualNetworkB has no gateway to offer, so it must instead select 'Use remote gateway' to reach networks through VirtualNetworkA's gateway.

If on-premises users can already reach VirtualNetworkB, what is actually blocking the Windows 10 workstation?

The peering gateway settings are already working. The P2S VPN client package must be downloaded and reinstalled after the peering change so the client receives the updated route configuration.

More AZ-104 FAQ →

Discussion 19 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 19

  1. d0bermannn 👍 36
    After reconfiguring \ creating peering existing point-to-site VPN connections need to be recreated
  2. Quantigo 👍 34
    Answer B - No If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client. https://docs.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing Thanks for indicating Yes or NO!
  3. Madbo 👍 6
    The solution proposed in this scenario is incorrect. Enabling the "Allow gateway transit" setting on VirtualNetworkB would not help establish a connection to VirtualNetworkB from the Windows 10 workstation. To enable the connection, the "Use remote gateway" setting should be enabled on the point-to-site VPN configuration for VirtualNetworkA. This would allow the Windows 10 workstation to use the VPN gateway on VirtualNetworkA to access resources on VirtualNetworkB. Therefore, the correct answer is B. No.
  4. mdmdmdmd 👍 5
    If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again"
  5. Takloy 👍 5
    You're right. almost forgot about this. whenever you made some changes on the azure network, you basically need to download the P2S client again for the client devices.
Show 14 more comments
  1. NaoVaz 👍 4 Answered B
    "If you make a change to the topology of your network and have Windows VPN clients, the VPN client package for Windows clients must be downloaded and installed again in order for the changes to be applied to the client."
  2. eduardovzermeno 👍 3 Answered B
    The "Allow gateway transit" has to be setting on "VirtualNetworkA". "VirtualNetworkB" needs “Use remote gateways” enabled.
  3. edengoforit 👍 2
    Site-to-Site (IPsec/IKE VPN tunnel) configurations are between your on-premises location and Azure. This means that you can connect from any of your computers located on your premises to any virtual machine or role instance within your virtual network, depending on how you choose to configure routing and permissions. It's a great option for an always-available cross-premises connection and is well suited for hybrid configurations.
  4. thalasi 👍 2 Answered B
    Enabling Allow gateway transit on VirtualNetworkB (the peered VNet) is the wrong setting To let a P2S client on VirtualNetworkA reach VirtualNetworkB you must: Enable Allow gateway transit on the VNet that actually has the gateway (VirtualNetworkA). Enable Use remote gateways on the peered VNet (VirtualNetworkB).
  5. Ponpon3185 👍 2 Answered B
    It' seems Trafic forwarded is enable: " After configuring virtual network peering between VirtualNetworkA and VirtualNetworkB, you confirm that you are able to access VirtualNetworkB from the company's on-premises network"...so it seems that the issue is not here.
  6. cosmicT73 👍 2
    I think since the on-prem network can access network B, then those two gateway settings must be already enabled, so the only thing left is to ensure that the VPN client is downloaded and installed again
  7. orion1024 👍 2
    After changing topology the azure vpn client must be reinstalled to include the new topology information.
  8. Watcharin_start 👍 1
    "you confirm that you are able to access VirtualNetworkB from the company's on-premises network. However, you find that you cannot establish a connection to VirtualNetworkB from the Windows 10 workstation." it mean, you have completed setting up with Allow gateway transit option in Network-A and used Use remote gateway option in Network-B already. You just need to restart/reinstall VPN client on your specified host. If you change option in Network-B to Allow gateway transit, it will destroy your routing.
  9. OlivierLumeau 👍 1 Answered B
    The proposed solution ("Allow gateway transit") alone isn't sufficient. You must download and re-install the VPN client configuration package on the Windows 10 workstation to resolve this issue. That's why the answer is "No."
  10. Miguel Angel 👍 1 Answered B
    Allow gateway transit solamente se puede habilitar en la VNet que posee la gateway, en este caso VirtualNetworkA, y activarlo ahi no cumple con el objetivo por si sola
  11. Bugati 👍 1
    can anyone help me with how much topics are there in exaptopics for az-104 and how many questions are there in each topic
  12. dhivyamohanbabu 👍 1
    Option B is correct
  13. EmnCours 👍 1 Answered B
    Correct Answer: B
  14. NicoVick 👍 1 Answered B
    b is correct

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.

Submitted for moderation before publishing. Keep it helpful and respectful.

Enable SSPR for Entra Identities

S-grade

Assigning Fabric Licenses in Entra ID Free Tenant

S-grade

Which Certificate from Vault1 for WebApp1 TLS?

S-grade

Does Storage Account Encryption Scope Contributor Role Allow Key Regeneration?

S-grade

Practice All AZ-104 Questions

Access 100 questions with complete answers and detailed explanations.

View Full AZ-104 Practice Test →

← Back to AZ-104 Study Guide