You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/partner-solutions/palo-alto/palo-alto-application-gateway.md
+30-31Lines changed: 30 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,29 +3,29 @@ title: Securing web applications with Cloud NGFW by Palo Alto Networks
3
3
description: This article describes how to use the Azure Application Gateway with the Cloud NGFW (Next-Generation Firewall) by Palo Alto Networks - an Azure Native ISV Service resource.
4
4
5
5
ms.topic: conceptual
6
-
ms.date: 03/11/2024
6
+
ms.date: 05/06/2024
7
7
8
8
---
9
9
# Cloud NGFW and Azure Application Gateway
10
10
11
-
## Background
11
+
In this article, you see a recommended architecture for deploying the Cloud NGFW for Azure behind the Azure Application Gateway.
12
12
13
-
This guide documents a recommended architecture to deploy the Cloud NGFW for Azure behind the Azure Application Gateway.
13
+
This deployment model uses the Application Gateway's reverse proxy and Web Application Firewall (WAF) functionality using the network security capabilities of the Cloud NGFW.
14
14
15
-
This deployment model allows leveraging the Application Gateway's reverse proxy and Web Application Firewall (WAF) functionality while benefiting the best-in-class network security capabilities of the Cloud NGFW.
15
+
The Cloud Next-Generation Firewall by Palo Alto Networks - an Azure Native ISV Service is Palo Alto Networks Next-Generation Firewall (NGFW) delivered as a cloud-native service on Azure. You find the Cloud NGFW in the Azure Marketplace and consume it in your Azure Virtual Networks (VNet) and in the Azure Virtual WAN (vWAN).
16
16
17
-
Cloud Next-Generation Firewall by Palo Alto Networks - an Azure Native ISV Service is Palo Alto Networks Next-Generation Firewall (NGFW) delivered as a cloud-native service on Azure. You can discover Cloud NGFW in the Azure Marketplace and consume it in your Azure Virtual Networks (VNet) and in the Azure Virtual WAN (vWAN). With Cloud NGFW, you can access the core NGFW capabilities such as App-ID and URL filtering-based technologies. It provides threat prevention and detection through cloud-delivered security services and threat prevention signatures.
17
+
With Cloud NGFW, you can access the core NGFW capabilities such as App-ID and URL filtering-based technologies. It provides threat prevention and detection through cloud-delivered security services and threat prevention signatures.
18
18
19
-
More details about the Cloud NGFW by Palo Alto Networks - an Azure Native ISV
20
-
Service can be found here: [https://learn.microsoft.com/azure/partner-solutions/palo-alto/palo-alto-overview](/azure/partner-solutions/palo-alto/palo-alto-overview)
19
+
For more information about the Cloud NGFW by Palo Alto Networks - an Azure Native ISV
20
+
Service, see [What is Cloud NGFW by Palo Alto Networks - an Azure Native ISV Service?](palo-alto-overview.md).
21
21
22
22
## Architecture
23
23
24
24
The Cloud NGFW for Azure secures inbound, outbound, and lateral traffic traversing the Hub Virtual Network (Hub VNet) or Virtual WAN Hub (vWAN Hub).
25
25
26
26
To secure ingress connections, Cloud NGFW resource supports Destination Network Address Translation (DNAT) configuration. Cloud NGFW accepts client connections on one or more of the configured Public IP addresses and performs the address translation, traffic inspection, and enforces the user-configured security policies.
27
27
28
-
For web applications, users may benefit from using Azure Application Gateway (AppGW) as a reverse proxy/Load Balancer. This combination offers the best security when securing both web-based and non-web workloads in Azure and on-prem. Ingress connections. It allows using a single Public IP address of the AppGW to proxy the HTTP(s) connections to many web application backends. Non-HTTP(s) connections should be directed via the Cloud NGFW Public IP address for inspection and policy enforcement.
28
+
For web applications, you benefit from using Azure Application Gateway (AppGW) as a reverse proxy/Load Balancer. This combination offers the best security when securing both web-based and nonweb workloads in Azure and on-premises. Ingress connections. It allows using a single Public IP address of the AppGW to proxy the HTTP and Https connections to many web application backends. Any Non-HTTP connections should be directed through the Cloud NGFW Public IP address for inspection and policy enforcement.
29
29
30
30
The AppGW also offers Web Application Firewall (WAF) capabilities to look for patterns that indicate an attack at the web application layer.
31
31
@@ -34,50 +34,51 @@ The AppGW also offers Web Application Firewall (WAF) capabilities to look for pa
34
34
More details about Application Gateway features can be found here: [https://learn.microsoft.com/azure/application-gateway](/azure/application-gateway)
35
35
36
36
Cloud NGFW for Azure supports two deployment architectures:
37
-
- Hub-and-Spoke VNet
37
+
38
+
- Hub-and-Spoke VNet
38
39
- Virtual WAN
39
40
40
41
The following sections describe the details and the required configuration to implement this architecture in Azure.
41
42
42
43
### Hub VNet
43
44
44
-
In this deployment, two subnets are allocated in the Hub VNet. The Cloud NGFW resource is provisioned into the Hub VNet.
45
+
In this deployment, two subnets are allocated in the Hub VNet. The Cloud NGFW resource is provisioned into the Hub VNet.
45
46
46
47
The AppGW is deployed in a dedicated VNet with a Frontend listening on a Public IP address. The backend pool and target the workloads serving the web application in this example a Virtual Machine in a spoke VNet 192.168.1.0/24.
47
48
48
49
Similar to spoke VNets, the AppGW VNet must be peered with the Hub VNet to ensure the traffic can be routed towards the destination spoke VNet.
49
50
50
51
:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-vnet.png" alt-text="Diagram shows Cloud NGFW architecture with Application Gateway in a hub-and-spoke VNet deployment.":::
51
52
52
-
To force the incoming web traffic via the Cloud NGFW resource a User-Defined route must be created and associated with AppGW subnet. The next hop in this case is Cloud NGFW’s Private IP address which can be obtained from the “Overview” blade of the resource in Azure Portal.
53
+
To force the incoming web traffic through the Cloud NGFW resource, a User-Defined route must be created and associated with AppGW subnet. The next hop in this case is Cloud NGFW’s Private IP address. You can see this by selecting **Overview** from the Resource menu in the Azure portal.
Once the infrastructure is deployed and configured there must be a security policy applied to the Cloud NGFW allowing the connection from the AppGW VNet. The AppGW proxies the client’s TCP connection and creates a new connection to the destination specified in the backend target. The source IP of this connection is the private IP address from the AppGW subnet. Thus, the security policy configuration should be configured accordingly using the AppGW VNet prefix to ensure it is treated as the inbound flow. The original source IP of the client is not preserved at layer 3.
62
-
63
-
Non-web traffic can continue using the Cloud NGFW’s public IP address(s) and DNAT rules.
63
+
Once the infrastructure is deployed and configured, there must be a security policy applied to the Cloud NGFW allowing the connection from the AppGW VNet. The AppGW proxies the client’s TCP connection and creates a new connection to the destination specified in the backend target. The source IP of this connection is the private IP address from the AppGW subnet. Thus, the security policy configuration should be configured accordingly using the AppGW VNet prefix to ensure it's treated as the inbound flow. The original source IP of the client isn't preserved at layer 3.
64
64
65
+
Nonweb traffic can continue using the Cloud NGFW’s public IP addresses and DNAT rules.
65
66
66
67
### vWAN
67
68
68
-
Securing vWAN Hub using the Palo Alto Networks SaaS solution is the most effective and easiest way to guarantee your vWAN stays secure with a consistent security policy applied across the entire deployment.
69
+
Securing vWAN Hub using the Palo Alto Networks SaaS solution is the most effective and easiest way to guarantee your vWAN stays secure with a consistent security policy applied across the entire deployment.
69
70
70
-
Routing Intent and Policy must be configured to use Cloud NGFW resource as a Next Hop for Public and/or Private traffic. Any connected spoke VNet or VPN/ExpressRoute Gateway would get the routing information to send the traffic via the Cloud NGFW resource.
71
+
Routing Intent and Policy must be configured to use Cloud NGFW resource as a Next Hop for Public and/or Private traffic. Any connected spoke VNet or VPN/ExpressRoute Gateway would get the routing information to send the traffic through the Cloud NGFW resource.
71
72
72
73
:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-vwan.png" alt-text="Diagram shows Cloud NGFW architecture with Application Gateway in vWAN Hub deployment.":::
73
74
74
-
By default, the VNet connection to the hub has the “Propagate Default Route” flag set to “Enabled”. This installs a 0.0.0.0/0 route forcing all non-matched traffic sourced from that VNet to go via the vWAN hub. In this topology, this would result in asymmetric routing as the return traffic proxied by the AppGW will go back to the vHub instead of the Internet. Hence, when connecting the AppGW VNet to the vWAN hub, set this attribute to “Disabled” to allow the AppGW-sourced traffic to break out locally.
75
+
By default, the VNet connection to the hub has the _Propagate Default Route_ flag set to `Enabled`. This installs a 0.0.0.0/0 route forcing all nonmatched traffic sourced from that VNet to go through the vWAN hub. In this topology, this would result in asymmetric routing as the return traffic proxied by the AppGW goes back to the vHub instead of the Internet. Hence, when connecting the AppGW VNet to the vWAN hub, set this attribute to **Disabled** to allow the AppGW-sourced traffic to break out locally.
In some cases, this may not be desirable. For example, when there are other applications or workloads hosted in the AppGW VNet requiring the inspection by the Cloud NGFW. In this case, you can enable the default route propagation but also add a 0.0.0.0/0 route to the AppGW subnet to override the default route received from the hub. An explicit route to the application VNet is also required.
81
+
In some cases, this might not be desirable. For example, when there are other applications or workloads hosted in the AppGW VNet requiring the inspection by the Cloud NGFW. In this case, you can enable the default route propagation but also add a 0.0.0.0/0 route to the AppGW subnet to override the default route received from the hub. An explicit route to the application VNet is also required.
@@ -89,30 +90,28 @@ You can locate the Next Hop IP address of the Cloud NGFW by looking at the effec
89
90
90
91
### Azure Rulestack
91
92
92
-
Azure Rulestack allows configuring the security rules and applying the security profiles right in the Azure Portal or via the API. When implementing the architecture presented above, configure the security rules leverating Palo Alto Network’s patented App-ID, Advanced Threat Prevention, Advanced URL filtering and DNS security [Cloud-Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions) (CDSS).
93
+
Azure Rulestack allows configuring the security rules and applying the security profiles right in the Azure portal or through the API. When implementing the architecture presented previously, configure the security rules using Palo Alto Network’s App-ID, Advanced Threat Prevention, Advanced URL filtering, and DNS security [Cloud-Delivered Security Services](https://www.paloaltonetworks.com/network-security/security-subscriptions) (CDSS).
93
94
94
-
See [Cloud NGFW Native Policy Management Using Rulestacks](https://docs.paloaltonetworks.com/cloud-ngfw/azure/cloud-ngfw-for-azure/native-policy-management) for more details.
95
+
For more information, see [Cloud NGFW Native Policy Management Using Rulestacks](https://docs.paloaltonetworks.com/cloud-ngfw/azure/cloud-ngfw-for-azure/native-policy-management).
95
96
96
97
> [!NOTE]
97
98
> Use of X-Forwarded-For (XFF) HTTP header field to enforce security policy is currently not supported with the Azure Rulestack policy management.
98
99
99
100
### Panorama
100
101
101
-
When managing the Cloud NGFW resources using Panorama, users may leverage the existing and new policy constructs such as template stacks, zones, vulnerability profiles, etc. The Cloud NGFW security policies may be configured between the 2 zones: Private and Public. Inbound traffic goes from Public Zone to Private, Outbound is Private-to-Public, and East-West is Private-to-Private.
102
+
When you manage the Cloud NGFW resources using Panorama, you can use the existing and new policy constructs such as template stacks, zones, vulnerability profiles, etc. The Cloud NGFW security policies can be configured between the two zones: Private and Public. Inbound traffic goes from Public Zone to Private, Outbound is Private-to-Public, and East-West is Private-to-Private.
102
103
103
104
:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-zones-1.png" alt-text="Diagram shows Cloud NGFW zone placement and traffic flows":::
104
105
105
-
The ingress traffic coming through the Application Gateway is forwarded via the Private Zone to the Cloud NGFW resource for inspection and security policy enforcement as depicted in the diagram below.
106
+
The ingress traffic coming through the Application Gateway is forwarded through the Private Zone to the Cloud NGFW resource for inspection and security policy enforcement as depicted in the following image.
106
107
107
108
:::image type="content" source="media/palo-alto-app-gw/palo-alto-app-gw-zones-2.png" alt-text="Diagram shows Cloud NGFW zone placement and AppGW traffic flow.":::
108
109
109
-
Special considerations need to be applied to the zone-based policies to ensure the traffic coming from the Application Gateway is treated as Inbound i.e. security rules, threat prevention profiles, Inline Cloud Analysis and other. The traffic will be treated as Private-to-Private as the Application Gateway proxies the traffic and it is sourced using the Private IP address from the Application Gateway subnet.
Special considerations need to be applied to the zone-based policies to ensure the traffic coming from the Application Gateway is treated as Inbound, that is, security rules, threat prevention profiles, Inline Cloud Analysis and other. The traffic is treated as Private-to-Private as the Application Gateway proxies the traffic, and it's sourced using the Private IP address from the Application Gateway subnet.
-[Cloud NGFW for Azure](https://docs.paloaltonetworks.com/cloud-ngfw/azure/cloud-ngfw-for-azure)
115
+
-[Zero-trust network for web applications with Azure Firewall and Application Gateway](/azure/architecture/example-scenario/gateway/application-gateway-before-azure-firewall)
116
+
-[Firewall and Application Gateway for virtual networks](/azure/architecture/example-scenario/gateway/firewall-application-gateway)
117
+
-[Configure Palo Alto Networks Cloud NGFW in Virtual WAN](/azure/virtual-wan/how-to-palo-alto-cloud-ngfw)
0 commit comments