How I Deployed Palo Alto NGFW VM Series on GCP
Overview
This articles details the Deployment and Configurations of Palo Alto VM Series on GCP for the Use Case of Monitoring the Outbound Traffic (From GCP to Internet) with the ultimate goal of having centralized control through Panorama hosted on-prem.
The VM-Series NGFW helps secure workloads deployed across both VPC networks and corporate/remote networks. Consider the following ways that the VM-Series NFGW can help to secure network patterns:
- Prevent inbound threats from the internet to resources deployed in VPC networks, on-premises, and in other cloud environments.
- Stop outbound connections from VPC networks to suspicious destinations, such as command-and-control servers, or malicious code repositories.
- Prevent threats from moving laterally between workload VPC networks and stealing data.
- Secure traffic between remote networks connected through Cloud Interconnect, Network Connectivity Center, or Cloud VPN.
- Help extend security to remote users and mobile devices to provide granular application access to Google Cloud resources.
Architecture
VM-Series NGFW is deployed through Compute Engine. Securing the users, applications, and data residing in your VPC networks requires a minimum of three network interfaces. The network interfaces are as follows:
- Management
- Untrust
- Trust
The following diagram shows the components required to help secure network traffic with the VM-Series firewall. The management network provides access to on-premises networks to provide private access in this case to Panorama hosted on-prem. The untrust network serves as the VM-Series user interface. It is common to connect the management network to an internet gateway for resources deployed to the trust network. The trust network contains the cloud workloads that you want to protect. Panorama Management provides centralized management of the VM-Series firewalls.
Panorama Management can be deployed either as a Compute Engine virtual appliance in Google Cloud, or as a virtual or physical appliance in an on-premises data center.
Important Note: For the VM-Series appliances to receive traffic from any Google Cloud external load balancer, a management interface swap must be performed. This swap also makes the untrust interface the primary interface of the appliance. If load balancing is not used, an interface swap should still be performed at deployment. If an interface swap is not performed at deployment, the VM-Series appliance must be redeployed.
In the presented case as there is no External Load Balancer and traffic flows outbound only, swap is not needed.
License Model and Credits
The VM-Series firewall supports the following license types:
- Pay-as-you-go (PAYG) — A pay-as-you-go license model is also called a usage-based or pay-per-use license. This type of license can be purchased from the Google Cloud Marketplace, and it is billed hourly.
- Bring Your Own License (BYOL) — A bring-your-own license model allows organizations to purchase a license from a partner or reseller or directly from Palo Alto Networks. In a BYOL model, VM-Series firewalls support all capacities, support entitlements, and subscription licenses. The BYOL model uses Software NGFW Credits for licensing.
Software NGFW Credits are term-based credits. The term is between one and five years. These credits to fund software NGFWs (VM-Series and CN-Series, Cloud-Delivered Security Services, and virtual Panorama appliances).
Credits can be allocated by creating a deployment profile in the support portal. The profile’s capabilities are dependent on the PAN-OS version that is being deployed:
- VM-Series firewalls on PAN-OS version 10.0.3 and earlier — Compatible with legacy licenses based on VM-Series Models and security service bundles.
- VM-Series firewalls on PAN-OS version 10.0.4 and later — Flexible number of vCPUs (from 1–32) and flexible selection of security services. The deployment profile is modified in order to add or decrease the number of vCPUs or add new services as they become available
Google Organization Policies & Constraints
Most organizations are locked in and have multiple policies enforced preventing deployment of Palo Alto NGFW, for the following policies exceptions have to be made to allow the deployment of Palo Alto appliances:
- constraints/compute.vmCanIpForward — By default, a Compute Engine instance cannot forward a packet unless the source IP address of packet matches the IP address of the instance. Similarly, Compute Engine won’t deliver a packet whose destination IP address is different from the IP address of the instance receiving the packet. However, both capabilities are required to help route packets. This policy has been disabled for the Google Cloud project where the Palo Alto appliances are located.
- constraints/compute.disableSerialPortAccess — Serial ports provide a direct line into a VM, potentially allowing unauthorized access. By restricting access, Google Cloud helps prevent attackers from exploiting this backdoor to gain control of the VM. Furthermore, unlike SSH or other remote access methods, serial console access typically lacks features like IP allowlisting. This means anyone with the correct information (project ID, zone, VM name) could potentially connect. However, this capability is required by the network engineer to allow troubleshooting of the appliances. This policy has been disabled for the Google Cloud project where the Palo Alto appliances are located.
- constraints/compute.trustedImageProjects — By default, instances can be created from images in any project that shares images publicly or explicitly with the user. Restricting virtual machine (VM) images to trusted sources (projects) ensures they meet an organization’s security and compliance standards. This prevents VMs from booting with untested or potentially vulnerable software. This policy’s constraints have been updated to allow using images from the Palo Alto project: paloaltonetworksgcp-public.
GCP Firewall
Google Cloud firewall rules filter network traffic entering and leaving virtual machine instances. A Google Cloud firewall rule is part of the VPC network configuration and applies to either inbound or outbound traffic. Firewall rules are stateful, meaning that they permit return traffic associated with permitted inbound or outbound traffic rules. Google Cloud firewall rules can be associated with all instances in a VPC network, instances possessing specific tags, or instances linked to specific service accounts.
Google Cloud applies firewall rules based on their priority. Priority is part of the rule definition, where the lower the value, the higher the priority. Google Cloud applies the highest priority rule that matches the traffic and ignores any lower-priority rules.
The default Google Cloud firewall rules block inbound traffic to an instance, it is mandatory to create explicit rules that allow traffic into the VM-Series instance.
Required Google Cloud firewall rules:
- Allow TCP/22 and 443 traffic into the VM-Series management interface from the public IP address or range from which you are managing the firewall.
- Allow all traffic into the VM-Series management interface from the private IP range where you deployed Panorama.
- Allow application traffic into the VM-Series instance on the public VPC network from all or a select set of sources.
- The Google Cloud firewall rule can be broad, allowing all traffic or allowing specific ports and protocols, such as TCP/80 and 443.
- Allow traffic into the VM-Series instance on the private VPC network from all IP subnets in the private VPCs.
Note: Above list of rules are minimum set of rules and additional sources can be added in allow list on need basis. By default, all egress communication is allowed and Ingress communication is denied. IAP subnet (35.235.240.0/20) is the source which is used by TCP proxy to securely access virtual machines. Google Frontend IPs are the subnets which will be used as source of traffic and health check probes while using GCP load balancers.
Deployment
Various deployment methods exist for VM-Series firewalls on GCP. Predefined VM-Series solutions are accessible through the Google Cloud Marketplace and code repositories like GitHub. Solutions within the marketplace facilitate the customization of settings such as administrator details, interface quantity, VPC network, subnet, and virtual machine dimensions. By default, marketplace solutions feature three interfaces (management, untrusted, and trusted) with the option to incorporate additional interfaces, up to a maximum of 8 interfaces per virtual machine.
Bootstrapping
For my deployment I have used Bootstrapping which allows for the creation of a repeatable and streamlined process for deploying new VM-Series firewalls on a network. This approach involves creating a package with the model configuration for the network, which can then be used to deploy VM-Series firewalls anywhere needed.
The bootstrap package must include the /config, /license, /software, and /content folders, even if they are empty. The /plugins folder is optional.
- /config folder — Contains the configuration files. The folder can hold two files: init-cfg.txt and the bootstrap.xml
- /license folder — Contains the license keys or auth codes for the licenses and subscriptions that are intended to activate on the firewalls.
- /software folder — Contains the software images required to upgrade a newly provisioned VM-Series firewall to the desired PAN-OS version. All intermediate software versions between the current version and the final PAN-OS software version must be included.
- /content folder — Contains the application and threat updates, WildFire updates, and the BrightCloud URL filtering database for the valid subscriptions on the VM-Series firewall.
- /plugins folder — Contains a single VM-Series plugin image.
The delivery of the bootstrap package to the VM-Series appliances that are deployed in Google Cloud is done through Storage Bucket. The bucket is created and managed by the Terraform module provided by Google Cloud.
module "bootstrap_bucket" {
source = "terraform-google-modules/cloud-storage/google"
version = "5.0.0"
project_id = var.project_id
names = [var.bootstrap_bucket_name]
versioning = { (var.bootstrap_bucket_name) = true }
force_destroy = { (var.bootstrap_bucket_name) = true }
set_viewer_roles = true
bucket_viewers = { (var.bootstrap_bucket_name) = "serviceAccount:${module.vmseries_service_account.email}" }
}
The custom-developed Terraform module to manage the bootstrap package will then upload the configuration files for each VM-Series appliance to the bucket.
module "bootstrap" {
source = "./modules/bootstrap"
bucket = module.bootstrap_bucket.name
folders = keys(var.vmseries)
files = merge(
{ for k, v in var.vmseries : "files/${k}/config/bootstrap.xml" => "${k}/config/bootstrap.xml" },
{ for k, v in var.vmseries : "files/${k}/config/init-cfg.txt" => "${k}/config/init-cfg.txt" },
{ for k, v in var.vmseries : "files/${k}/license/authcodes" => "${k}/license/authcodes" },
)
depends_on = [
local_file.bootstrap,
local_file.initcfg,
local_file.license,
]
}
For Appliances I used a custom-developer Terraform module that will provision and manage the appliances is backed by the following resources:
- google_compute_instance — compute instances are virtual machines part of Compute Engine.
- google_compute_instance_group — instance group allows to logically group a set of instances which can then serve as the target of a load balancer’s backend service.
module "vmseries" {
source = "./modules/vmseries"
for_each = var.vmseries
project_id = var.project_id
name = each.key
region = each.value.region
labels = each.value.labels
metadata = each.value.metadata
machine_type = each.value.machine_type
min_cpu_platform = each.value.min_cpu_platform
source_image = each.value.source_image
source_image_family = each.value.source_image_family
source_image_project = each.value.source_image_project
network_interfaces = each.value.network_interfaces # Network interfaces - NIC0,NIC1,NIC2
named_ports = each.value.named_ports
bootstrap_options = merge(
{
vmseries-bootstrap-gce-storagebucket = "${module.bootstrap_bucket.name}/${each.key}/"
},
each.value.bootstrap_options,
)
service_account = {
email = module.vmseries_service_account.email
scopes = ["cloud-platform"]
}
}
A firewall appliance is created for each element found in the Terraform variable vmseries map. The map’s key serves as the name of the virtual machine in Compute Engine and the object holds the configuration.
variable "vmseries" {
description = "Definition of Palo Alto VM-Series instances."
type = map(object({
region = string
labels = map(string)
metadata = map(string)
machine_type = optional(string, "n2-standard-8")
min_cpu_platform = optional(string, "Intel Cascade Lake")
source_image = string # "vmseries-flex-bundle1-1008h8"
source_image_family = string # "vmseries-100"
source_image_project = string # "paloaltonetworksgcp-public"
tags = optional(list(string), [])
can_ip_forward = optional(bool, true)
network_interfaces = map(object({
network = string
subnetwork = string
network_ip = optional(string)
network_public_ip = optional(string)
}))
named_ports = optional(list(object({
name = string
port = number
})), [])
bootstrap_options = object({
hostname = string
vm-auth-key = string
panorama-server = string
panorama-server-2 = string
tplname = string
dgname = string
cgname = optional(string, "")
dns-primary = string
dns-secondary = string
})
bootstrap_template_map = object({
TRUST_GCP_ROUTER_IP = string
UNTRUST_GCP_ROUTER_IP = string
TRUST_LOOPBACK_IP = optional(string, "")
UNTRUST_LOOPBACK_IP = optional(string, "")
})
}))
}
Management Interface
By default, the first interface attached to the instance is the firewall’s management interface. In most instance templates, this interface has a public IP address and a private IP address in the VPC. The firewall’s management interface obtains its private IP address through DHCP. If the management interface is configured with a public internet address, Google Cloud networking translates the private IP address to the public IP address when the traffic leaves the VPC.
Monitoring with the Panorama
The utilization of an on-premises Panorama appliance for managing firewalls safeguarding both the data center and internet edge is applicable for managing the VM-Series firewalls within Google Cloud. Additionally, it is advisable to extend considerations beyond firewall management to encompass log collection and retention strategies.
Log collection, storage, and analysis is an important cybersecurity best practice that organizations perform in order to correlate potential threats and prevent successful cyber breaches. Sending logging data back to the on-premises Panorama can be inefficient and costly, and in some regions, it can pose data privacy and residency issues. An alternative to sending the logging data back to on-premises Panorama is to deploy Panorama dedicated log collectors on Google Cloud and use the on-premises Panorama appliance for management.
Implementing a dedicated log collector on Google Cloud minimizes the volume of logging data transmitted outside the cloud environment. This setup enables seamless management of VM-Series firewalls within Google Cloud by your on-premises Panorama appliance while ensuring comprehensive visibility into logs, as required.
Results
Make sure you verify that bootstrapping is successful and licensing is performed accordingly, as well as there is connectivity with Panorama. Here is how to do it.
Useful commands
Verify Bootstrap Completion
> show system info
> show config running
> request license info
Other Commands
> show system software status
> show system resources
> show admins
> request restart system
> show routing route
Deployed Palo Alto VMs
Panorama Connecting to GCP Palo Alto VMs using Management Interface:
Hope this articles was helpful for you, all the best in your Palo Alto Deployment !
#paloalto #ngfw #gcp