Palo Alto Networks VM-Series Firewall Deployment in AWS with Alkira Cloud Area Networking

When it comes to enterprise grade security, Palo Alto Networks arguably has been leading the race for some time compared to any of its competitors. They are considered to be the trusted partner whether enterprises are looking to deploy security appliances inside their data centers or as a virtual form factor in private and public cloud environments. Deployment models for on-prem environments have matured over time and are very cookie cutter for different use cases. However, as the enterprises look to deploy Palo Alto Networks Virtual Next-Generation Firewalls in the public clouds, they very quickly come to the realization that networking capabilities and limitations differ between different public cloud providers, occasionally complicating the deployment of the firewalls and other third party services. While none of these problems are due to the firewall vendor itself, it definitely affects the adoption rate, even though there is a complete feature parity between on-premise and cloud offerings. In this case a solution like Alkira can be super beneficial for enterprises and firewall vendors by making firewall deployments in the cloud simple, easy and on-demand.

Deploy Palo Alto Networks VM-series Firewalls Manually in AWS

Just to bring things into perspective and to build my argument, I will use the more popular and simpler cloud deployment model for deploying VM-Series in AWS. In this case, a customer has multiple ‘Spoke VPCs’ with a set of requirements for a) applications hosted inside spoke VPCs to securely communicate to the Internet, b) secure ingress access to the Internet facing applications hosted inside the spoke VPCs, and c) secure spoke to spoke VPC communication between applications hosted in spoke VPCs. Per the official Palo Alto Networks VM-Series Firewalls on AWS deployment guide, the aforementioned requirements can be met using AWS Transit Gateway (TGW) by following the steps below. There are, in fact, additional configuration details for each of the steps below, but for this blog I am just outlining the main ones.

1. Create Spoke VPCs
2. Create 3 Security VPCs, one Outbound VPC for egress traffic from spoke VPCs to Internet, one Inbound VPC for ingress traffic to Internet-facing applications inside spoke VPCs and one East-to-West VPC for spoke-to-spoke traffic
3. Deploy 3 pairs of the VM-Series Firewalls in the 3 Security VPCs for a total of 6 firewalls
4. Create two TGW route tables, spoke route table for Spoke VPCs and security route table for Security VPCs
5. Create an IGW for Outbound VPC
6. Create a load balancer for Inbound VPC
7. Attach Spoke VPCs to the TGW Spoke VPC route table
8. Create a TGW VPC attachment for Inbound VPC and associate it with the TGW security route table
9. Create a TGW VPN attachment for Outbound VPC and associate it with the TGW security routing table
10. Create a TGW VPN attachment for East-to-West VPC and associate it with a TGW security routing table
11. Propagate Spoke VPCs routes into the TGW security route table, so that the returning traffic from the firewalls can reach back to the Spoke VPCs
12. Propagate routes available through the firewall into the TGW spoke routing table (prevents spokes from directly communicating to each other without going through the firewall)

Steps 8-12 are related to route propagation and route association. They are used to control routing between TGW attachments. TGW attachments can be associated to only one TGW routing table, while routes from a TGW attachment can be propagated to more than one TGW route table. Route association to an attachment basically defines the route table where a route lookup will happen upon receiving the traffic from that particular attachment, whereas route propagation is used to install routes for different attachments into a particular route table.

Transit Gateway with route tables and VPC attachments for Security and Spoke VPCs

With this design, even though it’s possible to solve these fairly basic use cases, getting to this stage requires a deep understanding of AWS networking constructs. You will be struggling to implement this design unless you have the understanding of VPC route table, Internet Gateway (IGW), subnet association to route tables, TGW attachment and route tables, route table association and propagation and so on. This deployment becomes even more complex if there is a need to have multiple segments or security zones, or extend connectivity to multiple public cloud regions. Maintaining traffic symmetry with optimal utilization of firewall resources is also a huge challenge, especially if your firewalls are distributed across multiple public cloud regions. Ultimately, even though enterprises prefer to use Palo Alto Networks firewalls in AWS deployments exactly the way they are using them for on-premise deployment, they soon come to realize that they may have to compromise between complexity and functionality.

