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

> Distinguish VNet-to-VNet address updates from manually maintained site-to-site definitions.

- Canonical URL: https://update.dsesecurity.com/updates/dse-20260917-063-identify-who-updates-remote-prefixes-when-connecting-azure-vnets-through-vpn/
- Publisher: Detection Systems & Engineering (DSE Security)
- Author: DSE Security Editorial Team
- Published: 2026-09-17T16:33:57+00:00
- Modified: 2026-09-17T16:38:45+00:00
- Last reviewed by DSE: 2026-09-17
- Resource type: Guide
- DSE priority: Information
- Topics: Cybersecurity, Networks & Infrastructure
- Reading time: 1 minutes

## What you need to know

Distinguish VNet-to-VNet address updates from manually maintained site-to-site definitions.

## Potentially affected

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.

## Article

## 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](https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vnet-vnet-rm-ps).

## 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](https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vnet-vnet-rm-ps).

## Primary reference

- Name: Connect a VNet to another VNet using a VPN Gateway VNet-to-VNet connection: PowerShell - Azure VPN Gateway | Microsoft Learn
- Authority: Microsoft Learn
- URL: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-vnet-vnet-rm-ps
- Source publication date: Not stated by the source

## Citation and use

Preferred citation: “Identify who updates remote prefixes when connecting Azure VNets through VPN gateways,” DSE Security, https://update.dsesecurity.com/updates/dse-20260917-063-identify-who-updates-remote-prefixes-when-connecting-azure-vnets-through-vpn/
Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/
Usage and citation policy: https://update.dsesecurity.com/usage/
Copyright © 2026 Detection Systems & Engineering. All rights reserved.