added updates and bug fixes

Author: wtnlee

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

@@ -103,7 +103,7 @@ Consider the following configuration where Hub 1 (Normal) and Hub 2 (Secured) ar
   * Static routes in the defaultRouteTable that point to a Virtual Network connection can't be used in conjunction with routing intent. However, you can use the [BGP peering feature](scenario-bgp-peering-hub.md).
   * Static routes on the Virtual Network connection with "static route propagation" aren't applied to the next-hop resource specified in private routing policies. Support for applying static routes on Virtual Network connections to private routing policy next-hop is on the roadmap.
   * The ability to deploy both an SD-WAN connectivity NVA and a separate Firewall NVA or SaaS solution in the **same** Virtual WAN hub is currently in the road-map. Once routing intent is configured with next hop SaaS solution or Firewall NVA, connectivity between the SD-WAN NVA and Azure is impacted. Instead, deploy the SD-WAN NVA and Firewall NVA or SaaS solution in different Virtual Hubs. Alternatively, you can also deploy the SD-WAN NVA in a spoke Virtual Network connected to the hub and leverage the virtual hub [BGP peering](scenario-bgp-peering-hub.md) capability.
-  * Network Virtual Appliances (NVAs) can only be specified as the next hop resource for routing intent if they're Next-Generation Firewall or dual-role Next-Generation Firewall and SD-WAN NVAs. Currently, **checkpoint**, **fortinet-ngfw** and **fortinet-ngfw-and-sdwan** are the only NVAs eligible to be configured to be the next hop for routing intent. If you attempt to specify another NVA, Routing Intent creation fails. You can check the type of the NVA by navigating to your Virtual Hub -> Network Virtual Appliances and then looking at the **Vendor** field. [**Palo Alto Networks Cloud NGFW**](how-to-palo-alto-cloud-ngfw.md) is also supported as the next hop for Routing Intent, but is considered a next hop of type **SaaS solution**. 
+  * Network Virtual Appliances (NVAs) can only be specified as the next hop resource for routing intent if they're Next-Generation Firewall or dual-role Next-Generation Firewall and SD-WAN NVAs. Currently, **checkpoint**, **fortinet-ngfw**, **fortinet-ngfw-and-sdwan** and **cisco-ftdv**  are the only NVAs eligible to be configured to be the next hop for routing intent. If you attempt to specify another NVA, Routing Intent creation fails. You can check the type of the NVA by navigating to your Virtual Hub -> Network Virtual Appliances and then looking at the **Vendor** field. [**Palo Alto Networks Cloud NGFW**](how-to-palo-alto-cloud-ngfw.md) is also supported as the next hop for Routing Intent, but is considered a next hop of type **SaaS solution**. 
   * Routing Intent users who want to connect multiple ExpressRoute circuits to Virtual WAN and want to send traffic between them via a security solution deployed in the hub can enable open up a support case to enable this use case. Reference [enabling connectivity across ExpressRoute circuits](#expressroute) for more information.
 
 ### Virtual Network Address Space Limits

articles/virtual-wan/whats-new.md

@@ -36,11 +36,13 @@ You can also find the latest Azure Virtual WAN updates and subscribe to the RSS
 
 | Type |Area |Name |Description | Date added | Limitations |
 | --- |---|---|---|---|---|
+|Feature |Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs| Versa VOS|General Availability of  of [Versa VOS](https://versa-networks.com/partners/microsoft-azure/).|February 2025| See [Versa](https://versa-networks.com/partners/microsoft-azure/) documentation.|
+| Feature| Network Virtual Appliances (NVAs)/Integrated  Third-party solutions in Virtual WAN hubs| Cisco Firepower Threat Defense| General Availability of [Cisco Firepower Threat Defense](https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/consolidated_ftdv_gsg/threat-defense-virtual-77-gsg/m-ftdv-azure-gsg.html) in the Virtual WAN hub. | February 2025| See [Cisco documentation](https://www.cisco.com/c/en/us/td/docs/security/firepower/quick_start/consolidated_ftdv_gsg/threat-defense-virtual-77-gsg/m-ftdv-azure-gsg.html). Same limitations as routing intent. |
+| Feature|Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs| [NVA Restart](how-to-network-virtual-appliance-restart.md)| Ability to restart Integrated NVAs in Virtual WAN hub. | October 2024 |Does not apply to Palo Alto Networks Cloud NGFW | 
 | Feature|Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs|  Public Preview of Internet inbound/DNAT for Next-Generation Firewall NVAs| Destination NAT for Network Virtual Appliances in the Virtual WAN hub allows you to publish applications to the users in the internet without directly exposing the application or server's public IP. Consumers access applications through a public IP address assigned to a Firewall Network Virtual Appliance. |February 2024| Supported for Fortinet Next-Generation Firewall, Check Point CloudGuard. See [DNAT documentation](how-to-network-virtual-appliance-inbound.md) for the full list of limitations and considerations.|
 |Feature|Software-as-a-service|Palo Alto Networks Cloud NGFW|General Availability of [Palo Alto Networks Cloud NGFW](https://aka.ms/pancloudngfwdocs), the first software-as-a-service security offering deployable within the Virtual WAN hub.|July 2023|Palo Alto Networks Cloud NGFW is now deployable in all  Virtual WAN hubs (new and old). See [Limitations of Palo Alto Networks Cloud NGFW](how-to-palo-alto-cloud-ngfw.md) for a full list of limitations and regional availability. Same limitations as routing intent.|
 |Feature|Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs|[Fortinet NGFW](https://www.fortinet.com/products/next-generation-firewall)|General Availability of [Fortinet NGFW](https://aka.ms/fortinetngfwdocumentation) and [Fortinet SD-WAN/NGFW dual-role](https://aka.ms/fortinetdualroledocumentation) NVAs.|May 2023| Same limitations as routing intent. Doesn't support internet inbound scenario.|
 |Feature|Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs|[Check Point CloudGuard Network Security for Azure Virtual WAN](https://www.checkpoint.com/cloudguard/microsoft-azure-security/wan/) |General Availability of Check Point CloudGuard Network Security NVA deployable from Azure Marketplace within the Virtual WAN hub in all Azure regions.|May 2023|Same limitations as routing intent. Doesn't support internet inbound scenario.|
-|Feature |Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs| [Versa SD-WAN](about-nva-hub.md#partners)|Preview of Versa SD-WAN.|November 2021| |
 |Feature|Network Virtual Appliances (NVAs)/Integrated Third-party solutions in Virtual WAN hubs|[Cisco Viptela, Barracuda, and VMware (Velocloud) SD-WAN](about-nva-hub.md#partners) |General Availability of SD-WAN solutions in Virtual WAN.|June/July 2021| |
 
 ### ExpressRoute
@@ -89,7 +91,7 @@ The following features are currently in gated public preview. After working with
 
 |#|Issue|Description |Date first reported|Mitigation|
 |---|---|---|---|---|
-|1|ExpressRoute connectivity with Azure Storage and the 0.0.0.0/0 route|If you configured a 0.0.0.0/0 route statically in a virtual hub route table or dynamically via a network virtual appliance for traffic inspection, that traffic bypasses inspection when destined for Azure Storage and is in the same region as the ExpressRoute gateway in the virtual hub. | | As a workaround, you can either use [Private Link](../private-link/private-link-overview.md) to access Azure Storage or put the Azure Storage service in a different region than the virtual hub.|
+|1|Connectivity to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|f you configure Virtual WAN to route internet-bound traffic to a security-inspection appliance deployed in the Virtual WAN hub or in a spoke Virtual Network connected to a Virtual WAN hub, storage account traffic destined for a storage account in the same Azure region bypasses the security-inspection appliance. In Secure Hub deployments, ExpressRoute on-premises connected to hubs with this configuration may not be able to access to Azure Storage accounts at all. | May 2021| As a workaround, you can either use [Private Link](../private-link/private-link-overview.md) to access Azure Storage or put the Azure Storage service in a different region than the virtual hub.|
 |2| Default routes (0/0) won't propagate inter-hub |0/0 routes won't propagate between two virtual WAN hubs. | June 2020 |  None. Note: While the Virtual WAN team has fixed the issue, wherein static routes defined in the static route section of the VNet peering page propagate to route tables listed in "propagate to route tables" or the labels listed in "propagate to route tables" on the VNet connection page, default routes (0/0) won't propagate inter-hub. |
 |3| Two ExpressRoute circuits in the same peering location connected to multiple hubs |If you have two ExpressRoute circuits in the same peering location, and both of these circuits are connected to multiple virtual hubs in the same Virtual WAN, then connectivity to your Azure resources might be impacted. | July 2023 | Make sure each virtual hub has at least 1 virtual network connected to it. This ensures connectivity to your Azure resources. The Virtual WAN team is also working on a fix for this issue. |
 |4| ExpressRoute ECMP Support | Today, ExpressRoute ECMP isn't enabled by default for virtual hub deployments. When multiple ExpressRoute circuits are connected to a Virtual WAN hub, ECMP enables traffic from spoke virtual networks to on-premises over ExpressRoute to be distributed across all ExpressRoute circuits advertising the same on-premises routes. | | To enable ECMP for your Virtual WAN hub, reach out to [email protected] after January 1, 2025. |
@@ -101,7 +103,7 @@ The following features are currently in gated public preview. After working with
 |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.
+|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.|
 
 ## Next steps