Revision Guide · Certified Next-Generation Firewall (NGFW) Engineer
Software Firewalls: VM-Series & Public Cloud
~17 min read
Prerequisites: Containers & Kubernetes — this module widens from CN-Series to the full VM-Series/public-cloud picture.
Cloud Network Security Concepts 37
Software Firewall (NGFW) course · Cloud Network Security
Learning objectives
- Explain the shared-responsibility model as it applies to network security in public cloud
- Name the recurring cloud-native constructs VM-Series integrates with (load balancers, transit gateways, autoscaling)
Moving NGFW into public cloud isn't just "run the same appliance on a different hypervisor" — it means integrating with cloud-native constructs (load balancers, autoscaling groups, transit routing) that don't exist in a traditional data center.
Why
Cloud providers secure the underlying infrastructure, but you remain responsible for securing what runs on top of it — network segmentation, traffic inspection, and policy are still the customer's job under the shared-responsibility model. Cloud workloads also scale elastically, so a static-capacity firewall design doesn't fit; security has to scale with the workload.How
VM-Series in public cloud plugs into cloud-native traffic steering rather than requiring physical rewiring: load balancers and Gateway Load Balancers distribute traffic across an autoscaled firewall fleet (see AWS GWLB / Azure GWLB), transit gateways/hubs centralize routing so one security VPC/VNet can inspect traffic for many spoke VPCs/VNets, and autoscaling adds/removes firewall instances based on load instead of provisioning for peak capacity permanently. The same App-ID/User-ID/Content-ID policy model carries over unchanged — what differs is how traffic gets steered to the firewall, not what the firewall does with it once it arrives.
Pros
- Autoscaling avoids permanently over-provisioning for peak traffic
- Hub-and-spoke/transit designs centralize inspection instead of a firewall per VPC/VNet
- Consistent policy model with on-prem NGFW — no separate cloud rulebase language to learn
Cons
- Shared-responsibility confusion is a real, recurring cause of cloud misconfiguration incidents — "the provider secures it" is a common false assumption
- Each cloud's native constructs (GWLB, transit gateway, NSX-T service insertion) have their own quirks — expertise doesn't fully transfer between clouds
Exam trap
Don't assume the cloud provider secures your traffic inspection. Under the shared-responsibility model, the provider secures the underlying infrastructure — network segmentation, traffic inspection, and policy enforcement inside your VPC/VNet remain your job.Self-check
1. Your team assumes AWS/Azure automatically inspects and blocks malicious traffic between two of your VPCs. Why is this assumption wrong?
A: The shared-responsibility model covers the underlying cloud infrastructure, not what runs on top of it — network segmentation and traffic inspection between your own VPCs/VNets is the customer's responsibility, which is exactly the gap VM-Series (via a hub/transit design) is built to fill.
2. Why is a hub-and-spoke/transit gateway design generally preferred over deploying a firewall pair in every application VPC?
A: It centralizes inspection so one autoscaled firewall fleet protects many spoke VPCs/VNets, avoiding per-VPC firewall management overhead — though it does concentrate risk onto that shared hub.
Curriculum: Software Firewall (NGFW) course, "Cloud Network Security" lesson; cross-referenced against the VM-Series public/private cloud deployment docs.
VM-Series Requirements & Licensing 38
Software Firewall (NGFW) course · VM-Series Requirements and Licensing
Learning objectives
- Compare flexible vCPU (Software NGFW Credits) vs. fixed VM-Series Model licensing
- Compare BYOL vs. PAYG license types
VM-Series licensing has two independent axes to choose: how you pay (BYOL vs. PAYG) and how capacity is defined (flexible vCPU credits vs. a fixed model) — picking the right combination shapes both cost and deployment flexibility.
Why
Cloud-native workloads want elastic, pay-for-what-you-use capacity; traditional enterprise buyers often want predictable, pre-purchased capacity tied to an existing agreement. One licensing model can't serve both well, so VM-Series offers both.How
License type: BYOL (bring your own license, purchased and activated against your support account) vs. PAYG (bought hourly/usage-based directly from a cloud marketplace — AWS/Azure/GCP — or a CSSP). Capacity model: Software NGFW Credits (flexible vCPU) — reusable credits you activate, pool, then spend via a deployment profile that bundles vCPU count, chosen security services, and optional Panorama, up to 64 vCPUs on PAN-OS 10.0.4+; all firewalls sharing that profile share one auth code and update together — vs. VM-Series Model licenses (fixed vCPUs per model — VM-100/300/500/700), sold as an Enterprise License Agreement token pool, a perpetual capacity license, or a term license, each optionally bundling Threat Prevention and other services. Flexible-vCPU deployment profile changes propagate automatically (no reboot); changing a fixed model requires a new license and a reboot.
Pros
- Software NGFW Credits let you resize a fleet's vCPU/service mix without reboots, matching cloud elasticity
- Fixed VM-Series Models suit organizations that prefer predictable, pre-committed capacity and cost
- PAYG marketplace billing removes upfront procurement friction for short-lived or trial deployments
Cons
- Two independent licensing axes (type × capacity model) is genuinely more to get right than a single SKU
- Changing a fixed-model firewall's capacity requires a new license and a reboot — real downtime, unlike a credit-based profile change
- New (non-Software-NGFW-Credits) capacity licenses are no longer sold — only renewals — pushing new deployments toward the credit model whether or not it fits the buying pattern
Exam trap
A Software NGFW Credits deployment-profile change propagates automatically with no reboot; changing a fixed VM-Series Model's capacity requires a new license and a reboot. Don't assume both capacity models behave the same way operationally.Self-check
1. A customer wants to resize firewall vCPU/service mix frequently without downtime. Which capacity model fits, and why?
A: Software NGFW Credits (flexible vCPU) — deployment-profile changes apply automatically without a reboot, unlike the fixed VM-Series Model, which needs a new license and a reboot to change capacity.
2. What are the two independent axes of VM-Series licensing, and what does each one decide?
A: License type (BYOL vs. PAYG) decides how you pay; capacity model (Software NGFW Credits vs. VM-Series Model) decides how firewall capacity is defined and changed.
Source: vm-series/activation-and-onboarding/vm-series-firewall-licensing
VM-Series Traffic Flow Designs 39
Software Firewall (NGFW) course · Traffic Flow Designs and Features for VM-Series
Learning objectives
- Name the three traffic directions a cloud NGFW deployment typically protects
- Explain why centralized (hub) inspection is the common target design
Regardless of which public or private cloud it runs in, VM-Series deployments are generally designed around the same three traffic patterns: north-south inbound, north-south outbound, and east-west.
Why
Each direction carries a different threat model — internet-facing inbound traffic needs to be defended against exploits and vulnerability scans, outbound traffic needs to be prevented from exfiltrating data or reaching malicious infrastructure, and east-west (inter-VPC/VNet/subnet) traffic needs to stop malware or a compromised workload from moving laterally. A single design has to account for all three without three separate, unrelated firewall deployments.How
Inbound protects externally-reachable resources (web servers) from exploits and vulnerabilities in traffic that a cloud security-group/NSG already allowed. Outbound ensures workloads only reach permitted destinations/URL categories and blocks data exfiltration, while still scanning return traffic for malware. East-West inspects traffic between VPCs/VNets/subnets to contain malware propagation and enforce segmentation between application tiers or business units. The common target architecture centralizes all three into a shared security VPC/VNet (a "hub"), reached via Gateway Load Balancer endpoints or a transit gateway, rather than deploying and managing a firewall pair per application VPC.
Pros
- Centralized hub design means one firewall fleet protects many application VPCs/VNets instead of one per VPC
- Same three-direction model applies consistently whether you're on AWS, Azure, GCP, or NSX-T
Cons
- Centralized hub designs concentrate risk — the security VPC/VNet becomes a critical path for every application VPC behind it
- Symmetric routing (traffic returning through the same firewall instance that inspected the outbound leg) has to be engineered deliberately or connections break
Exam trap
A centralized hub design only works if return traffic is pinned to the same firewall instance that inspected the outbound leg. Asymmetric routing silently breaks stateful inspection (decryption, session tracking) — this is engineered deliberately, not automatic.Self-check
1. Name the three traffic directions a cloud NGFW hub design typically protects, and one threat each direction defends against.
A: Inbound (exploits/vulnerability scans against internet-facing resources), outbound (data exfiltration and malicious destinations), east-west (lateral malware movement between VPCs/VNets/subnets).
2. What is the main downside of concentrating inbound, outbound, and east-west inspection into one shared security VPC/VNet hub?
A: It concentrates risk — the hub becomes a critical path for every application VPC behind it, and symmetric routing must be engineered correctly or connections break.
Curriculum: Software Firewall (NGFW) course, "Traffic Flow Designs and Features for VM-Series" lesson; cross-referenced against the AWS/Azure GWLB integration docs.
VM-Series on AWS 40
Software Firewall (NGFW) course · VM-Series Firewall on AWS / Deployment and Network Integration
Learning objectives
- List what's required to deploy VM-Series on AWS
- Name the AWS-specific deployment variants (GovCloud, China, Outposts)
VM-Series on AWS runs as a standard EC2 instance, secured with the same PAN-OS policy engine, but licensed and network-integrated through AWS-specific plumbing (AMIs, the AWS plugin, Panorama's AWS plugin).
Why
Workloads on EC2 need the same App-ID/Content-ID protection as on-prem servers, but the deployment mechanics (image sourcing, licensing, autoscaling, network attachment) have to speak AWS's native model rather than a traditional hardware install process.How
Deploying requires an AWS account, an Amazon Machine Image (AMI) ID for the VM-Series image, a license (PAYG from the AWS Marketplace or BYOL), the VM-Series plugin, Panorama, and the Panorama plugin for AWS (needed for license/config management at scale). AWS-specific variants extend the same firewall to specialized environments: AWS GovCloud (isolated region for US government compliance/CUI data — same feature set as standard AWS, but horizontally-scalable deployment only, and offline licensing needs CPU ID/UUID/auth-code entry via the CSP); AWS China (BYOL-only, via a separate AWS China account); and AWS Outposts (BYOL AMIs deployed on-premises AWS hardware, extending cloud consistency into your own data center).
Pros
- Same PAN-OS policy engine and management model as every other form factor — no separate cloud-only rule language
- GovCloud/China/Outposts variants extend one deployment pattern to regulated and on-prem-AWS environments
Cons
- GovCloud restricts you to horizontally-scalable deployment only — some designs from standard AWS don't carry over
- Offline GovCloud licensing (manual CPU ID/UUID/auth-code entry) is materially more operationally heavy than standard activation
- Requires its own account (China) or region-specific version/plugin minimums (GovCloud) — easy to trip on prerequisites
Exam trap
GovCloud restricts you to horizontally-scalable deployment only — don't assume every standard-AWS design pattern (or licensing/activation flow) carries over unchanged to GovCloud or China variants.Self-check
1. What five things does deploying VM-Series on standard AWS require?
A: An AWS account, an AMI ID for the VM-Series image, a license (PAYG via Marketplace or BYOL), the VM-Series plugin, and Panorama with the Panorama plugin for AWS.
2. How does AWS China licensing differ from standard AWS?
A: AWS China is BYOL-only, via a separate AWS China account — there's no PAYG marketplace shortcut there the way there is on standard AWS.
Source: vm-series/deployment/public-cloud/set-up-the-vm-series-firewall-on-aws/about-the-vm-series-firewall-on-aws
AWS Gateway Load Balancer Integration 41
Software Firewall (NGFW) course · AWS Gateway Load Balancer Integration
Learning objectives
- Explain what a Gateway Load Balancer Endpoint (GWLBE) does
- Trace the inbound, outbound, and east-west traffic paths through a GWLB-fronted firewall stack
AWS Gateway Load Balancer (GWLB) lets you insert an autoscaling stack of VM-Series firewalls transparently into inbound, outbound, and east-west traffic paths — exposed to the rest of the environment as a single VPC Endpoint Service.
Why
Manually routing every application VPC's traffic through a fixed firewall pair doesn't scale and doesn't tolerate firewall failure gracefully. GWLB turns the firewall fleet into an elastic, load-balanced, fault-tolerant service that other VPCs can consume like any other AWS-managed endpoint.How
Firewalls sit behind a GWLB in a centralized security VPC attached to a Transit Gateway (TGW). Traffic reaches the firewall via Gateway Load Balancer Endpoints (GWLBE) created in each spoke/application VPC and in the security VPC itself; GWLB and VM-Series use GENEVE encapsulation to keep original packet headers/payload intact end-to-end. Route tables direct traffic through the appropriate GWLBE: inbound traffic from the Internet Gateway routes to a GWLBE that sends it to the firewall, then on to the application via an ALB; outbound traffic from application VPCs routes via TGW to the security VPC's GWLBE, through the firewall, then out via a NAT Gateway; east-west traffic between two application VPCs routes through TGW into the same security-VPC GWLBE/firewall path before reaching its destination VPC. Appliance mode must be enabled on the TGW VPC attachment for the security VPC so that request and response traffic are pinned to the same firewall instance (symmetric routing) — without it, GWLB can't maintain per-flow persistence to the correct firewall. VM-Series supports full decryption (including TLS 1.2/1.3 with DHE/ECDHE) while deployed behind a GWLB.
Pros
- One firewall stack protects inbound, outbound, and east-west traffic for every attached application VPC
- GENEVE encapsulation preserves full packet visibility (including original source) end-to-end
- Horizontally scalable and fault-tolerant by design — AWS load-balances and health-checks the firewall stack automatically
Cons
- Forgetting to enable Appliance Mode on the TGW attachment breaks symmetric routing — a common, confusing failure mode ("traffic works one direction only")
- Route-table design across application VPCs, the security VPC, and TGW is intricate — several route tables must all agree or traffic silently misroutes
- Recommended to keep all subnets in the same AZ to avoid cross-zone data transfer charges — an easy cost trap otherwise
Exam trap
Forgetting to enable Appliance Mode on the TGW VPC attachment for the security VPC is the single most common GWLB misconfiguration — without it, request/response traffic isn't pinned to the same firewall instance and "traffic works one direction only."Self-check
1. Traffic through your GWLB-fronted firewall stack works outbound but return traffic never arrives. What's the most likely misconfiguration?
A: Appliance Mode isn't enabled on the TGW VPC attachment for the security VPC, so GWLB can't maintain per-flow symmetric routing to the same firewall instance.
2. What does GENEVE encapsulation preserve, and why does that matter for VM-Series behind a GWLB?
A: It keeps original packet headers and payload intact end-to-end, so the firewall retains full visibility (including original source) despite traffic being routed through GWLB endpoints.
Source: vm-series/deployment/public-cloud/set-up-the-vm-series-firewall-on-aws/vm-series-integration-with-gateway-load-balancer
VM-Series on Azure 42
Software Firewall (NGFW) course · VM-Series Firewall on Azure / Deployment and Network Integration
Learning objectives
- Compare deployment via Azure Solution Templates vs. custom image
- Explain Azure-specific integration points: health monitoring, Security Center, Application Gateway
VM-Series on Azure follows the same shape as AWS — same PAN-OS image, Azure-native licensing and networking glue — but plugs into Azure's own load-balancing, monitoring, and security ecosystem instead of AWS's.
Why
Azure customers expect firewall deployment and HA to integrate with Azure-native primitives (Azure Load Balancer health probes, Azure Security Center, ARM/Solution Templates) the same way AWS customers expect CloudFormation/GWLB integration — the underlying firewall logic is identical, but the cloud plumbing has to match the platform.How
Deployment options range from Azure Marketplace Solution Templates (fastest path, pre-wired networking) to a fully custom VM image for bespoke topologies, including Azure China variants for that sovereign cloud. Active/passive HA on Azure relies on Azure's own health-probe mechanism rather than dedicated HA links, since Azure networking doesn't support the same L2 adjacency assumptions as on-prem HA. Azure health monitoring lets Azure Load Balancer detect a failed firewall instance and stop sending it traffic. Azure Security Center integration surfaces VM-Series alerts inside Azure's native security dashboard instead of requiring a separate pane. The VM-Series + Azure Application Gateway template combines Azure's own L7 web app gateway with VM-Series inspection for web-facing workloads.
Pros
- Solution Templates get a working, correctly-wired deployment up fast for standard topologies
- Azure Security Center integration keeps firewall alerts inside a dashboard Azure admins already use
- Azure China variant extends the same model into that sovereign cloud
Cons
- Active/passive HA depends on Azure health-probe timing rather than dedicated HA heartbeat links — failover characteristics differ from on-prem HA
- Custom-image deployments trade the Solution Template's convenience for more manual networking setup
Exam trap
Azure active/passive HA relies on Azure's own health-probe mechanism, not dedicated HA heartbeat links like on-prem HA. Don't assume on-prem HA failover timing/behavior carries over unchanged to Azure.Self-check
1. Why doesn't VM-Series on Azure use the same dedicated HA links as on-prem PAN-OS HA?
A: Azure networking doesn't support the same L2 adjacency assumptions as on-prem HA, so active/passive HA instead relies on Azure's own health-probe mechanism to detect failure.
2. When would you choose a custom VM image over an Azure Solution Template for deployment?
A: For bespoke topologies that the pre-wired Solution Template networking doesn't fit — trading its convenience for more manual networking setup.
Source: vm-series/deployment/public-cloud/set-up-the-vm-series-firewall-on-azure (directory: azure-health-monitoring, azure-networking-and-vm-series, azure-security-center-integration, deploy-the-vm-series-and-azure-application-gateway-template, configure-activepassive-ha-for-vm-series-firewall-on-azure)
Azure Gateway Load Balancer 43
Software Firewall (NGFW) course · Azure Gateway Load Balancer Integration
Learning objectives
- Explain how Azure GWLB achieves the same transparent-insertion goal as AWS GWLB
Azure Gateway Load Balancer mirrors AWS GWLB's purpose — transparent, scalable insertion of a VM-Series firewall stack into traffic paths without redesigning application-side routing — using Azure's own load-balancer chaining model.
Why
The same problem GWLB solves on AWS applies on Azure: a firewall fleet needs to sit transparently in front of application traffic, scale independently, and stay fault-tolerant, without every application VNet needing custom routing logic per firewall instance.How
Azure Gateway Load Balancer chains to a standard Azure Load Balancer's frontend, inserting the VM-Series firewall stack transparently into the traffic path between the internet/internal clients and the backend application — conceptually the same "load balancer sends traffic to a scalable firewall fleet before it reaches its real destination" pattern as AWS GWLB, adapted to Azure's networking model. As with AWS, symmetric routing (both directions of a flow hitting the same firewall instance) is essential for connection-based inspection like decryption and threat prevention to work.
Pros
- Transparent insertion means no re-addressing of application VNets to add inspection
- Chains onto existing Azure Load Balancer frontends rather than requiring a parallel routing scheme
Cons
- Same symmetric-routing discipline required as AWS GWLB — get it wrong and stateful inspection (decryption, session tracking) breaks
- Azure and AWS GWLB are conceptually similar but not configuration-identical — expertise on one doesn't fully transfer without re-learning the platform specifics
Exam trap
Azure GWLB and AWS GWLB solve the same problem conceptually but aren't configuration-identical — don't assume hands-on AWS GWLB experience transfers directly to Azure without re-learning the platform-specific chaining setup.Self-check
1. What does it mean that Azure Gateway Load Balancer "chains" to a standard Azure Load Balancer frontend?
A: It inserts the VM-Series firewall stack transparently into the traffic path between clients and the backend application, without requiring a parallel routing scheme — traffic still enters via the existing Load Balancer frontend.
2. Why does symmetric routing matter equally for Azure GWLB as it does for AWS GWLB?
A: Connection-based inspection like decryption and threat prevention requires both directions of a flow to hit the same firewall instance, regardless of cloud platform.
Curriculum: Software Firewall (NGFW) course, "Azure Gateway Load Balancer Integration" lesson; cross-referenced against the AWS GWLB integration doc for the shared architecture pattern (Azure-specific configuration doc in the local mirror was a stub).
VM-Series on GCP 44
Software Firewall (NGFW) course · VM-Series Firewall on GCP / Deployment and Network Integration
Learning objectives
- Name the GCP-specific deployment models and integration points (autoscaling, GCP load balancer, NSI overlay)
VM-Series on GCP follows the same pattern again — image, license, deploy — with GCP's own autoscaling, load balancing, and network security integration APIs standing in for AWS/Azure's equivalents.
Why
GCP customers get the same App-ID/Content-ID policy engine, but need it to integrate with GCP's autoscaling groups and internal/external load balancers, and to meet GCP-specific platform requirements (minimum system requirements, secure boot support) for the images they run.How
Deployment models range from a standalone instance to a fully autoscaled firewall tier. Autoscaling on GCP adds/ removes VM-Series instances behind a GCP load balancer based on load, matching capacity to demand rather than provisioning for peak permanently. Configuring the GCP load balancer steers traffic into the firewall tier, similar in spirit to GWLB on AWS/Azure but using GCP's internal/external LB constructs. Securing a VPC with VM-Series on GCP extends the same inspection model to protect GCP-native VPC traffic. Secure boot support and documented minimum system requirements gate which GCP machine types/images are supported. Active/passive HA on GCP is supported but, like Azure, relies on GCP's own health-check/failover primitives rather than dedicated HA links — and unlike AWS/Azure, GCP HA setup has its own documented caveats worth checking per release.
Pros
- Autoscaling on GCP matches firewall capacity to real-time demand, same value proposition as AWS/Azure autoscaling
- Secure boot support hardens the instance itself against tampering, aligned with GCP's platform security model
Cons
- Minimum system requirements and secure-boot support constraints narrow which machine configurations are actually supported
- GCP active/passive HA design differs enough from AWS/Azure that HA runbooks don't port cleanly between clouds
Exam trap
GCP active/passive HA has its own documented caveats and differs enough from AWS/Azure that HA runbooks don't port cleanly between clouds — don't assume a procedure validated on one cloud applies unchanged to GCP.Self-check
1. What two GCP-specific factors gate which machine configurations are supported for VM-Series?
A: Documented minimum system requirements and secure boot support — both narrow which GCP machine types/images are actually supported.
2. How does GCP autoscaling for VM-Series achieve the same goal as AWS/Azure autoscaling?
A: It adds/removes VM-Series instances behind a GCP load balancer based on real-time load, matching capacity to demand instead of provisioning permanently for peak traffic.
Source: vm-series/deployment/public-cloud/set-up-the-vm-series-firewall-on-google-cloud-platform (directory: autoscaling-on-google-cloud-platform, configuring-gcp-load-balancer, deployment-models-for-vm-series-on-gcp, minimum-system-req-for-the-vm-series-firewall, secure-boot-support-for-vm-series-on-gcp, securing-vpc-with-vm-on-gcp, setup-active-passive-ha-on-gcp)
Google Cloud Intrusion Detection System 45
Software Firewall (NGFW) course · Google Cloud Intrusion Detection System
Learning objectives
- Explain how Cloud IDS packet mirroring differs from an inline VM-Series deployment
- Identify when a mirrored-traffic detection model is the right fit vs. inline inspection
Google Cloud IDS is a managed threat-detection service, built on Palo Alto Networks threat intelligence, that inspects a mirrored copy of GCP traffic rather than sitting inline — a fundamentally different insertion model from VM-Series' inline enforcement.
Why
Not every use case wants (or can tolerate) inline enforcement: some teams want detection/visibility into east-west and north-south threats without adding a hop that could affect latency or availability, especially during initial rollout or in environments where an inline change-control process is slow.How
Cloud IDS uses GCP's native Packet Mirroring to copy traffic from a VPC to the IDS service, which runs Palo Alto's threat-detection engine against the mirrored copy and raises findings in GCP's own security tooling (Security Command Center) — it detects and alerts, but because it inspects a copy, it cannot itself block traffic inline the way a VM-Series firewall in the traffic path can. It's positioned as a managed, GCP-native complement to an inline VM-Series deployment: Cloud IDS for broad, low-friction detection coverage; VM-Series where active prevention (blocking, not just alerting) is required.
Pros
- Zero traffic-path risk — mirrored inspection can't introduce latency or become an availability dependency
- Fast to enable broadly since it doesn't require re-routing traffic through an inline firewall
- Findings surface natively in GCP Security Command Center
Cons
- Detection only — it cannot block traffic itself, unlike an inline VM-Series deployment
- Being GCP-only, it doesn't give the cross-cloud consistency that VM-Series' AWS/Azure/GCP parity does
Exam trap
Cloud IDS inspects a mirrored copy of traffic — it can detect and alert but cannot block anything inline. Don't confuse it with an inline VM-Series deployment when a scenario calls for active prevention.Self-check
1. A scenario requires blocking malicious traffic in real time on GCP, not just alerting on it. Is Cloud IDS the right tool?
A: No — Cloud IDS only inspects a mirrored copy of traffic via Packet Mirroring and cannot block inline; an inline VM-Series deployment is required for active prevention.
2. What's the main operational advantage of Cloud IDS's mirrored-traffic model over inline inspection?
A: Zero traffic-path risk — since it inspects a copy, it can't introduce latency or become an availability dependency, making it fast to enable broadly during initial rollout.
Curriculum: Software Firewall (NGFW) course, "Google Cloud Intrusion Detection System" lesson. Not covered as a dedicated topic in the local NGFW/VM-Series docs mirror — summarized from Google Cloud IDS' published architecture (Palo Alto threat-detection engine on GCP Packet Mirroring).
VM-Series on NSX-T 46
Software Firewall (NGFW) course · VM-Series Firewall on NSX-T / Required Components / NSX-T Deployment
Learning objectives
- List the VMware + Palo Alto components required for VM-Series on NSX-T
- Compare the operations-centric and security-centric deployment workflows
VM-Series on VMware NSX-T brings the same NGFW inspection into a private-cloud/SDN environment, inserted via NSX-T's service-insertion framework rather than a public cloud's load balancer.
Why
Private-cloud/virtualized data centers built on NSX-T need the same App-ID-driven east-west and north-south protection as public cloud, but have to plug into VMware's own service-chaining and steering-rule model instead of a cloud provider's load balancer.How
Required components: vCenter/ESXi (compute virtualization), NSX-T Manager 3.0+ (registered with vCenter, required to deploy VM-Series onto ESXi hosts), Panorama 9.1+ with the Panorama plugin for VMware NSX 3.0+ (works with NSX-T Manager to deploy, license, and centrally administer the firewalls), and the VM-Series plugin 1.0.6+ on the firewalls themselves (BYOL license, VM-100/300/500/700 models, up to 64 vCPUs via Software NGFW credits). Deployment follows one of two workflows: the operations-centric workflow splits work between Panorama (plugin communication, template stacks/device groups, service definition, firewall launch) and NSX-T Manager (service chains, steering rules to direct traffic to the firewall), then returns to Panorama for security policy — suited to environments with frequent NSX-T steering-rule changes and admins who operate both consoles. A security-centric workflow instead lets a security team drive more of the process from Panorama with less direct NSX-T Manager involvement.
Pros
- Extends the same App-ID/Panorama policy model into private-cloud/SDN environments, not just public cloud
- Service-chain/steering-rule insertion means no manual re-cabling of ESXi hosts
- Two workflow options let you match the deployment process to who actually owns NSX-T vs. security policy day to day
Cons
- Requires specific, fairly tightly-coupled minimum versions across vCenter/NSX-T Manager/Panorama/plugins — a real compatibility-matrix exercise before deployment
- Operations-centric workflow requires admins with access to (and fluency in) both Panorama and NSX-T Manager, which isn't always the same team
- BYOL-only licensing on this platform — no PAYG marketplace shortcut like public cloud offers
Exam trap
vCenter/ESXi, NSX-T Manager, Panorama, the Panorama plugin for VMware NSX, and the VM-Series plugin all have specific tightly-coupled minimum versions — don't assume "latest version of everything" is automatically compatible.Self-check
1. List the required VMware + Palo Alto components to deploy VM-Series on NSX-T.
A: vCenter/ESXi, NSX-T Manager 3.0+, Panorama 9.1+ with the Panorama plugin for VMware NSX 3.0+, and the VM-Series plugin 1.0.6+ on the firewalls.
2. How does the security-centric workflow differ from the operations-centric workflow?
A: Operations-centric splits work between Panorama and NSX-T Manager and suits frequent steering-rule changes; security-centric lets a security team drive more of the process from Panorama with less direct NSX-T Manager involvement.
Source: vm-series/deployment/private-cloud/set-up-the-vm-series-firewall-on-nsx/components-of-the-vm-series-firewall-on-nsx-t; vm-series/deployment/private-cloud/set-up-the-vm-series-firewall-on-nsx/deploy-the-vm-series-firewall-on-nsx-t-east-west
Module Quiz
1. A cloud architect assumes AWS automatically inspects and blocks malicious traffic passing between two of the company's VPCs, and skips deploying any inline inspection. Under the shared-responsibility model, why is this assumption wrong?
Shared responsibility covers the infrastructure layer only — segmentation, inspection, and policy on top of it are the customer's job, which is exactly the gap a VM-Series hub design fills.
2. An engineer is choosing a VM-Series capacity model for a fleet that needs frequent vCPU and subscription resizing with zero downtime. Which two statements about the two available capacity models are correct? (Choose two.)
Flexible Software NGFW Credits apply deployment-profile changes without a reboot; the fixed VM-Series Model needs a new license and a reboot to resize.
3. A regional team needs to stand up VM-Series firewalls in AWS China. Which licensing path must they use?
AWS China requires BYOL only, obtained via a dedicated AWS China account — there is no marketplace PAYG shortcut there.
4. A design centralizes inbound, outbound, and east-west inspection for every application VPC into one security VPC reached via Transit Gateway. What is the primary architectural tradeoff of this hub-and-spoke pattern?
Centralizing inspection avoids per-VPC firewalls but concentrates risk: every spoke VPC's traffic now depends on the shared hub.
5. An engineer deploys VM-Series behind an AWS Gateway Load Balancer using a Transit Gateway-attached security VPC. Outbound traffic reaches the internet correctly, but return traffic never makes it back to the originating instance. What is the most likely misconfiguration?
Without Appliance Mode, GWLB cannot pin both directions of a flow to the same firewall instance, breaking stateful/symmetric routing — a classic "works outbound only" symptom.
6. Which encapsulation does AWS Gateway Load Balancer use with VM-Series to keep the original packet headers and payload intact end-to-end?
GWLB and VM-Series use GENEVE encapsulation, so the firewall retains full original-packet visibility, including the true source, through the load-balanced path.
7. Why does VM-Series active/passive HA on Azure rely on Azure health probes rather than the dedicated HA1/HA2 heartbeat links used on-prem?
Without on-prem-style L2 adjacency, Azure active/passive HA instead depends on Azure Load Balancer health probes to detect a failed instance — failover characteristics differ from on-prem HA as a result.
8. To transparently insert a VM-Series firewall stack into a traffic path on Azure, what does Azure Gateway Load Balancer chain to?
Azure GWLB chains onto an existing Azure Load Balancer frontend, avoiding a parallel routing scheme for the application VNet.
9. Which two factors specifically gate which GCP machine configurations are supported for VM-Series deployments? (Choose two.)
Minimum system requirements and secure boot support together determine which GCP machine types and images are actually supported for VM-Series.
10. A team validated their VM-Series active/passive HA failover runbook thoroughly on AWS and wants to apply the identical procedure on GCP without re-testing. What should they expect?
GCP relies on its own health-check/failover primitives with release-specific caveats, so HA procedures validated on one cloud shouldn't be assumed to carry over unchanged.
11. A security team wants broad threat-detection visibility across GCP VPC traffic during an initial rollout phase, with zero risk of adding latency or becoming an availability dependency. Which capability best fits this requirement first?
Cloud IDS inspects a mirrored copy of traffic, so it introduces zero traffic-path risk — ideal for fast, broad detection-only visibility before committing to inline enforcement.
12. A scenario requires actively blocking malicious traffic on GCP in real time, not just alerting on it. Is Google Cloud IDS the correct tool for this requirement?
Cloud IDS is detection-only via Packet Mirroring; an inline VM-Series deployment is required whenever active prevention (blocking) is in scope.
13. An engineer is scoping the components needed to deploy and centrally administer VM-Series on VMware NSX-T. Which combination of Panorama version and plugin is required?
VM-Series on NSX-T requires Panorama 9.1+ together with the Panorama plugin for VMware NSX 3.0+, in addition to NSX-T Manager 3.0+ and the VM-Series plugin 1.0.6+ — versions are tightly coupled.
14. A security architecture team is deciding between the operations-centric and security-centric NSX-T deployment workflows. Which situation favors the operations-centric workflow?
Operations-centric splits work between Panorama and NSX-T Manager, suiting teams that operate both consoles and change steering rules often; security-centric favors a mostly Panorama-driven process.