You have a Site-to-Site VPN between an on-premises network and an Azure VPN gateway. BGP is disabled for the Site-to-Site VPN. You have an Azure…

The Site-to-Site VPN uses static routing because BGP is disabled. When the address space of VNet1 was extended and Subnet2 was created, the Azure VPN gateway automatically became aware of the new address range. However, the on-premises VPN device has no automatic mechanism to learn this new route. Its configuration still only contains routes for the original VNet address space. To enable connectivity from the on-premises network to the new Subnet2, the routing configuration on the on-premises VPN device must be manually updated to include the address space of Subnet2, directing that traffic into the VPN tunnel.

A. Add an additional Site-to-Site VPN between the on-premises network and Vnetl.

This is incorrect because a single Site-to-Site VPN can handle multiple subnets and address prefixes. Adding a second VPN is unnecessary and overly complex.

B. Add a private endpoint to Subnet2.

This is incorrect as private endpoints are used to provide secure, private connectivity to Azure PaaS services, not to enable routing for VMs over a VPN.

C. To Subnet2. add a route table that contains a user-defined route.

This is incorrect because a route table on Subnet2 would control traffic leaving the subnet, not the inbound traffic from the on-premises network that is failing to arrive.

1. Microsoft Learn

Azure VPN Gateway Documentation. Troubleshoot an Azure site-to-site VPN connection that can't connect. In the section "Step 5: Check the on-premises VPN device

" the documentation states: "For a route-based VPN

ensure that your on-premises router has the correct routing tables so that the traffic is sent over the S2S VPN tunnel." This confirms that when a new Azure network is added

the on-premises routing tables must be updated accordingly in a non-BGP environment.

2. Microsoft Learn

Azure VPN Gateway Documentation. About policy-based and route-based VPN gateways. This document explains that for static route-based VPNs

"routing/forwarding tables direct traffic to different IPsec tunnels." This implies that if the destination network (the new Azure subnet) is not in the on-premises routing table

traffic will not be directed to the correct tunnel.

3. Microsoft Learn

Azure VPN Gateway Documentation. About VPN Gateway configuration settings. In the section "Local network gateways

" it details how address spaces are defined for static routing. It states

"The address space is the list of address ranges for the on-premises network." The same principle applies in reverse: the on-premises device must have a defined list of remote (Azure) address ranges. When a new range is added in Azure

the on-premises configuration must be updated to match.