: Launch the VM-Series Auto Scaling Template for AWS (v2.0)
Focus
Focus

Launch the VM-Series Auto Scaling Template for AWS (v2.0)

Table of Contents
End-of-Life (EoL)

Launch the VM-Series Auto Scaling Template for AWS (v2.0)

You can choose to deploy the firewall template in one VPC and the sample application template in the same VPC as the one in which you deployed the firewalls, or in a different VPC.
If the applications that you want to secure belong to a separate AWS account, the sample application template includes support for cross-account deployments. The solution supports a hub and spoke architecture whereby you can deploy the firewall template in one AWS account and use it as a hub to secure your applications (spokes) that belong to the same or to different AWS accounts.
All VM-Series firewall interfaces must be assigned an IPv4 address when deployed in a public cloud environment. IPv6 addresses are not supported.

Launch the VM-Series Firewall Template

This workflow tells you how to deploy the application load balancer and the VM-Series firewalls using the firewall template.
This firewall template includes an AWS NAT gateway that the firewalls use to initiate outbound requests for retrieving updates, connecting to Panorama, and publishing metrics to AWS CloudWatch. If you are not using Panorama to manage the firewalls, you must deploy a jump server (a bastion host with an EIP address) that attaches to the Untrust subnet within the VPC to enable SSH and/or HTTPS access to the VM-Series firewalls. This jump server is required because the management interface on the VM-Series firewalls has a private IP address only.
  1. Review the checklist for Plan the VM-Series Auto Scaling Template for AWS (v2.0).
    Make sure that you have completed the following tasks:
    • (For PAYG only) Reviewed and accepted the EULA for the PAYG bundle you plan to use.
    • (For BYOL only) Obtained the auth code. You need to enter this auth code in the /license folder of the bootstrap package.
    • Downloaded the files required to launch the VM-Series Auto Scaling template from the GitHub repository.
  2. Modify the init-cfg.txt file. You must add the device certificate auto-registration PIN to the init-cfg.txt file to automatically install a device certificate when your VM-Series firewall instance is deployed.
    vm-series-auto-registration-id=
    vm-series-auto-registration-pin-value=
    For more details read about the bootstrapping process and the init-cfg.txt file.
    If you’re using Panorama to manage the firewalls, complete the following tasks:
    1. Generate the VM Auth Key on Panorama. The firewalls must include a valid key in the connection request to Panorama. Set the lifetime for the key to 8760 hours (1 year).
    2. Open the init-cfg.txt file with a text editor, such as Notepad. Make sure that you do not alter the format as this causes a failure in deploying the VM-Series Auto Scaling template. Add the following information as name-value pairs:
      • IP addresses for the primary Panorama and optionally a secondary Panorama. Enter:
        panorama-server=
        panorama-server-2=
      • Specify the template stack name and the device group to which you want to assign the firewall. Enter:
        tplname=
        dgname=
      • VM auth key. Enter:
        vm-auth-key=
    3. Verify that you have not deleted the command for swapping the management interface (mgmt) and the dataplane interface (ethernet 1/1) on the VM-Series firewall on AWS. For example, the file must include name-value pairs as shown here:
      op-command-modes=mgmt-interface-swap
      vm-auth-key=755036225328715
      panorama-server=10.5.107.20
      panorama-server-2=10.5.107.21
      tplname=FINANCE_TG4
      dgname=finance_dg
    4. Save and close the file.
  3. (For BYOL only) Add the license auth code in the /license folder of the bootstrap package. For more information see Prepare the Bootstrap Package.
    1. Create a new .txt file with a text editor, such as Notepad.
    2. Add the authcode for your BYOL licenses to this file,then save the file with authcodes (no file extension) and upload it to the /license folder. The auth code must support the number of firewalls that may be required for your deployment. You must use an auth code bundle instead of individual auth codes so that the firewall can simultaneously fetch all license keys associated with a firewall. If you use individual auth codes instead of a bundle, the firewall retrieves only the license key for the first auth code included in the file.
  4. Change the default credentials for the VM-Series firewall administrator account defined in the bootstrap.xml file.
    Required for using the VM-Series Auto Scaling template in a production environment.
    The bootstrap.xml file in the GitHub repository is provided for testing and evaluation only. For a production deployment, you must Customize the Bootstrap.xml File (v2.0) prior to launch.
  5. Prepare the Amazon Simple Storage (S3) buckets for launching the VM-Series Auto Scaling template to a production environment.
    Make sure to create the S3 buckets in the same region in which you plan to deploy the template; the bootstrapping files hosted in the public S3 bucket are provided only to make it easier for you to evaluate the template.
    1. Create a new S3 bucket for the bootstrap files.
      1. Sign in to the AWS Management Console and open the S3 console.
      2. Click Create Bucket.
      3. Enter a Bucket Name and a Region, and click Create. The bucket must be at the S3 root level. If you nest the bucket, bootstrapping fails because you cannot specify a path to the location of the bootstrap files.
    2. Upload the bootstrap files to the S3 bucket. The bootstrap folders must be in the root folder of the S3 bucket.
      1. Click the name of bucket and then click Create folder.
      2. Create the following folder structure for bootstrapping.
      3. Click the link to open the config folder.
      4. Select ActionsUpload and Add Files, browse to select the init-cfg.txt file and bootstrap.xml file, and click Open.
      5. Click Start Upload to add the files to the config folder. The folder can contain only two files: init-cfg.txt and the bootstrap.xml.
      6. (For BYOL only) Click the link to open the license folder and upload the txt file with the auth code required for licensing the VM-Series firewalls.
    3. Upload the AWS Lambda code (panw-aws.zip file) to an S3 bucket. In this example, the AWS Lambda code is in the same S3 bucket as the bootstrap package.
      1. Click the bucket name.
      2. Click Add Files to select the panw-aws.zip file, click Open.
      3. Click Start Upload to add the zip file to the S3 bucket.
  6. Select the firewall template.
    If you need to Customize the Firewall Template Before Launch (v2.0), do that now and select the modified template.
    1. In the AWS Management Console, select CloudFormationCreate Stack.
    2. Select Upload a template to Amazon S3, choose the firewall-v2.0.template and click Open and Next.
    3. Specify the Stack name. The stack name allows you to uniquely identify all the resources that this template deploys.
  7. Configure the parameters for the VPC.
    1. Enter the parameters for the VPC Configuration as follows:
      1. Enter a VPCName.
      2. Select the two Availability Zones that your setup spans in Select two AZs.
  8. Select your preferences for the VM-Series firewalls.
    1. Look up the AMI ID for the VM-Series firewall and enter it. Make sure that the AMI ID matches the AWS region, PAN-OS version and the BYOL or PAYG licensing option you opted to use.
    2. Select the EC2 Key pair (from the drop-down) for launching the firewall. To log in to the firewalls, you must provide the name of this key pair and the private key associated with it.
    3. Restrict SSH access to the firewall’s management interface. Make sure to supply a CIDR block that corresponds to your dedicated management IP addresses or network. Do not make the allowed source network range larger than necessary and do not ever configure the allowed source as 0.0.0.0/0. Verify your IP address before configuring it on the template to make sure that you do not lock yourself out.
    4. Select Yes if you want to Enable Debug Log. Enabling the debug log generates more verbose logs that help with troubleshooting issues with the deployment. These logs are generated using the stack name and are saved in AWS CloudWatch.
    By default, the template uses CPU utilization as the scaling parameter for the VM-Series firewalls. Custom PAN-OS metrics are automatically published to the CloudWatch namespace that matches the stack name you specified earlier.
  9. Specify the name of the Amazon S3 bucket(s).
    You can use one S3 bucket for the bootstrap package and the zip file.
    1. Enter the name of the S3 bucket that contains the bootstrap package.
      If the bootstrap bucket is not set up properly or if you enter the bucket name incorrectly, the bootstrap process fails and you cannot be able to log in to the firewall. Health checks for the load balancers also fail.
    2. Enter the name of the S3 bucket that contains the panw-aws.zip file.
  10. Specify the keys for enabling API access to the firewall and Panorama.
    1. Enter the key that the firewall must use to authenticate API calls. The default key is based on the sample bootstrap.xml file and you should only use it for testing and evaluation. For a production deployment, you must create a separate PAN-OS login just for the API call and generate an associated key.
    2. Enter the API Key to allow AWS Lambda to make API calls to Panorama, if you are using Panorama for centralized management. For a production deployment, you should create a separate login just for the API call and generate an associated key.
    3. Copy and paste the license deactivation API key for your account. This key is required to successfully deactivate licenses on your firewalls when a scale-in event occurs. To get this key:
      1. Log in to the Customer Support Portal.
      2. Select AssetsAPI Key Management.
      3. Copy the API key.
  11. Enter the name for the application load balancer.
  12. (Optional) Apply tags to identify the resources associated with the VM-Series Auto Scaling template.
    Add a name-value pair to identify and categorize the resources in this stack.
  13. Review the template settings and launch the template.
    1. Select I acknowledge that this template might cause AWS CloudFormation to create IAM resources.
    2. Click Create to launch the template. The CREATE_IN_PROGRESS event displays.
    3. On successful deployment the status updates to CREATE_COMPLETE.
      Unless you customized the template, the VM-Series Auto Scaling template launches an ASG that includes one VM-Series firewall in each AZ, behind the application load balancer.
  14. Verify that the template has launched all required resources.
    1. On the AWS Management Console, select the stack name to view the Output for the list of resources.
    2. On the EC2 Dashboard, select Auto Scaling Groups. Verify that in each AZ, you have one ASG for the VM-Series firewalls with the one firewall in each ASG. The ASG name prefix includes the stack name.
    3. Log in to the VM-Series firewall. You must deploy a jump server or use Panorama to access the web interface on the firewall.
      • It can take up to 20 minutes for the firewalls to boot up and be available to handle traffic.
      • When you finish testing or a production deployment, the only way to ensure charges stop occurring is to completely delete the stack. Shutting down instances, or changing the ASG maximum to 0 is not sufficient.
  15. Save the following information. You need to provide these values as inputs when deploying the application template.
    • IP addresses of the NAT Gateway in each AZ. You need this IP address to restrict HTTP access to the web servers if you deploy the application in a different VPC. Specifying this IP address ensures that the firewall secures access your applications in a different VPC, and that nobody can bypass the firewall to directly access the web server. The sample application template (panw_aws_nlb_vpc-2.0.template) displays a template validation error if you do not enter the NAT Gateway IP addresses; you must enter the IP addresses as a comma-separated list.
    • Network Load Balancer SQS URL. An AWS Lambda function in the firewall stack monitors this queue so that it can learn about any network load balancers that you deploy, and create NAT policy rules (one per application) on the VM-Series firewalls that enable the firewalls to send traffic to the network load balancer IP address.

