PANOS is not able to see the public IP of a client in the Traffic Logs if using an AWS Public ALB

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

PANOS is not able to see the public IP of a client in the Traffic Logs if using an AWS Public ALB

L1 Bithead

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...).

 

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

 ___________________________________________________________________________________

 

1 accepted solution

Accepted Solutions

L1 Bithead

I've figured out my own solution. The solution is to use a Public Network Load Balancer. The NLB passes the source IP address to the downstream device (i.e., Palo Alto firewall).

 

You would still need to perform the interface swap outlined in the above subsection "Registering PANW firewalls as instances of a ALB Target group".

View solution in original post

1 REPLY 1

L1 Bithead

I've figured out my own solution. The solution is to use a Public Network Load Balancer. The NLB passes the source IP address to the downstream device (i.e., Palo Alto firewall).

 

You would still need to perform the interface swap outlined in the above subsection "Registering PANW firewalls as instances of a ALB Target group".

  • 1 accepted solution
  • 6022 Views
  • 1 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!