Dynamic updates schedule from Panorama

[Rajesh12]

I see PA have changed the behavior of dynamic updates push from Panorama to managed firewalls from PAN OS 7.x to 8.x. As per PA, in 7.x panorama will push the updates to managed devices. But from 8.x, managed device itself retrieve the updates from Panorama. Can someone please help to explain in brief on how firewall will come to know about the schedule time defined in Panorama and will initiate a connection to Panorama to retrieve updates?

[MP18]

As per my understanding when you configure Dynamic updates there is a field for schedule and there you define when PA can talk to Panorama to download and install dynamic updates.

Also In Panorama under device deployment you need have your firewall added there to get the updates from the Panorama.

[BPry]

@Rajesh12,

Essentially the process is the same as if you were allowing the firewall to pull updates through updates.paloaltonetworks.com, except they pull through your Panorama instance instead. Everything else stays exactly the same as far as how things were scheduled, and the download process utilizes the same process a standalone set of firewalls would that weren't pulling updates through your Panorama instance. 

Essentially the only change that happens is that the firewall is now going to pull the updates from Panorama, instead of Panorama pushing the updates out to the firewalls. 

[Rajesh12]

Thanks for your inputs @BPry  and @MP18. 

Yes, functionality remains same for most of the part. But I actually was looking for step by step process that will be taken place during the scheduled updates. As per the traffic logs analysis that I have done yesterday, below is my understanding.

Before PAN OS 8.0

1. Panorama initiates connection to managed firewall during the schedule time on port TCP 3978.

2. Panorama pushes the package to managed firewall by using same connection.

From PAN OS 8.0

1. Panorama initiates connection to managed firewall during the schedule time on port TCP 3978.

2. In response, managed firewall initiate new connection to panorama on port TCP 28433 to pull the updates (because I noticed logs where firewall initiate connection to Panorama to pull the updates instead of using earlier connection).

Please correct me if I'm missing anything.

Cheers!

[Rajesh12 · Accepted solution]

One of the support engineer just confirmed that my assumption is correct. 

For the PAN-OS version 8.x above I could see Panorama sending the link to all the firewalls(by POST) to retrieve the update file from Panorama on port 28443.(eg: 08:00:45.899 -0700 Deployment URL: &lt;url type=&quot;ipv4&quot; method=&quot;POST&quot;&gt;https://10.20.244.134:28443/dl.get</url>;).

Then the firewalls will retrieve the updates from panorama destination port as 28443.

[fjwcash]

One HUGE caveat to the new setup:  Palo Alto has gone back to the 80s and reproduced all the issues with FTP in their stupid/braindead updates protocol.  Namely, that they embed the IP of the Panorama server INSIDE the data payload of the IP packets, instead of using the "Panorama IP" set in the Device tab of the managed firewall.  Thus, if your Panorama server is behind a NAT, and your remote firewalls are configured to connect to Panorama via the public IP, these new "pushed pulls" will fail (the private IP of the Panorama server is passed through as part of the TCP payload).

Instead of fixing their braindead protocol, they added a new configuration setting: Panorama tab --> Setup --> Interfaces sub-tab --> Management.  In there, you have to manually enter the public/NAT IP for the Panorama server.

Virtually every other protocol released since the 90s has been NAT-aware due to all the issues with PASV/ACTV FTP shenanigans, but Palo Alto decided (in 2019) to released a broken protocol that can't work through NAT without special steps.

The more I use PanOS 8.1, the more I long for the days of 7.1.  It seems to be two steps forward, 1 step backward with ever minor release.  😞

[Rajesh12]

Agreed @fjwcash . I actually had the same issue now with Panorama sending its private IP in the POST message. Luckily my firewall had internal connection also. So for now I was just relying on service routes to solve this.

Any idea why they have changed this behavior?

Also if we update public IP of panorama in mgmt interface settings, will the POST message in payload will be updated with public IP? 

[fjwcash]

---

@Rajesh12 wrote:

Agreed @fjwcash . I actually had the same issue now with Panorama sending its private IP in the POST message. Luckily my firewall had internal connection also. So for now I was just relying on service routes to solve this.

Any idea why they have changed this behavior?

Also if we update public IP of panorama in mgmt interface settings, will the POST message in payload will be updated with public IP? 

---

No idea why they moved to using a scheduled push from Panorama to initiate a pull from the firewall, when the previous push from Panorama worked so well.  Seems backwards to me, but I don't work for Palo Alto.  They must have their reasons.  Why they have Panorama send it's management IP address in the payload data of the connection is beyond me, when they could just use the Panorama Server IP that's already set on the firewalls.  What's the point of setting it on the firewalls if you aren't going to use that for everything Panorama-related?

Yes, if you update the Public IP Address setting for the Panorama management interface, that is the IP address that will be used for the scheduled updates connections from the firewalls to Panorama.

[Rajesh12]

Thanks @fjwcash . In my case I have firewalls of which some use private IP of panorama and others use public IP of panorama. So If I configure public IP for mgmt interface of Panorama, does my firewalls which use private IP of panorama will also receive POST message with Public IP of Panorama?