Launch the Application Template

The application template allows you to complete the sandwich topology and is provided so that you can evaluate the auto scaling solution. This application template deploys a network load balancer and a pair of web servers behind the auto scaling group of VM-Series firewalls, which you deployed using the firewall template. The web servers in this template have a public IP address for direct outbound access to retrieve software updates. Use this template to evaluate the solution, but build your own template to deploy to production. For a custom template, make sure to enable SQS Messaging Between the Application Template and Firewall Template.
When launching the application template, you must select the template based on whether you want to deploy the application template within the same VPC (panw_aws_nlb-2.0.template) in which you deployed the firewall template or in a separate VPC (panw_aws_nlb_vpc-2.0.template). For a separate VPC, the template provides supports for cross-account deployments. A cross-account deployment requires you to create an IAM role and enable permissions and trust relationship between the trusting AWS account and the trusted AWS account, and the account information is required as input when launching the template.
  1. (Required only for a cross-account deployment) Create the IAM role. Refer to AWS documentation.
    This role grants access to a user who belongs to a different AWS account. This user requires permissions to access the Simple Queue Service (SQS) resource in the firewall template. The firewall uses this queue to learn about each network load balancer that you deploy so that it can create NAT policy to send traffic to the web servers that are behind the network load balancer.
    • For Account ID, type the AWS account ID of the account into which you are deploying the application template. Specifying that account ID allows you to grant access to the resources in your account that hosts the firewall template resources.
    • Select Require external ID and enter a value that is a shared secret. Specifying an external ID allows the user to assume the role only if the request includes the correct value.
    • Choose Permissons to allow Amazon SQS Full Access.
  2. Use the Palo Alto Networks public S3 bucket or prepare your private (S3) bucket for launching the application template.
    1. Create a zip file with all the files in the GitHub repository, excluding the three .template files, named nlb.zip in the screenshot below.
    2. Upload the zip file to the S3 bucket you created earlier or to a new bucket.
    3. Copy the pan_nlb_lambda template into the same bucket to which you copied the nlb.zip file.
  3. Select the application template to launch.
    1. In the AWS Management Console, select CloudFormationCreate Stack.
    2. Select Upload a template to Amazon S3, to choose the panw_aws_nlb-2.0.template to deploy the resources that the template launches within the same VPC as the firewalls, or the panw_aws_nlb_vpc-2.0.template to deploy the resources in to a different VPC. Click Open and Next.
    3. Specify the Stack name. The stack name allows you to uniquely identify all the resources that are deployed using this template.
  4. Configure the parameters for the VPC and network load balancer.
    1. Select the two Availability Zones that your setup will span in Select list of AZ. If you are deploying within the same VPC make sure to select the same Availability Zones that you selected for the firewall template.
    2. Enter a CIDR Block for the VPC. The default CIDR is 192.168.0.0/16.
    3. (Only if you are using the panw_aws_nlb-2.0.template to deploy the applications within the same VPC)
      Select the VPC ID and the Subnet IDs associated with the trust subnet on the firewalls in each AZ. The network load balancer is attached to the trust subnet on the firewalls, to complete the load balancer sandwich topology.
    4. Enter a name for the network load balancer.
  5. Configure the parameters for AWS Lambda.
    1. Enter the S3 bucket name where nlb.zip and the pan_nlb_lambda.template is stored.
    2. Enter the name of the pan_nlb_lambda.template and the zip file name.
    3. Paste the SQS URL that you copied earlier.
    4. Enter a unique TableName. This table stores a mapping of the port and IP address for the applications associated with the network load balancer in your deployment.
      When you delete the application stack this table is deleted. Therefore, if multiple instances of the network load balancer write to the same table and the table is deleted, the NAT rules on the firewalls not function properly and the application traffic maybe be inaccurately forwarded to the wrong port/network load balancer.
  6. Modify the web server EC2 instance type to meet your deployment needs.
  7. Select the EC2 Key pair (from the drop-down) for launching the web servers. To log in to the web servers, you must provide the key pair name and the private key associated with it.
  8. (Only if you are using the panw_aws_nlb_vpc-2.0.template) Lock down access to the web servers.
    1. Restrict SSH From access to the web servers. Only the IP addresses you list here can log in to the web servers.
    2. Restrict HTTP access to the web servers. Enter the public IP addresses of the NAT gateway from the firewall template output, and make sure to separate IP addresses with commas. Entering the NAT gateway IP address allows you to ensure that all web traffic to the application servers are secured by the VM-Series firewalls.
  9. (Only if you are using the panw_aws_nlb_vpc-2.0.template) Configure the other parameters requires to launch the application template stack in a different VPC.
    1. Select SameAccount true if you are deploying this application template within the same AWS account as the firewall template, and leave the cross account role and external ID blank; select false for a cross-account deployment.
      For a cross-account deployment, enter the Amazon Resource Number (ARN) for the CrossAccountRole and ExternalId that you defined in (Required only for a cross-account deployment) Create the IAM role. Refer to AWS documentation.You can get the ARN from SupportSupport Center on the AWS Management Console.
    2. Enter the VPC Namein which you want to deploy the application template resources.
    3. Optional Change the NLBSubnetIPBlocks for the Management subnet for the network load balancer.
  10. Review the template settings and launch the template.
  11. Verify that the network load balancer is deployed and in a ready state.
  12. Get the DNS name for the application load balancer, and enter it into a web browser.
    For example: http://MVpublic-elb-123456789.us-east-2.elb.amazonaws.com/
    When the web page displays, you have successfully launched the auto scaling template.
  13. Verify that each firewall has a NAT policy rule to the IP address of each network load balancer.
    When you deploy the application template to launch another instance of a network load balancer and pair of web servers, the firewall learns about the port allocated for the next network load balancer instance and creates another NAT policy rule. So, if you deploy the application template three times, the firewall has three NAT policy rules for ports 81, 82, and 83.
  14. If you have launched the application template more than once, you need to Enable Traffic to the ELB Service.

