updated whatsnew

Author: wtnlee

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

@@ -59,7 +59,12 @@ The list below corresponds to the diagram above and describes the packet flow fo
 
 ## Known Issues, Limitations and Considerations
 
+The following section describes known issues, limitations and considerations associatd with the Internet Inbound feature.
+
 ### Known Issues
+
+The following table describes known issues related to the internet inbound/DNAT feature.
+
 |Issue | Description| Mitigation|
 |--|--|--|
 | DNAT traffic is not 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 is not 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. |

articles/virtual-wan/how-to-routing-policies.md

@@ -92,13 +92,11 @@ Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) ar
     * Palo Alto Cloud NGFW is only available in Azure Public. Reach out to Palo Alto Networks regarding avaialbility of Cloud NGFW in Azure Government and Microsoft Azure operated by Viacom.
     * Network Virtual Appliances are not available in all Azure Government regions. Contact your NVA partner regarding availability in Azure Government.  
 
-  
 | Cloud Environment| Azure Firewall| Network Virtual Appliance| SaaS solutions|
 |--|--|--| --|
 | Azure Public | Yes | Yes | Yes|
 |Azure Government|Yes| Limited | No|
 |Microsoft Azure operated by 21 Vianet|No|No|No| 
-
 
 * Routing Intent simplifies routing by managing route table associations and propagations for all connections (Virtual Network, Site-to-site VPN, Point-to-site VPN, and ExpressRoute). Virtual WANs with custom route tables and customized policies therefore can't be used with the Routing Intent constructs.
 * Encrypted ExpressRoute (Site-to-site VPN tunnels running over ExpressRoute circuits) is supported in hubs where routing intent is configured if Azure Firewall is configured to allow traffic between VPN tunnel endpoints (Site-to-site VPN Gateway private IP and on-premises VPN device private IP). For more information on the required configurations, see [Encrypted ExpressRoute with routing intent](#encryptedER).

articles/virtual-wan/whats-new.md

@@ -98,6 +98,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 does not 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 does not 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 is not 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) is not 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 re-configure  additional private prefixes.|
+|10|  DNAT traffic is not 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 is not 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| Inbound security rule configuration scalability | Inbound security rule configuration may fail when a large number (approximately 100)  rules are configured. | November 2024  | None, reach out Azure Support for more information.|
+
 
 
 ## Next steps