Keep a Virtual WAN BGP peer out of dynamic NAT mappings

Source facts

Microsoft says the on-premises BGP peer cannot be included in a dynamic rule’s pre-NAT mapping because the translated address and port are not fixed. If that peer needs translation, the documented approach is a separate static rule for the peering address.

The VPN site’s link-connection BGP address must then use the translated address. The guidance also excludes site-to-site connections that use policy-based traffic selectors from this NAT capability. Microsoft Learn.

Applicability

Identify the original peer address, intended translated peer address, dynamic application range and connection type. Keep the routing-control endpoint distinct from the traffic whose overlapping addresses motivated NAT.

DSE recommendation

DSE recommends a mapping worksheet that shows the BGP peer’s dedicated static translation alongside the dynamic pool. Have both VPN owners check the link-connection setting and expected route advertisements before the change. Do not assume that a working translated application flow demonstrates the BGP peering configuration is correct. Review the full source for ingress, egress and route-translation settings.

Verification

In an approved test connection, inspect the deployed NAT rules and the configured BGP link address, then verify peering and learned routes. Exercise an intended translated application path and its return traffic separately. Retain the original and translated identities with the observed routes so future address changes do not accidentally move the control-plane peer into the dynamic mapping.

Official references

Microsoft Learn: Configure VPN NAT rules for your gateway. Source retrieved September 9, 2026.