Identify who updates remote prefixes when connecting Azure VNets through VPN gateways

Source facts

Microsoft distinguishes the VNet-to-VNet VPN connection type from manually connecting two VNets through site-to-site definitions. With VNet-to-VNet, the local-network address information is populated automatically and follows the other VNet’s address-space updates. In the manual site-to-site approach, the corresponding local network gateway must be updated explicitly when the remote VNet address space changes. Microsoft Learn.

Applicability

Apply this check before adding or changing a connected VNet’s prefixes. Inspect the actual connection type and gateway objects, rather than inferring the maintenance behavior from a diagram showing two Azure networks.

DSE recommendation

DSE recommends recording address-update ownership in the network change plan. For manually maintained site definitions, list the remote gateway objects and operator responsible for each. Compare proposed ranges with the approved address plan and identify affected applications. Preserve the prior prefixes and connection settings before making an authorized change; use the current source for the full connection prerequisites.

Verification

After the approved update, compare each remote address definition and effective route with the planned range. Test an allowed endpoint in the changed prefix and a previously working endpoint. Record both observations and the actual connection type. Investigate an absent remote route before attributing the failure to application or firewall settings.

Official references

Microsoft Learn: Connect a VNet to another VNet using a VPN Gateway VNet-to-VNet connection: PowerShell.