fixed links

Author: flang-msft

articles/partner-solutions/palo-alto/palo-alto-application-gateway.md

@@ -24,7 +24,7 @@ For web applications, you benefit from using Application Gateway as both a rever
 
 Application Gateway also offers WAF capabilities to look for patterns that indicate an attack at the web application layer. For more information about Application Gateway features, see the [service documentation](/azure/application-gateway).
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw.png" alt-text="Diagram that shows a high-level architecture with Application Gateway.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-app-gateway.png" alt-text="Diagram that shows a high-level architecture with Application Gateway.":::
 
 Cloud NGFW for Azure supports two deployment architectures:
 
@@ -41,11 +41,11 @@ Application Gateway is deployed in a dedicated virtual network with a front end
 
 Similar to spoke virtual networks, the Application Gateway virtual network must be peered with the hub virtual network to ensure that the traffic can be routed toward the destination spoke virtual network.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-vnet.png" alt-text="Diagram that shows a Cloud NGFW for Azure architecture with Application Gateway in a hub-and-spoke virtual network deployment.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-app-gateway-vnet.png" alt-text="Diagram that shows a Cloud NGFW for Azure architecture with Application Gateway in a hub-and-spoke virtual network deployment.":::
 
 To force incoming web traffic through the Cloud NGFW for Azure resource, you must create a user-defined route and associate it with the Application Gateway subnet. The next hop in this case is the private IP address of Cloud NGFW for Azure. You can find this address by selecting **Overview** from the resource menu in the Azure portal.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-resource.png" alt-text="Screenshot that shows the Cloud NGFW for Azure view in the Azure portal.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-resource.png" alt-text="Screenshot that shows the Cloud NGFW for Azure view in the Azure portal.":::
 
 Here's an example user-defined route:
 
@@ -63,21 +63,21 @@ Securing a virtual WAN hub by using a Palo Alto Networks software as a service (
 
 You must configure a routing intent and a routing policy to use a Cloud NGFW for Azure resource as a next hop for public or private traffic. Any connected spoke virtual network, VPN gateway, or Azure ExpressRoute gateway then gets the routing information to send the traffic through the Cloud NGFW for Azure resource.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-vwan.png" alt-text="Diagram that shows a Cloud NGFW for Azure architecture with Application Gateway in a virtual WAN hub deployment.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-app-gateway-vwan.png" alt-text="Diagram that shows a Cloud NGFW for Azure architecture with Application Gateway in a virtual WAN hub deployment.":::
 
 By default, the virtual network connection to the hub has the **Propagate Default Route** option set to **Enabled**. This setting installs a 0.0.0.0/0 route to force all nonmatched traffic sourced from that virtual network to go through the virtual WAN hub. In this topology, this setting would result in asymmetric routing because the return traffic proxied by Application Gateway would go back to the virtual hub instead of the internet. When you're connecting the Application Gateway virtual network to the virtual WAN hub, set this attribute to **Disabled** to allow the Application Gateway-sourced traffic to break out locally.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-virtual-connection.png" alt-text="Screenshot that shows virtual network connections for a virtual WAN.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-virtual-connection.png" alt-text="Screenshot that shows virtual network connections for a virtual WAN.":::
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-disable-gateway.png" alt-text="Screenshot that shows the toggle for disabling the default route propagation.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-disable-gateway.png" alt-text="Screenshot that shows the toggle for disabling the default route propagation.":::
 
 In some cases, disabling the default route propagation might not be desirable. An example is when other applications or workloads are hosted in the Application Gateway virtual network and require the inspection by Cloud NGFW for Azure. In this case, you can enable the default route propagation but add a 0.0.0.0/0 route to the Application Gateway subnet to override the default route received from the hub. An explicit route to the application virtual network is also required.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-route-table.png" alt-text="Screenshot that shows an Azure route table.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-route-table.png" alt-text="Screenshot that shows an Azure route table.":::
 
 You can locate the next hop IP address of Cloud NGFW for Azure by viewing the effective routes of a workload in a spoke virtual network. The following example shows the effective routes for a virtual machine network interface.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-effective-routes.png" alt-text="Screenshot that shows effective routes for a spoke virtual machine.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-effective-routes.png" alt-text="Screenshot that shows effective routes for a spoke virtual machine.":::
 
 ## Security policy considerations
 
@@ -94,11 +94,11 @@ For more information, see [Cloud NGFW Native Policy Management Using Rulestacks]
 
 When you manage Cloud NGFW for Azure resources by using Panorama, you can use existing and new policy constructs such as template stacks, zones, and vulnerability profiles. You can configure the Cloud NGFW for Azure security policies between the two zones: private and public. Inbound traffic goes from public to private, outbound traffic goes from private to public, and east-west traffic goes from private to private.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-zones-1.png" alt-text="Diagram that shows zone placement and traffic flows in Cloud NGFW for Azure.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-app-gateway-zones-1.png" alt-text="Diagram that shows zone placement and traffic flows in Cloud NGFW for Azure.":::
 
 The ingress traffic that comes through Application Gateway is forwarded through the private zone to the Cloud NGFW for Azure resource for inspection and security policy enforcement.
 
-:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-zones-2.png" alt-text="Diagram that shows zone placement in Cloud NGFW for Azure and traffic flow through Application Gateway.":::
+:::image type="content" source="media/palo-alto-app-gateway/palo-alto-app-gateway-zones-2.png" alt-text="Diagram that shows zone placement in Cloud NGFW for Azure and traffic flow through Application Gateway.":::
 
 You need to apply special considerations to zone-based policies to ensure that the traffic coming from Application Gateway is treated as inbound. These policies include security rules, threat prevention profiles, and inline cloud analysis. The traffic is treated as private-to-private because Application Gateway proxies it, and it's sourced through the private IP address from the Application Gateway subnet.