Merge pull request #299699 from wtnlee/updatedstorage

hello

Author: prmerger-automator[bot]

articles/virtual-wan/whats-new.md

@@ -95,7 +95,8 @@ The following features are currently in gated public preview. After working with
 
 |#|Issue|Description |Date first reported|Mitigation|
 |---|---|---|---|---|
-|1|Connectivity to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|If 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 as the Virtual WAN hub 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. | September 2023| 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.1 |On-premises  to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from on-premises ExpressRoute, Site-to-site VPN and Point-to-site VPN connections destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations (routing via security appliance deployed in the Virtual WAN hub or spoke). In set-ups where routing intent private routing policy and internet routing policy are used, ExpressRoute connections are not able to reach storage account public IP addresses.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, terminate on-premises connectivity on a SD-WAN or dual-role SD-WAN and Firewall [Network Virtual Appliance (NVA) deployed in the Virtual WAN hub](about-nva-hub.md). You can terminate VPN tunnels over the public Internet on the NVA public IPs  or use ExpressRoute as an underlay. Traffic forwarded to storage account public IPs from an NVA in the hub is not impacted by this issue.|
+|1.2|Traffic from a Virtual Network connected to Virtual WAN destined to Azure Storage accounts deployed in the same region as your Virtual WAN hub bypasses Virtual WAN routing configuration.|Traffic from a Virtual Network connected to Virtual WAN destined for same region storage account public IP addresses bypasses Virtual WAN routing configurations to send traffic to a security appliance deployed in another Virutal WAN spoke Virtual Network.| September 2023| This issue applies to storage account access over public IP. Utilize [Private Link](../private-link/private-link-overview.md) to deploy private endpoints in spoke Virtual Networks connected to Virtual WAN hub to access storage accounts over private IP. If Private Link is not a technically feasible solution, deploy and configure routing to a security appliance in the hub as instead of another Virtual WAN spoke. This mitigation only applies to traffic from Virtual Networks and does **not** apply to traffic from on-premises. Reference Known Issue #1.1 for guidance related to on-premises connections.|
 |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 1 or more 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 and links advertising the same on-premises routes. | | To enable ECMP for your environment, you can create a [route-map](route-maps-how-to.md) for your virtual hub. When you create a route-map, your virtual hub will automatically be upgraded to the latest software version that supports ECMP, regardless of whether this route-map is applied on any connections. As a result, you only need to follow steps 1-7 [here](route-maps-how-to.md#configuration-workflow). If you do not plan to use the route-map, you can delete the route-map after step 7 is complete, as hubs with a route-map will incur additional cost. It is also recommended to first try creating a route-map in your test environment and validating routing and connectivity before creating a route-map in your production environment.  |