About JD-SECD

Hello,   I've been trying to get past what seems to be a shortfall of the AWS ALB and PANOS alike. Please let me build you my current issue.   I am trying to set up a "loadbalance sandwich" such that a public AWS ALB will be load balancing between two PANW firewalls (different AZs), and then the firewall will pass traffic to an internal AWS ALB. The main sticking point is how can we keep the source IP address of the client/requester in the PANOS Traffic Logs.   I understand that the ALBs can send x-forward-for headers to the PANOS. The sad thing with this is that the only way to see the xff header in the PANOS is via URL logs. In that case you would then need the firewalls to have URL subscriptions. This seems very clunky and not very helpful to manually correlate URL Logs with Traffic Logs, not to mention extra cost for the subs.   Someone from the PANW PS team said that the source ip address can be saved/passed to the PANOS if we register the Public ALBs Targets as instances instead of registering targets via ip (see below for more helpful “gotchas”). In short this did not work – I can only seeing the private ip address of the Public ALB.   The only way I have found to maintain the public IP of the client/request in the PANOS’ traffic logs is to remove the Public ALB, use Route53 (AWS DNS service) to load balance (via a public hosted zone with the DNS A records to have Routing Policy either equal weights or primary/secondary failover) and healthcheck the firewalls. This leads to local dns caching shortfalls and TTL considerations.   Can anyone on this discussion board help with my issue? I have a case opened with AWS and PANW, I am hoping to get a quicker and more creative solution via this forum.   If anyone reads this post, many thanks for your time in reading – I hope it makes sense. Any feedback helps.      __________________________________________________________________________ start of: Registering PANW firewalls as instances of a ALB Target group   If you are going to configure the Public ALBs to target instances, you have to do a little more work. Since the ALB's only send traffic to the eth0 of the EC2 instance and most PANW firewalls will have eth0 as MGMT and eth1 as eth1/1 we have to swap interfaces. It took me a while to get my head around the concept, but eventually I got it to swap correctly.   To get past this swap/shortfall you MUST ensure both MGMT and eth1/1 are DHCP clients  then you have to swap interfaces via this article (https://www.paloaltonetworks.com/documentation/71/virtualization/virtualization/set-up-the-vm-series-firewall-in-aws/management-interface-mapping-for-use-with-amazon-elb).   I then wanted to get the MGMT and eth1/1 subnets back to “normal” (see below table for a little bit of clarification). I had to create an AWS AMI image, launch a new instance from that AMI image and on the configuration options page of the instance I had ensure I used the untrust-subnet as the primary and add the secondary NIC associated with the MGMT-subnet. *** NOTE when creating an AMI image this will reboot the firewall that the AWS AMI image is copying from. *** NOTE when you launch from an AMI image the admin account sometimes get corrupted so you have to create a new user and assign that user superuser permission from the cli of the newly created AMI firewall instance in order to get access to the GUI via elastic ip.   See below for an example of my subnet: Private IP association:   BEFORE SWAP on inbound-fw-a AFTER SWAP on inbound-fw-a AFTER AMI on inbound-fw-a-ami Mgmt 10.0.0.10 10.0.1.10 10.0.0.63 Untrust 10.0.1.10 10.0.0.10 10.0.1.63     Private IP association:   BEFORE SWAP on inbound-fw-b AFTER SWAP on inbound-fw-b AFTER AMI on inbound-fw-b-ami MGMT 10.0.10.10 10.0.20.10 10.0.10.154 Untrust 10.0.20.10 10.0.10.10 10.0.20.37     end of: Registering PANW firewalls as instances of a ALB Target group  ___________________________________________________________________________________   ... View more