About ebonjour

Just open all cases as critical. ... View more

Found out why I don't have a log forwarder for syslog, its not the right place for system messages!   In Device -> Log Settings, you should see at the top System.  You need to configure the system-"level" alerts to output to your syslog profile. ... View more

Just tested my setup and was able to see failed SSH attempts. What version of PAN-OS are you running?  I'm on 8.0, has been working since 7.0.   I don't have a log forwarder setup for my syslog profile at all and I only receieve System messages.  Try deleting your log forwarder.   ... View more

Had the same problem for months!   https://live.paloaltonetworks.com/t5/General-Topics/Problem-with-Panorama-commit/m-p/257333/highlight/true#M73005   Read the second to last post. ... View more

After 4 months I asked for esclation and after a couple days received a request to make a simple change. Panorama -> Setup -> Logging and Reporting Settings -> Buffered Log Fowarding from Device - enable it. It took 3 hours to impact one set of HA firewalls and 6 hours another another set.  Not enabling this requires the firewalls ACK every single log sent to Panorama which increases mgmt CPU usage and causes issues like I had.    Not sure if this setting is default in later releases, it should be.  I've had this panorama install since 5.1 and upgraded since then, issue starting happening after upgrading to 8.0.x. ... View more

@jeremy.larsen wrote: I'd be curious to see if you pulled a snapshot and reinstalled Panorama from scratch on the same version if this continued to happen.  Perhaps some residual garbage from the upgrade process?  I know that sounds painful. After 3 months of this I would try anything, but this does sound really painful.  The worst part of this is that diffs fail, these actually timeout after 4 minutes and 30 seconds, unlike commits that do not have a failure timer (kinda scary!). ... View more

@Bittereinder wrote: @ebonjour I was to quick answering you without reading that you have already tried rebooting the device. It worked at least for me... Regards. If you are having the same problem I am, then the commit queueing will occuring again.  Usually this takes about 5-10 minutes, but sometimes longer. ... View more

I have the same problem!  I'm running 8.0.15 and I've had this issue since upgrading to 8.0 from 7.1. I only have this issue on firewalls with HA.  I can get the commits to go through after restarting panorama. My TAC case is about 3 months old at this point.   Edit:  I never see the commit hit the firewalls, it stays in queue on the panorama. ... View more

So after 25 seconds does the second RADIUS server get queried? ... View more

I never even tried it! Seems just such a poor way to handle timeouts that I just decided it wasn't worth my time... and potentially the time of someone else that had to fix what I broke.  I just hope Palo Alto goes back and tries to address this issue at some point. ... View more

No, I opened a ticket but the "solutions" provided didn't fit in with my use case.   This is the answer provided to me   1. ==> There is a global timeout for global-protect process which is 25 seconds by default. It must be the same as or greater than the total time that any server profile allows for connection attempts. The total time in a server profile is the timeout value multiplied by the number of retries and the number of servers. For example, if a RADIUS server profile specifies a 3-second timeout, 3 retries, and 2 servers, the total time that the profile allows for connection attempts is 18 seconds (3 x 3 x 2).   This is just not acceptable when using two factor authentication. You can adjust via CLI with "set deviceconfig setting global-protect timeout  <range is 3-150 sec>", it is not in any GUI.   I also have no idea how this may work with multiple GP gateways... as the whole retry for that is insane.   A good idea I was provided is setting authentication protocol in your RADIUS server profile to either CHAP or PAP and not AUTO.  This will cut down on the overall time it takes to retry on a failed server as it will query each host for CHAP and PAP per RADIUS server retry count.   ... View more

I have done the test as you suggested, both RADIUS servers work as expected so it doesn't seem like an issue on my side.   Not sure what Palo Alto is using to determine if a RADIUS server is not working. ... View more

@BPry, I totally understand the point you are trying to make and maybe some people will not open tickets after finding open bugs in database.  I can say from using Cisco's bug search tool I have found many bugs that I have hit along the years, but everytime I then opened a ticket to confirm that I was in fact hitting that bug.  I do it for more of a CYA than trying to help the investigation.   With the current method of how Palo Alto is providing bug notices, I have to search through high 100s of notices if I am behind a couple releases.  Most of the time if this issue is minor I'd rather poke myself in the eye repeatedly than to open a case with Palo Alto (but thats another issue).  Maybe I should just pull out all of the bug fixes from the release notes in put them in my own database to search. ... View more

I don't think different documents are needed, just different subsections for device specific bugs. ... View more