Onboarding Global HTTPS Load Balancer
Table of Contents
Expand all | Collapse all
-
- VM-Series Deployments
- VM-Series in High Availability
- IPv6 Support on Public Cloud
- Enable Jumbo Frames on the VM-Series Firewall
- Hypervisor Assigned MAC Addresses
- Custom PAN-OS Metrics Published for Monitoring
- Interface Used for Accessing External Services on the VM-Series Firewall
- PacketMMAP and DPDK Driver Support
- Enable NUMA Performance Optimization on the VM-Series
- Enable ZRAM on the VM-Series Firewall
-
- Licensing and Prerequisites for Virtual Systems Support on VM-Series
- System Requirements for Virtual Systems Support on VM-Series
- Enable Multiple Virtual Systems Support on VM-Series Firewall
- Enable Multiple Virtual Systems Support on VM-Series in Panorama Console
- Enable Multiple Virtual Systems Support Using Bootstrap Method
-
- VM-Series Firewall Licensing
- Create a Support Account
- Serial Number and CPU ID Format for the VM-Series Firewall
- Use Panorama-Based Software Firewall License Management
-
- Activate Credits
- Create a Deployment Profile
- Activate the Deployment Profile
- Manage a Deployment Profile
- Register the VM-Series Firewall (Software NGFW Credits)
- Provision Panorama
- Migrate Panorama to a Software NGFW License
- Transfer Credits
- Renew Your Software NGFW Credits
- Deactivate License (Software NGFW Credits)
- Delicense Ungracefully Terminated Firewalls
- Set the Number of Licensed vCPUs
- Customize Dataplane Cores
- Migrate a Firewall to a Flexible VM-Series License
-
- Generate Your OAuth Client Credentials
- Manage Deployment Profiles Using the Licensing API
- Create a Deployment Profile Using the Licensing API
- Update a Deployment Profile Using the Licensing API
- Get Serial Numbers Associated with an Authcode Using the API
- Deactivate a VM-Series Firewall Using the API
- What Happens When Licenses Expire?
-
- Supported Deployments on VMware vSphere Hypervisor (ESXi)
-
- Plan the Interfaces for the VM-Series for ESXi
- Provision the VM-Series Firewall on an ESXi Server
- Perform Initial Configuration on the VM-Series on ESXi
- Add Additional Disk Space to the VM-Series Firewall
- Use VMware Tools on the VM-Series Firewall on ESXi and vCloud Air
- Use vMotion to Move the VM-Series Firewall Between Hosts
- Use the VM-Series CLI to Swap the Management Interface on ESXi
- Configure Link Aggregation Control Protocol
-
-
- Supported Deployments of the VM-Series Firewall on VMware NSX-T (North-South)
- Components of the VM-Series Firewall on NSX-T (North-South)
-
- Install the Panorama Plugin for VMware NSX
- Enable Communication Between NSX-T Manager and Panorama
- Create Template Stacks and Device Groups on Panorama
- Configure the Service Definition on Panorama
- Deploy the VM-Series Firewall
- Direct Traffic to the VM-Series Firewall
- Apply Security Policy to the VM-Series Firewall on NSX-T
- Use vMotion to Move the VM-Series Firewall Between Hosts
- Extend Security Policy from NSX-V to NSX-T
-
- Components of the VM-Series Firewall on NSX-T (East-West)
- VM-Series Firewall on NSX-T (East-West) Integration
- Supported Deployments of the VM-Series Firewall on VMware NSX-T (East-West)
-
- Install the Panorama Plugin for VMware NSX
- Enable Communication Between NSX-T Manager and Panorama
- Create Template Stacks and Device Groups on Panorama
- Configure the Service Definition on Panorama
- Launch the VM-Series Firewall on NSX-T (East-West)
- Add a Service Chain
- Direct Traffic to the VM-Series Firewall
- Apply Security Policies to the VM-Series Firewall on NSX-T (East-West)
- Use vMotion to Move the VM-Series Firewall Between Hosts
-
- Install the Panorama Plugin for VMware NSX
- Enable Communication Between NSX-T Manager and Panorama
- Create Template Stacks and Device Groups on Panorama
- Configure the Service Definition on Panorama
- Launch the VM-Series Firewall on NSX-T (East-West)
- Create Dynamic Address Groups
- Create Dynamic Address Group Membership Criteria
- Generate Steering Policy
- Generate Steering Rules
- Delete a Service Definition from Panorama
- Migrate from VM-Series on NSX-T Operation to Security Centric Deployment
- Extend Security Policy from NSX-V to NSX-T
- Use In-Place Migration to Move Your VM-Series from NSX-V to NSX-T
-
-
- Deployments Supported on AWS
-
- Planning Worksheet for the VM-Series in the AWS VPC
- Launch the VM-Series Firewall on AWS
- Launch the VM-Series Firewall on AWS Outpost
- Create a Custom Amazon Machine Image (AMI)
- Encrypt EBS Volume for the VM-Series Firewall on AWS
- Use the VM-Series Firewall CLI to Swap the Management Interface
- Enable CloudWatch Monitoring on the VM-Series Firewall
- VM-Series Firewall Startup and Health Logs on AWS
- Use AWS Secrets Manager to Store VM-Series Certificates
- Use Case: Secure the EC2 Instances in the AWS Cloud
- Use Case: Use Dynamic Address Groups to Secure New EC2 Instances within the VPC
-
- Intelligent Traffic Offload
- Software Cut-through Based Offload
-
- Deployments Supported on Azure
- Deploy the VM-Series Firewall from the Azure Marketplace (Solution Template)
- Deploy the VM-Series Firewall from the Azure China Marketplace (Solution Template)
- Deploy the VM-Series with the Azure Gateway Load Balancer
- Create a Custom VM-Series Image for Azure
- Deploy the VM-Series Firewall on Azure Stack
- Deploy the VM-Series Firewall on Azure Stack HCI
- Enable Azure Application Insights on the VM-Series Firewall
- Set up Active/Passive HA on Azure
- Use Azure Key Vault to Store VM-Series Certificates
- Use the ARM Template to Deploy the VM-Series Firewall
-
- About the VM-Series Firewall on Google Cloud Platform
- Supported Deployments on Google Cloud Platform
- Create a Custom VM-Series Firewall Image for Google Cloud Platform
- Prepare to Set Up VM-Series Firewalls on Google Public Cloud
-
- Deploy the VM-Series Firewall from Google Cloud Platform Marketplace
- Management Interface Swap for Google Cloud Platform Load Balancing
- Use the VM-Series Firewall CLI to Swap the Management Interface
- Enable Google Stackdriver Monitoring on the VM Series Firewall
- Enable VM Monitoring to Track VM Changes on Google Cloud Platform (GCP)
- Use Dynamic Address Groups to Secure Instances Within the VPC
- Use Custom Templates or the gcloud CLI to Deploy the VM-Series Firewall
- Enable Session Resiliency on VM-Series for GCP
-
- Prepare Your ACI Environment for Integration
-
-
- Create a Virtual Router and Security Zone
- Configure the Network Interfaces
- Configure a Static Default Route
- Create Address Objects for the EPGs
- Create Security Policy Rules
- Create a VLAN Pool and Domain
- Configure an Interface Policy for LLDP and LACP for East-West Traffic
- Establish the Connection Between the Firewall and ACI Fabric
- Create a VRF and Bridge Domain
- Create an L4-L7 Device
- Create a Policy-Based Redirect
- Create and Apply a Service Graph Template
-
- Create a VLAN Pool and External Routed Domain
- Configure an Interface Policy for LLDP and LACP for North-South Traffic
- Create an External Routed Network
- Configure Subnets to Advertise to the External Firewall
- Create an Outbound Contract
- Create an Inbound Web Contract
- Apply Outbound and Inbound Contracts to the EPGs
- Create a Virtual Router and Security Zone for North-South Traffic
- Configure the Network Interfaces
- Configure Route Redistribution and OSPF
- Configure NAT for External Connections
-
-
- Choose a Bootstrap Method
- VM-Series Firewall Bootstrap Workflow
- Bootstrap Package
- Bootstrap Configuration Files
- Generate the VM Auth Key on Panorama
- Create the bootstrap.xml File
- Prepare the Licenses for Bootstrapping
- Prepare the Bootstrap Package
- Bootstrap the VM-Series Firewall on AWS
- Bootstrap the VM-Series Firewall on Azure
- Bootstrap the VM-Series Firewall on Azure Stack HCI
- Bootstrap the VM-Series Firewall on Google Cloud Platform
- Verify Bootstrap Completion
- Bootstrap Errors
Onboarding Global HTTPS Load Balancer
The Global HTTP(s) Load Balancer distributes traffic from the internet to the
VM-Series firewall. Internal applications can be onboarded by creating port mappings
between the backend service and VM-Series NAT policies. Here, we will onboard two
separate HTTP applications using port mappings.
Before you begin, you need the following:
- The IPs of the backend applications (i.e. app1: 10.1.0.10, app2: 10.2.0.10).
- A unique port number to map each application (i.e. app1:TCP/1000, app2:TCP/2000).
- If you do not have an environment, use this Terraform plan to build a test bed environment.
Following are the steps to onboard the global HTTPS load balancer:
- Log in to your GPS console and create a health check for app1 and app2.
- Create a Global HTTPS Load Balancer.
- Create 2 frontend addresses on port TCP/80. Each frontend will map to a backend application.
- Create a backend service for each application. Select the corresponding names port and health check for each application.This is an example:gcloud compute instance-groups set-named-ports vmseries \ --region=us-central1 \ --named-ports=app1:1000,app2:2000 gcloud compute backend-services create app1 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --port-name=app1 \ --health-checks=app1 \ --connection-draining-timeout=300 \ --global gcloud compute backend-services add-backend app1 \ --instance-group=vmseries \ --instance-group-region=us-central1 \ --balancing-mode=RATE \ --max-rate-per-instance=10000 \ --global gcloud compute backend-services create app2 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTP \ --port-name=app2 \ --health-checks=app2 \ --connection-draining-timeout=300 \ --global gcloud compute backend-services add-backend app2 \ --instance-group=vmseries \ --instance-group-region=us-central1 \ --balancing-mode=RATE \ --max-rate-per-instance=10000 \ --global gcloud compute url-maps create global-https-lb \ --default-service app1 \ --global gcloud compute target-http-proxies create global-https-lb-target-proxy \ --url-map=global-https-lb \ --global-url-map \ --global gcloud compute forwarding-rules create app1 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --target-http-proxy=global-https-lb-target-proxy \ --ports=80 \ --global gcloud compute forwarding-rules create app2 \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --target-http-proxy=global-https-lb-target-proxy \ --ports=80 \ --globalConfigure the routing rules. Set the frontend address as the host to direct traffic to each backend.On your VM-Series firewall web interface, create 2 NAT policies to map the named port to the correct destination.Automation Example:Here is a Terraform example that onboards a new backend service to an existing HTTP(s) load balancer. The PAN-OS Terraform provider creates a service object and NAT policy for the new service:# Assign named port to instance group resource "google_compute_instance_group_named_port" "main" { group = var.instance_group zone = “us-central1-a” name = "app2" port = "2000" } # Create health check resource "google_compute_health_check" "main" { name = "app2" tcp_health_check { port = "2000" } } # Create backend service resource "google_compute_backend_service" "main" { name = "app2" port_name = "app2" load_balancing_scheme = "EXTERNAL_MANAGED" health_checks = [google_compute_health_check.main.self_link] backend { balancing_mode = "RATE" capacity_scaler = 1 group = var.instance_group max_rate_per_instance = "10000" } } # Create forwarding rule resource "google_compute_global_forwarding_rule" "main" { name = "app2" load_balancing_scheme = "EXTERNAL_MANAGED" port_range = "80" target = var.global_lb_self_link } # Create VM-Series service object resource "panos_service_object" "main" { name = "app2" vsys = "vsys1" protocol = "tcp" destination_port = "2000" } # Create VM-Series NAT policy resource "panos_nat_rule_group" "main" { provider = panos position_keyword = "bottom" rule { name = "app2" original_packet { source_zones = ["untrust"] destination_zone = "untrust" destination_interface = "ethernet1/1" service = panos_service_object.main.name source_addresses = ["any"] destination_addresses = ["any"] } translated_packet { source { dynamic_ip_and_port { interface_address { interface = "ethernet1/2" } } } destination { dynamic_translation { address = "<ip-address>" } } } } }