General Articles
LIVEcommunity's General Articles area is home to how-to resources, technical documentation, and discussions with Accepted Solutions that turn into articles related to all Palo Alto Networks products.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.
About General Articles
LIVEcommunity's General Articles area is home to how-to resources, technical documentation, and discussions with Accepted Solutions that turn into articles related to all Palo Alto Networks products.
Organizations often use Google Cloud’s Application Load Balancer to distribute HTTP/HTTPS traffic to VM-Series firewalls deployed within Google Cloud.   Diagram 1 In this setup, the Application Load Balancer functions as a proxy, altering the client's source address before forwarding the request to the VM-Series for security inspection. This may present challenges for organizations defining security policies based on the client's address or requiring IP preservation for backend applications protected by the VM-Series.   Using XFF Headers with PAN-OS Within PAN-OS, the firewalls can be configured to use the source address of an X-Forwarded-For (XFF) header to enforce security policy.  When configured, the firewall applies policy based on the address that was most-recently added to the XFF field.   However, when using the Application Load Balancer, this approach alone will not work.  This is because the load balancer appends two addresses to the XFF header, where the <load-balancer-ip> is the most-recent address within the header and the <client-ip> is the next-to-last address.     X-Forwarded-For: <client-ip>, <load-balancer-ip>     Solution Within the backend service configuration of the Application Load Balancer, you can define custom headers to make the client address the most-recently added address to the XFF field. When used, the load balancer preserves the supplied value of the custom header before the <client-ip>, <load-balancer-ip> addresses.       X-Forwarded-For: <supplied-value>, <client-ip>, <load-balancer-ip>     To insert the client’s address as the supplied value, you can use the client_ip_address header variable.  This variable contains the client’s IP address, and has the same value as the <client-ip> address.  Once configured, the VM-Series can then use the client’s address to enforce policy.   Diagram 2   Steps to Implement The steps below outline how to add the client_ip_address value as a custom header to an existing Application Load Balancer that uses the VM-Series as its backend service.   Adding Custom Request Header to Backend Service 1. In Google Cloud, go to Network Services → Load Balancing.  Select your Application Load Balancer and click Edit.   2. Select Backend Configuration and click the edit icon next to the backend service.  Selecting backend   3. Under Advance Configurations → Custom Request Headers, click Add Header.    4. Set the header name to X-Forwarded-For and the header value to {client_ip_address} . Adding customer header   5. Click Update to apply the changes.      Configure VM-Series for XFF Headers 1. On the VM-Series, go to Device → Setup → Content-ID → X-Forwarded-For Headers.   2. Set Use X-Forwarded-For Header to  Enabled for Security Policy . Enabling XFF for policy.   3. Commit the changes.   View Traffic Logs Once the changes have been applied, you can view the value of the client_ip_address header within the firewall's traffic logs.    1. Simulate traffic flows through the Application Load Balancer to your application.    2. Go to Monitor → Traffic and add the X-Forwarded-For IP field to the log view. Log viewer.   The traffic logs should now contain the client's IP address under the X-Forwarded-For IP column.  This address can then be used as the source address within the VM-Series security policies.    Traffic logs
View full article
This blog outlines the best practices for upgrading the VM series firewalls in AWS.  
View full article
This article provides the steps to setup, demonstrate and teardown the Palo Alto Networks' VM-Series Next Generation Firewalls on AWS in integration with the AWS Gateway Load Balancer.  
View full article
This article describes the best practices for sizing Palo Alto Networks' VM-Series Next Generation Firewalls deployed on Google Cloud. Proper sizing of the deployment is very important because it provides an fairly accurate picture of how many firewalls would be needed to handle the customer’s traffic.  
View full article
Digitization has revolutionized banking, empowering fintech firms to offer innovative services. Banks collaborate with fintech companies to enhance offerings and reach more customers. This shift is driven by the need to adapt to scalability and resiliency requirements.  
View full article
This document describes the use-cases, architecture design and traffic flows for Palo Alto Networks VM-Series deployed in Active-Passive mode in Google Cloud.  
View full article
Palo Alto Networks covers the deployment of the VM-Series Next-Generation Firewall on the ESXi hypervisor in Layer2 mode.
View full article
Palo Alto Networks VM-Series Next-Generation Firewall for Google Cloud is the industry-leading virtualized firewall to protect applications and data.
View full article
    Introduction Palo Alto Networks VM-Series Next-Generation Firewall for Google Cloud is the industry-leading virtualized firewall to protect applications and data with next-generation security features that deliver superior visibility, precise control, and threat prevention at the application level.  Google Cloud internal TCP/UDP Load Balancing enables end-users to run and scale VM-Series deployments behind a single internal IP address. The VM-Series can be deployed in zonally dispersed managed instance groups to scale up and down based PAN-OS metrics delivered to Google Cloud StackDriver.  Traffic from the VPC network can be routed to the load balanced firewalls by creating a custom static route that uses the internal TCP/UDP load balancer as the next hop.  Here are some of the benefits of using TCP/UDP load balancing as next hop in your VPC network:    Load balance traffic across VM-Series firewalls to protect applications and data with next-generation security features at scale.  Leverage Google Cloud managed instance groups to horizontally scale VM-Series firewalls across regions and zones.  Enable Symmetric Hashing to maintain original client IP address. Provide high availability with reliable failover through cloud load balancer health checks.    Symmetric Hashing   Overview Historically, source network address translation, or SNAT, has to be applied when routing east-west traffic through load balanced VM-Series firewalls. SNAT can be avoided by either removing the load balancer or by configuring the load balancer’s backend service to use a primary and failover instance group.  However, implementing either of these workarounds limits your ability to effectively scale firewalls for your east-west traffic flows.  Google Cloud announced general availability of an internal TCP/UDP load balancer feature called symmetric hashing.  Symmetric hashing maps a given traffic flow to a VM-Series firewall while ignoring the directionality of the IP addresses and ports.  This capability ensures server response traffic traverses through the same VM-Series firewall that received the initial client request without proxying or obscuring the initial client IP address.  Symmetric hashing can be enabled on your internal TCP/UDP load balancer as long as the following statements are true:   The forwarding rule for the internal TCP/UDP load balancer was created on or after June 22, 2021. The custom static route referencing the forwarding rule was created on or after June 22, 2021. The internal TCP/UDP load balancer’s backend service does not use the NONE session affinity setting.   East-West Security with Network Peering  In this model, you can deploy compute resources in the same project as the VM-Series firewall, or distribute compute resources across multiple projects with unique VPC networks and administrative domains.  VPC Network Peering by Google Cloud enables you to centralize security by connecting spoke networks to a hub network that contains load balanced VM-Series firewalls.  Custom routes defined in the hub network use the VM-Series internal TCP/UDP load balancer as the next hop.  The routes can then be propagated to the spoke network’s route table via Network Peering's import/export custom route functionality.   If symmetric hashing is enabled on the internal TCP/UDP load balancer, the VM-Series can be deployed into managed instance groups to automatically scale based on utilization metrics.   Example 1. The hub network contains VM-Series firewalls deployed in a managed instance group that serve as the backend of an internal TCP/UDP load balancer with symmetric hashing enabled.  The hub network has a custom default route that uses the TCP/UDP load balancer as the next hop.  This route is propagated over the VPC peering connection (via import/export custom routes) to spoke1 and spoke2 VPC network’s route table.  Below is an example of how a request is routed and handled by the internal load balancer with symmetric hashing enabled.   Client Request A TCP request from SPOKE1-VM (10.1.0.2) to SPOKE2-VM (10.2.0.2) is routed to the hub VPC network peering connection via the imported default custom route from the hub VPC network. The custom default route in the hub network routes the request to the TCP/UDP load balancer forwarding rule.  The load balancer sends the request to any of the available VM-Series firewalls for inspection (availability dependent on load balancer health checks). After inspection, the VM-Series sends the request into the hub network where it is then routed to the spoke2 peering connection. Hub-and-Spoke with Symmetric Hashing - Client Request Traffic   Server Response The TCP response from SPOKE2-VM (10.2.0.2) to SPOKE1-VM (10.1.0.2) is routed to the hub VPC network peering connection via the imported default custom route from the hub VPC network. The custom default route in the hub network routes the response to the TCP/UDP load balancer forwarding rule. Symmetric hashing on the load balancer sends the response to the same VM-Series firewall that received the initial client request (without proxying or using source network address translation). The VM-Series sends the response into the hub’s network where it is routed to spoke1 peering connection and the session is established. Hub and Spoke with Symmetric Hashing - Server Response Traffic     Example 2. In this example, the VM-Series firewalls secure traffic between the production, development, and QA VPC networks.  Within each VPC, the VM-Series dataplane interfaces are the backend service of separate internal TCP/UDP load balancers; each of which have symmetric hashing enabled.  A custom default route is defined in the production VPC to use the production load balancer as the next hop.  Likewise, a custom default route is defined in the development VPC network to use the development load balancer as the next hop.  Even though the request and response traffic are sent through separate TCP/UDP load balancers, the VM-Series does not need to apply SNAT to maintain symmetry.  Symmetric hashing ensures packets that are a part of the same flow use the same firewall for a given session.  If desired, you can still apply SNAT, but it is not required.       Scale Security for Outbound Traffic for Global VPC Networks   VPC networks, including their associated routes and firewall rules, are global resources.  They are not associated with a particular region or zone.  The VPC network’s subnets determine regionality.  This provides organizations with the unique ability to have cloud resources deployed globally, while maintaining a small VPC network footprint with a centralized route domain and firewall rule set.  The VM-Series firewall with Google Cloud’s internal load balancer can handle egress requests from regions that are different from its own.  For example, if the VM-Series and internal load balancer are deployed in region1, requests from region2 and region3 can be routed to the region1 firewalls.  However, this may be undesirable due to cross region transaction costs, latency considerations, and cross-region resiliency requirements.    You could deploy load balanced VM-Series firewalls in regions that are reflective of your workload’s locations.  However, this design previously presented a design issue.  If two or more custom static routes with the same destination using different internal TCP/UDP load balancers as the next hop, the traffic could not be distributed among the load balancers using ECMP.   This limitation can be completely overcome by leveraging Google Cloud’s network tags.  Network tags make routes applicable only to instances that use the corresponding network tag and can be used for a variety of use-cases, including:    Prevention of cross-region traffic flows. Isolation of egress traffic between development environment and production environments. Creation of “swimming-lanes” to distribute traffic to different sets of load balanced firewalls.   Example 3. The diagram below is an example of how to use network tags to prevent cross region traffic flows for outbound internet requests.  The trust VPC route table has two default routes: default-east and default-west.  Each route has a unique network tag applied to it: vmseries-east and vmseries-west.   Although both routes belong to the VPC route table, the routes are only applied to compute resources that share the same network tag.   For example, the compute resources in the us-east subnets have the east-vmseries tag applied.  This ensures resources residing in us-east will only use the us-east VM-Series firewall set.  Likewise, compute resources in us-west have the west-vmseries network tag applied to force us-west traffic through the us-west VM-Series firewall set.    Network Tags for Internal Load Balancer as Next Hop   The end result with network tags is you do not need to segregate different client instances into separate VPC networks, each pointing to their preferred internal TCP/UDP load balancer front-ending a  set of VM-Series firewalls.  Below is an example architecture of using network tags to isolate regional subnet traffic flow through a set of firewalls that share the same region   More Information Google Cloud - Internal TCP/UDP Load Balancers as Next Hop  Google Cloud - Setting up Internal TCP/UDP Load Balancing for Third-Party Appliances Google Cloud - Internal TCP/UDP Load Balancing and Connected Networks Setup Palo Alto Networks VM-Series on Google Cloud  Terraform Build - Google Cloud VM-Series ILBnH with Network Tags   
