You have an Azure subscription that contains a user named User1 and the resources shown in the following table.
User1 has a computer named Computer1 that runs Windows 11. User1 works from home and establishes a Point-to-Site (P2S) connection to GW1 to access AppSvr1.
You deploy the resources shown in the following table.
User1 cannot access AppSvr2.
You need to ensure that User1 can access AppSvr2.
What should you do?
User1 needs to re-download and reinstall the VPN client on Computer1 to update the changes made to the VNet peering or network topology. This will allow User1's computer to recognize the new network routes and provide access to AppSvr2 in VNet2. VNet peering allows communication between the two virtual networks, but changes to the VPN client's configuration are necessary for these new routes to be recognized by the client.
Perhaps A is correct https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing
Yep, sounds like it. From that link: "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."
Re-install the P2S client.
Azure default routes will be populated automatically once peering is established, no need for manual routing changes with Route Tables. Will need to re-download the client and reinstall it again, So the answer is A
A, these topics were covered in more detail in AZ-104
C is just plain wrong D is also out as Virtual Network (VNet) service endpoint provides secure and direct connectivity to Azure services https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-about-point-to-site-routing 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 Meaning A is wrong leaving B as the answer
Wait, you're saying A is wrong but it's right? Could you clarify?
not B because Azure creates the route table. You can add to a route table but not create your own.
You can add a UDR
B is correct B. Create a route table and associate the table with GatewaySubnet on VNet1. Reason below: 1- User1 is already able to establish a Point-to-Site (P2S) connection to GW1 to access AppSvr1. This indicates that the VPN client on Computer1 is configured correctly for the existing P2S connection. 2- The problem is that User1 cannot access AppSvr2, which is located in Vnet2 and not directly connected to the P2S connection. To enable User1 to access resources in Vnet2, you need to ensure that the traffic from the P2S connection is correctly routed to Vnet2. 3- Creating a route table and associating it with the GatewaySubnet on VNet1 allows you to define custom routes for the VPN traffic. You can configure the route table to route traffic destined for Vnet2 through the peering connection between Vnet1 and Vnet2.
You're correct that VNet peering does indeed establish a link and routing between the two virtual networks (VNet1 and VNet2). However, by default, a Point-to-Site (P2S) VPN client (User1 in this case) connected to VNet1 can only access resources within VNet1. While VNet peering allows for resources in VNet1 and VNet2 to communicate directly, this doesn't automatically mean a P2S VPN client connected to VNet1 can access resources in VNet2. This capability has to be explicitly configured.
This answer was wrong given below webpage answer A!!
B. Create a route table and associate the table with GatewaySubnet on VNet1. Since User1 can establish a P2S connection to GW1, User1 can access resources in VNet1. However, User1 cannot access resources in VNet2 because there is no route between the two VNets. To enable access to AppSvr2, you need to create a route table and associate the table with GatewaySubnet on VNet1. The route table should contain a user-defined route that has a destination prefix of the address space of VNet2 (10.2.0.0/16 in this case) and the next hop type Virtual appliance. The next hop address should be the IP address of the virtual network gateway on VNet1. This route table will enable User1 to access AppSvr2 over the P2S connection to GW1.
https://learn.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview For peered virtual networks, resources in either virtual network can directly connect with resources in the peered virtual network. The traffic between virtual machines in peered virtual networks is routed directly through the Microsoft backbone infrastructure, not through a gateway or over the public Internet. Full connectivity is the default option. So, just reinstall the client.
Same as thefscale, if the 2 VNETs are peered, recreating the connection should provide connectivity to both.
To decide on the correct answer, let's take a closer look at the options: - Option A (Download and reinstall VPN client on computer 1): This option doesn't seem relevant to solving the access problem between AppSvr1 and AppSvr2. - Option B (Create a routing table and associate it with GatewaySubnet on virtual network 1): This is the most appropriate option. It configures the routes required for traffic to pass between the peered virtual networks (VNet1 and VNet2). In this way, User1 will be able to access AppSvr2 from AppSvr1. - Option C (Modify Windows Defender firewall settings on Computer1): Although firewall security is important, this will not directly solve the access problem between the two virtual machines. - Option D (Add a service endpoint to virtual network 2): This option doesn't seem necessary to solve the access problem between AppSvr1 and AppSvr2. Taking this information into account, I confirm that Option B is the correct answer.
Answer is A
Answer is A.
Multiple peered VNets In this example, the Point-to-Site VPN gateway connection is for VNet1. VNet1 is peered with VNet2. VNet 2 is peered with VNet3. VNet1 is peered with VNet4. There is no direct peering between VNet1 and VNet3. VNet1 has “Allow gateway transit” and VNet2 and VNet4 have “Use remote gateways” enabled. 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. Non-Windows clients can access directly peered VNets. Access isn't transitive and is limited to only directly peered VNets.