Now in comparison let’s take a look at such a deployment using Alkira solution.

Deploying Palo Alto Networks VM-Series Firewalls with Alkira is a simple three step process and it can be provisioned from the topology canvas inside Alkira’s Cloud Area Networking portal without compromising on the security architecture and functionality.

STEP 1 – Deploy Palo Alto VM-Series Firewalls inside Alkira Cloud Exchange Point (CXP)

VM-Series firewalls can be provisioned within the Alkira CXPs with or without Palo Alto Networks Panorama. In order to provision it, all you need is the license information. Alkira supports both BYOL (Bring Your Own License) and PAYG (Pay As You Go). If enterprises choose to manage the firewalls provisioned within the Alkira CXPs through Panorama, they will need to provide the Panorama server IP address, device group and template information.

Enterprises can also enable autoscale for the VM-Series. With autoscale, Alkira will proactively monitor traffic going through the firewalls and automatically bring up or bring down firewalls based on the load. This allows enterprises to optimize their firewall utilization and pay for resources only when they are needed.

Alkira will manage the full lifecycle of the firewall VMs, while enterprises can operate management of VM-Series using Panorama.

STEP 2 – Map Segments/Groups to the Palo Alto Networks VM-Series Firewall Zones

Segmentation and micro-segmentation is fundamental to Alkira solution and these can be seamlessly extended to the VM-Series firewall zones through the Alkira’s Cloud Area Networking portal. At the time of onboarding a cloud or an on-premise connector, administrators are required to assign a segment and a group to the connector. Segment is an isolated compartment from routing and policy standpoint, while group is used to apply common policy across a group of connectors within a given segment, also known as the micro-segmentation. When deploying VM-Series firewalls, network/security engineers can easily map the segment and the group to the firewall zone. Once provisioned, these zones will be automatically created within the firewall without you needing to manually create them. This provides more granularity and flexibility in terms of number of zones you can create on the firewall based on your use case. This type of deployment flexibility is only possible with Alkira and is not recommended with cloud-native deployments, as it becomes overly complex and challenging to operationalize.

To achieve a similar outcome with Alkira for the example explained above, enterprises just need to have a group defined for the Spoke VPCs (cloud connectors) and a group defined for the ‘Internet’ connectors, then map these groups to the ‘Intranet’ and ‘Internet’ zones on the firewall settings respectively. If there is a requirement to expand this to an on-premise environment, simply add an on-premise connector to the ‘Intranet’ group and that’s it! The same way you can expand this solution to other cloud regions by simply adding more Alkira CXPs with the VM-Series firewalls. You can further expand this solution to other public clouds as well by simply adding cloud connectors for the newly added clouds (e.g. Microsoft Azure vNets or GCP VPCs) and attaching them to the ‘Spoke VPC’ group, which will automatically make them become part of the ‘Intranet’ zone on the firewall.

Alkira CXP with Palo Alto Networks VM-Series Firewalls

STEP 3 – Define Alkira Policy to Steer Traffic to the Palo Alto Networks VM-Series Firewalls

Lastly, enterprises can steer traffic to the VM-Series firewalls using Alkira’s intent-based point-and-click policy framework. They can send all traffic or only selected traffic to the firewalls based on the 5-tuple match within a given segment. There are three actions administrators can take if there is a policy match, ‘Permit the traffic and send it to firewall’, ‘Permit the traffic and not send it to firewall’ or ‘Deny and drop the traffic’.

Conclusion

Alkira and Palo Alto Networks together unlock the true potential of the cloud and is a win-win solution for customers as they get to deploy an enterprise-grade security firewall in the cloud without compromising on any of the functionality, due to the limitations of the cloud-native constructs. In using Alkira Cloud Area Networking for their deployments, enterprises can achieve speed, simplicity, and elasticity enabling IT teams to more effectively and efficiently meet their business needs across the enterprise

For more details, please reach out to us and schedule a demo.