View full article
Alibaba Cloud recently introduced a feature called HAVIP allow VM-Series firewalls to be deployed in active/standby mode.
View full article
With CEN-TR, VM-Series firewalls can be deployed in a Security VPC to protect inbound, outbound and east/west traffic between a large number of VPCs on Alibaba Cloud.
View full article
Palo Alto Networks is proud to announce the availability of our VM-Series virtual next-generation firewalls on Oracle Cloud Marketplace.
View full article
This presentation was prepared by Kambiz Kazemi in 2019 on how to deploy VM Series on a single VPC at Alibaba Cloud. The presentation includes the following sections: Before you begin Routing Considerations Load Balancer Considerations Supported designs Create Custom VM-Series Image for Alibaba Cloud Deploying VM-Series in Alibaba Cloud Building Outbound flow architecture with HA Building Inbound flow architecture – LB Sandwich  
View full article
The VM-Series auto scale templates in GitHub® can deliver centralized security and connectivity for your large-scale server and Kubernetes deployments.
View full article
Discover how organizations leverage hybrid cloud infrastructure for a balanced approach, combining public and private clouds to meet specific business needs while optimizing costs and ensuring security.  
View full article
  • 182 Posts
  • 257 Subscriptions
Customer Advisories

Your security posture is important to us. If you’re a Palo Alto Networks customer, be sure to login to see the latest critical announcements and updates in our Customer Advisories area.

Learn how to subscribe to and receive email notifications here.

Listen to PANCast

PANCast is a Palo Alto Networks podcast that provides actionable insights to customers, helping you maximize your investment while improving your cybersecurity posture.

Labels
Top Contributors
Top Liked Posts in LIVEcommunity Article
Top Liked Authors