Re-install VPN Client for Peered VNet Access?
Answer
Correct answer: A — Downloading and re-installing the VPN client configuration package updates the P2S client routes to access the peered VirtualNetworkB.
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 download and re-install the VPN client configuration package on the Windows 10 workstation. Does the solution meet the goal?
Community Insight
This question tests P2S VPN routing updates after VNet peering; the common trap is assuming gateway transit settings are missing when they are already proven to work for the on-premises network.
When a Point-to-Site (P2S) VPN topology changes by adding a peered virtual network, Windows clients must download and reinstall the VPN client configuration package to receive updated routes. This page confirms that reinstalling the package allows the P2S client to access the newly peered virtual network.
Choosing 'No' because of confusion over gateway transit configuration, ignoring the fact that the on-premises network already successfully accesses the peered VNet, proving transit is enabled.
Community Discussion (33 comments)
Devendra M
👍 1
Selected: A
Enabling Allow gateway transit on VirtualNetworkA alone does not update the Windows 10 workstation’s VPN routes. Because VNet peering was added after the point-to-site VPN was configured, you must download and reinstall/import the updated VPN client configuration, then reconnect. This supplies the workstation with the routes needed to reach VirtualNetworkB. GitHub The fact that the on-premises network already reaches VirtualNetworkB indicates the gateway transit path is working; the question points to an outdated client configuration.
Belal105
👍 2
Selected: A
I'd keep the answer as Yes. Your point about the gateway settings is correct in general, but the question already shows those settings are in place. Why the peering is already configured The question says on-premises users can already reach VirtualNetworkB through VirtualNetworkA's gateway. That only works if Allow gateway transit is on for VirtualNetworkA and Use remote gateways is on for VirtualNetworkB. Gateway transit isn't limited to site-to-site traffic. It covers all traffic through that gateway, including P2S. Allow forwarded traffic isn't needed for gateway transit. It's for traffic from an NVA or another network being forwarded into the peered VNet. So on the Azure side, P2S traffic can already reach VirtualNetwork
Chris_J
👍 2
Selected: B
A point‑to‑site (P2S) VPN connection terminates on VirtualNetworkA’s VPN gateway, not on VirtualNetworkB. Even though VNet peering exists between A and B, P2S traffic does NOT automatically flow across peered VNets unless: The gateway is configured to allow forwarded traffic, and UseRemoteGateways and AllowGatewayTransit are both configured on the peering. Simply re‑installing the VPN client package does nothing to enable routing to VirtualNetworkB.
3ed32ea
👍 2
Selected: B
The correct answer is B. Reinstalling the VPN client doesn't solve the problem
thalasi
👍 3
Selected: B
The issue is routing between VNets, not the client configuration. Re-downloading and reinstalling the Point-to-Site (P2S) VPN client configuration package on the Windows 10 workstation does not address the root cause of the problem.
biarielo
👍 1
Selected: B
VPN client reinstall solves configuration corruption, not routing issues. Cross-VNET access via P2S requires proper peering settings, not client reinstall. To allow the workstation to reach VirtualNetworkB, you need: Allow gateway transit on VirtualNetworkA (share its VPN gateway). Use remote gateways on VirtualNetworkB (consume that gateway).
thalasi
👍 2
Selected: B
Reinstalling the P2S VPN client on the Windows 10 machine won’t fix this — the issue is routing/gateway transit, not the client package. Enable gateway transit on the VNet that hosts the gateway (VirtualNetworkA): Set the peering from A→B to allowGatewayTransit=true. Enable use of the remote gateway on the peered VNet (VirtualNetworkB): Set the peering from B→A to useRemoteGateways=true.
Sugz
👍 2
Selected: B
Answer is B (No): Client reinstall doesn’t address required route-based gateway + gateway transit configuration VnetB needs to have 'Use Remote Gateway' and P2S address space advertised/ allowed VNetB needs to have 'Route-based VPN Gateway' and Peering: 'Allow Gateway Transit' enabled
abhi_azure_devops
👍 2
Selected: B
Virtual Network Required Setting VirtualNetworkA ✅ Allow gateway transit VirtualNetworkB ✅ Use remote gateway above steps also required to establish connectivity .
AfshinZ
👍 2
Selected: B
on VnetA we need to enable "forward traffic" as well as "gateway transit" and then update the vpn server config. So, updating vpn config is insufficient.
ahmadniknam
👍 2
Selected: B
The issue is not with the VPN client installation itself, but with the network configuration between the peered virtual networks. Reinstalling the VPN client on the Windows 10 workstation does not resolve the fact that VirtualNetworkB is not reachable through the point-to-site connection to VirtualNetworkA. To enable connectivity from the VPN client to VirtualNetworkB, the following configurations must be in place: "Allow gateway transit" must be enabled on VirtualNetworkA "Use remote gateway" must be enabled on VirtualNetworkB Without these settings, the point-to-site VPN client will not be able to route traffic to the peered network (VirtualNetworkB), even if the VPN is connected properly. Therefore, the solution does not meet the goal, and the correct answer is: B. No.
NicoVick
👍 1
Selected: A
a is correct
gurungde
👍 3
Selected: B
downloading and re-installing the VPN client configuration on windows 10 will help only in updating the configuration to connect to VNet-A but here the issue is in routing with VNet-B.
Helpnosense
👍 1
Selected: B
Need to update configuration then redownload and reinstall the VPN client.
ea4b48e
👍 4
Selected: B
The solution provided of downloading and re-installing the VPN client configuration package on the Windows 10 workstation is not likely to meet the goal. The issue here likely stems from the fact that when you establish a point-to-site VPN connection to VirtualNetworkA, the client configuration package does not automatically update to include routes to any newly peered virtual networks, in this case, VirtualNetworkB. To resolve this, you would need to update the VPN client configuration package to include the new routes. Therefore, the correct answer is: B. No
bhaskarraobaipothu
👍 2
Selected: B
Enable Remote Gateway Usage: Ensure that the peering between VNet A and VNet B is correctly configured. Enable Allow Gateway Transit on the peering for VNet A. Enable Use Remote Gateway on the peering for VNet B. Configure Routing: Add the necessary routes to ensure that the Windows 10 workstation can route traffic to VNet B. This can be done by: Configuring custom routes in Azure Route Tables. Ensuring that the Windows 10 workstation (or the VPN client) has routes to VNet B. You may need to manually add these routes to the VPN client or configure them in Azure's route tables.
Mark74
👍 1
Selected: A
A is correct , refresh correct routes
NaoVaz
👍 48
Selected: A
"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."
tsummey
👍 1
Selected: B
B is correct. The question implies that the Windows 10 workstation should access both VirtualNetworkA and VirtualNetworkB. The scenario says that VirtualNetworkA and VirtualNetworkB are peered, and the Windows 10 workstation has a site-to-site VPN connection with VirtualNetworkA, so you need to turn on the Allow gateway transit option on VirtualNetworkA Downloading and re-installing the VPN client configuration package on the Windows 10 workstation won't fix the problem of connecting to VirtualNetworkB from the workstation.
pooh0805
👍 1
Selected: B
Downloading and re-installing the VPN client configuration package on the Windows 10 workstation is unlikely to resolve the issue of not being able to establish a connection to VirtualNetworkB from the Windows 10 workstation. This issue is related to the configuration of the VPN client and routing, and simply re-installing the client configuration package is unlikely to address the underlying problem.
abinnnnnnnnnn
👍 2
No, downloading and re-installing the VPN client configuration package on the Windows 10 workstation is not the right solution to establish a connection to VirtualNetworkB from the Windows 10 workstation1. To establish a connection to VirtualNetworkB from the Windows 10 workstation, you need to enable the Allow gateway transit setting on VirtualNetworkA and the Use remote gateways setting on VirtualNetworkB23. This will allow VirtualNetworkB to use the VPN gateway in VirtualNetworkA for connectivity purposes, and the Windows 10 workstation will be able to establish a connection to VirtualNetworkB through the point-to-site VPN connection to VirtualNetworkA
dhivyamohanbabu
👍 1
Option A is correct
Benjam
👍 12
I have done this at work many times A is correct.
Madbo
👍 1
The solution in option A as YES (downloading and re-installing the VPN client configuration package on the Windows 10 workstation) may resolve the issue of not being able to establish a connection to VirtualNetworkB from the Windows 10 workstation. This is because when a VPN gateway is configured to use static routing, it may require updating the VPN client package configuration after making changes to the VPN gateway, such as adding a virtual network peering. Therefore, downloading and re-installing the VPN client configuration package on the Windows 10 workstation could potentially fix the issue.
lokii9980
👍 4
B. No, downloading and re-installing the VPN client configuration package on the Windows 10 workstation is unlikely to resolve the issue of not being able to connect to VirtualNetworkB. This is because the issue seems to be related to the virtual network peering between VirtualNetworkA and VirtualNetworkB, and not with the VPN client configuration on the Windows 10 workstation. A more appropriate solution would be to check the virtual network peering configuration, and ensure that the appropriate routes are in place to allow traffic to flow between VirtualNetworkA and VirtualNetworkB. Additionally, checking the network security groups and the Azure Firewall rules can help ensure that traffic is allowed to flow from the Windows 10 workstation to VirtualNetworkB.
habbey
👍 1
I agree. A is correct based on MSC documentation.
Shajeecool
👍 1
Selected: A
Correct answer is A
bonobos1979
👍 2
why “Allow gateway transit” and “Use remote gateways” don't need?
ricardona
👍 1
"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."
bdumois
👍 2
A is correct: Clients using Windows can access directly peered VNets, but the VPN client must be downloaded again if any changes are made to VNet peering or the network topology. https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing
m_faraz
👍 1
Selected: A
Correct answer is A
godchild
👍 1
thank you
EmnCours
👍 1
Selected: A
Correct Answer: A
Comments & Corrections
No comments yet — spotted an error or have a note? Share it below.
Expert Analysis
Why the Answer Is Correct
The on-premises network can already access VirtualNetworkB, which proves that VNet peering and gateway transit are correctly configured. The Windows 10 workstation cannot access VirtualNetworkB simply because its local routing table lacks the routes to the newly peered VNet's address space. Downloading and reinstalling the VPN client configuration package updates the client with the necessary routes, resolving the connectivity issue.Why the Other Options Are Wrong
Answering "No" implies that reinstalling the client package does not update the routes or that the underlying issue is a missing gateway transit configuration. However, the question explicitly states that on-premises connectivity to the peered VNet is successful, invalidating the missing transit configuration argument. For Windows P2S VPN clients, reinstalling the package is the required procedure to apply topology changes.Community Comment Notes
Several users correctly pointed out that "If you make a change to the topology of your network and have Windows VPN clients, the VPN client package" must be reinstalled, as NaoVaz noted. Others incorrectly argued for "No" based on missing gateway transit settings, failing to recognize that the on-premises network's successful connection proves those settings are already in place.Official Reference
Exam Strategy
Pay close attention to what the question explicitly confirms as working; if on-premises access to a peered VNet works, gateway transit is already configured. Focus on the client-side requirement for receiving updated routing information after a topology change.
Related Analysis
Practice All AZ-104 Questions
Access 100 questions with complete answers and detailed explanations.
View Full AZ-104 Practice Test →