Merge pull request #299331 from wtnlee/removedlimitations

removeddnatlimit

Author: prmerger-automator[bot]

articles/virtual-wan/how-to-network-virtual-appliance-inbound.md

@@ -65,11 +65,7 @@ The following section describes known issues, limitations, and considerations as
 
 ### Known Issues
 
-The following table describes known issues related to the internet inbound/DNAT feature.
-
-|Issue | Description| Mitigation|
-|--|--|--|
-| DNAT traffic isn't forwarded to the NVA after associating an additional IP address.| After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic isn't forwarded properly to the NVA due to a code defect. | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity. |
+There are currently no known issues related to the destination NAT (DNAT) capability for NVAs deployed in the Virtual WAN hub.
 
 ### Limitations
 

articles/virtual-wan/whats-new.md

@@ -102,10 +102,9 @@ The following features are currently in gated public preview. After working with
 | 7| BGP between the Virtual WAN hub router and NVAs deployed in the Virtual WAN hub doesn't come up if the ASN used for BGP peering is updated post-deployment.|Virtual hub router expects NVA in the hub to use the ASN that was configured on the router when the NVA was first deployed. Updating the ASN associated with the NVA on the NVA resource doesn't properly register the new ASN with the Virtual hub router so the router rejects BGP sessions from the NVA if the NVA OS is configured to use the new ASN. | |Delete and recreate the NVA in the Virtual WAN hub with the correct ASN.|
 |8| Advertising default route (0.0.0.0/0) from on-premises (VPN, ExpressRoute, BGP endpoint) or statically configured on a Virtual Network connection isn't supported for forced tunneling use cases.| The 0.0.0.0/0 route advertised from on-premises (or statically configured on a Virtual Network connection) isn't applied to the Azure Firewall or other security solutions deployed in the Virtual WAN hub. Packets inspected by the security solution in the hub are routed directly to the internet, bypassing the route learnt from on-premises||Publish the default route from on-premises only in non-secure hub scenarios.|
 |9| Routing intent update operations fail in deployments where private routing policy next hop resource is an NVA or SaaS solution.| In deployments where private routing policy is configured with next hop NVA or SaaS solutions alongside additional private prefixes, modifying routing intent fails. Examples of operations that fail are adding or removing internet or private routing policies. This known issue doesn't impact deployments with no additional private prefixes configured. | |Remove any additional private prefixes, update routing intent and then reconfigure additional private prefixes.|
-|10|  DNAT traffic isn't forwarded to the NVA after associating an additional IP address.|After associating additional IP address(es) to an NVA that already has active inbound security rules, DNAT traffic isn't forwarded properly to the NVA due to a code defect. | November 2024 | Use partner orchestration/management software to modify (create or delete existing) configured inbound-security rules to restore connectivity.|
-|11| Spoke Virtual Network address space updates not picked up by Virtual WAN | Multiple concurrent updates on spoke Virtual Network address spaces aren't properly synced with the Virtual hub. | November 2024 | Ensure address space updates in a single Virtual Network are done serially. Wait until the first address update is properly reflected in the Virtual hub's effective routes before updating the address space of the spoke Virtual Network again. If this issue has already occurred, make sure to update the address space of the affected Virtual Network with a nonimpacting address space (wait about 20 minutes before attempting again). Once this is reflected in the Virtual Network AND in the Virtual hub, update the Virtual Network address space to the preferred Virtual Network address space.|
-|12 |Unable to update route tables and routing configuration (propagated route table and label)  for on-premises (VPN, ExpressRoute, NVA) connections. | When a Virtual WAN hub and its gateway(s) are in different Azure resource groups, updating routing configuration results in a "resource not found" error. | March 2025| This issue is caused by a code defect in Azure portal. Use Terraform, PowerShell, CLI or REST API to manage your Virtual WAN deployment.|
-|13| Hub won't advertise routes to VPN sites | When a customer uses Route-Maps for the first time it triggers an upgrade. After the upgrade is complete, If VPN sites aren't advertising routes to the hub, the hub won't advertise routes to the VPN sites. | December 2024 | If the VPN sites start adverting any routes to the hub, the hub will start adverting routes again.|
+|10| Spoke Virtual Network address space updates not picked up by Virtual WAN | Multiple concurrent updates on spoke Virtual Network address spaces aren't properly synced with the Virtual hub. | November 2024 | Ensure address space updates in a single Virtual Network are done serially. Wait until the first address update is properly reflected in the Virtual hub's effective routes before updating the address space of the spoke Virtual Network again. If this issue has already occurred, make sure to update the address space of the affected Virtual Network with a nonimpacting address space (wait about 20 minutes before attempting again). Once this is reflected in the Virtual Network AND in the Virtual hub, update the Virtual Network address space to the preferred Virtual Network address space.|
+|11 |Unable to update route tables and routing configuration (propagated route table and label)  for on-premises (VPN, ExpressRoute, NVA) connections. | When a Virtual WAN hub and its gateway(s) are in different Azure resource groups, updating routing configuration results in a "resource not found" error. | March 2025| This issue is caused by a code defect in Azure portal. Use Terraform, PowerShell, CLI or REST API to manage your Virtual WAN deployment.|
+|12| Hub won't advertise routes to VPN sites | When a customer uses Route-Maps for the first time it triggers an upgrade. After the upgrade is complete, If VPN sites aren't advertising routes to the hub, the hub won't advertise routes to the VPN sites. | December 2024 | If the VPN sites start adverting any routes to the hub, the hub will start adverting routes again.|
 
 ## Next steps