Skip to content

Conversation

edtorresco
Copy link
Contributor

Review address spaces

Review addess spaces
Copy link
Contributor

@edtorresco : Thanks for your contribution! The author(s) and reviewer(s) have been notified to review your proposed change.

Copy link
Contributor

Learn Build status updates of commit 0f9fcf3:

✅ Validation status: passed

File Status Preview URL Details
articles/virtual-wan/nat-rules-vpn-gateway.md ✅Succeeded

For more details, please refer to the build report.

Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR corrects address space inconsistencies in the VPN gateway NAT rules documentation. The changes fix mismatched IP address ranges and correct a typographical error in an IP address.

  • Updates address space notation from /32 to /24 for proper subnet representation
  • Fixes IP address typo from 192.168.0.02 to 192.168.0.1

Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.

* In Dynamic NAT, on-premises BGP peer IP can't be part of the pre-NAT address range (**Internal Mapping**) as IP and port translations aren't fixed. If there is a need to translate the on-premises BGP peering IP, please create a separate **Static NAT Rule** that translates BGP Peering IP address only.

For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/32, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.02/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).
For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/24, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.1/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).
Copy link
Preview

Copilot AI Sep 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's an inconsistency in the IP address range. The dynamic NAT rule translates to '192.198.0.0/24' but the static NAT rule uses '192.168.0.1/32'. These should use the same IP range - either both should be 192.198.x.x or both should be 192.168.x.x for consistency.

Suggested change
For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/24, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.168.0.1/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).
For instance, if the on-premises network has an address space of 10.0.0.0/24 with an on-premises BGP peer IP of 10.0.0.1 and there is an **Ingress Dynamic NAT Rule** to translate 10.0.0.0/24 to 192.198.0.0/24, a separate **Ingress Static NAT Rule** translating 10.0.0.1/32 to 192.198.0.1/32 is required and the corresponding VPN site's **Link Connection BGP address** must be updated to the NAT-translated address (part of the External Mapping).

Copilot uses AI. Check for mistakes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@cherylmc This may not apply, but I will leave that answer to you.

@v-dirichards
Copy link
Contributor

@cherylmc

Can you review the proposed changes?

Important: When the changes are ready for publication, adding a #sign-off comment is the best way to signal that the PR is ready for the review team to merge.

#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@prmerger-automator prmerger-automator bot added the aq-pr-triaged tracking label for the PR review team label Sep 25, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants