PaloAlto VM Firewalls with AWS ELB/ALB

Hey friends – wanted to continue sharing my knowledge as I uncover how to use Palo Alto FW inside AWS. Here is some information about this Cloud Formation Template by Palo Alto.

Basically, the link above leads to a collection of scripts, CF templates that build configuration of Palo Alto Firewalls sitting behind an ELB, and in front of an ALB, like this:

All credit due to Palo Alto, the Cloud Formation Template works well. What is not so great however, is the technical documentation detailing the wizardry with which they pulled this off.  The tricky part about a design like this is that Firewalls are not a traditional LB target, meaning that they FORWARD traffic, rather than responding directly to the LoadBalancer itself like a server would. Further complicating matters, AWS ALB and ELB use DNS aliases. Keep-alives sourced from the external ELB pass through the Firewall – the firewall does not respond to keep-alives.

For this to work, Palo Alto has a NAT policy which basically takes external inbound LB traffic(untrust) and NATs the destination IP to the AWS ALB (internal load-balancer ) private IP(trust). That  last point is critical to understand if you ever hope to get something like this to work. Along with the Cloud Formation Template, Palo Alto basically has included 20+, (yes 20! ) python scripts that work in conjunction with CF and Lambda to automate this deployment. One / or more of those scripts figures out what the private IP is for the internal load-balancer and creates a NAT object for the internal load balancer in the FW configuration template prior to FW deployment and that is how they are getting around the fact that the ALB private IP is dynamic, built on-the-fly each time CF is run.  This little piece of info should be included in their documentation, presently, it is not.

Although I give serious, ( and I mean SERIOUS props),  to the Engineer who figured how to automate that piece with python and coded it all  – this ultimately is another ‘shoehorn’ of making something that was not built or designed to run in AWS, run in AWS.  The maintenance of the 20 + python scripts is not scalable – nor does it fit nicely into Terraform.

Palo Alto needs to work harder to integrate more deeply into the AWS API. Really, for a Cloud enabled Firewall, this should just be a CF template where you specify the ALB ( internal ) and the AWS API builds the initial FW policy based on resource attributes AWS has spun up internally.

This entry was posted in AWS, AWS Certified Solutions Architect, Palo Alto FW, Palo Alto Networks and tagged . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s