Enable Traffic to the ELB Service (v2.0 and v2.1)

If you add a second or additional internal load balancers (ILBs) in your deployment, you must complete additional configuration so that the internal load balancer, the VM-Series firewalls auto scaling groups, and the web servers can report as healthy and traffic is load balanced across all your AWS resources.
In v2.0, the ILB can only be a network load balancer. In v2.1 the ILB can be an application load balancer or a network load balancer.
  1. On the AWS management console, verify the ports allocated for each network balancer on the DynamoDB table.
    When you launch a new internal load balancer, the application template must send an SQS message to the SQS URL you provided as input when you launched the template. The AWS Lambda function in the firewall template monitors the SQS and adds the port mapping to the DynamoDB table for the firewall template. Starting at port 81, the port allocated for every additional internal load balancer you deploy increments by 1. So, the second internal load balancer uses port 82, and the third port uses port 83.
    1. Select the DynamoDB service on the AWS management console.
    2. Select Tables and click the table that matches the stack name for your firewall template. For example, MV-CFT20-firewall-us-east-2.
      In the Items list, view the ports used by the internal load balancers that are publishing to the SQS associated with the firewall template.
  2. Create a target group. The internal load balancer sends requests to registered targets using the port and protocol that you specify for the servers in the target group.
    When you add a new target group, use the port information that you verified on the DynamoDB table.
  3. Edit the listener rules on the internal load balancer to route requests to the target web servers.
    1. On the AWS management console, select Load Balancers in the Load Balancing section, and select the internal load balancer that matches your stack name.
    2. Select View/edit rules to modify the rules for the listener.
    3. Select Insert rule and add a path-based route to forward traffic to the target group you defined above as follows:
  4. Attach the target group to both VM-Series firewalls auto scaling groups.
    1. Select Auto Scaling Groups in the Auto Scaling section and select an auto scaling group that matches the stack name.
    2. Select DetailsEditand select the new target group from the Target Groups drop-down.
  5. Log in to each web server that was deployed by the application template, create a new directory with the target group name and copy the index.html file into the directory. Until you set up the path to the index.html file, the health check for this web server reports as unhealthy.
    sudo su
    cd/var/www/html
    mkdir <target-groupname>
    cp index.html <target-groupname>
  6. Verify the health status of the web servers.
    Select Auto Scaling Groups, and use the application stack name to find the webserver auto scaling group to verify that the web servers are reporting healthy.