- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
08-30-2017 01:05 AM
We had problems with AD after installing content version 729 this morning. Users were authenticated, but the logon process (group policy, drive mapping) was painfully slow. After we reverted to version 727 everything was OK again. The strange thing is that I see no traffic to our AD controllers being stopped by the firewall.
Anybody else seen this? We're using two PA-5050 in HA (active/passive) running PAN-OS 7.1.10.
08-30-2017 11:57 AM
08-30-2017 12:05 PM
We also had AD authentication issues from web applications traversing the firewall. Reverting to 727 fixed the issue.
08-30-2017 12:09 PM - edited 08-30-2017 12:13 PM
@ajr0 wrote:
FYI on panorama 7.x.x and above I think this option is available. It may be available prior to that release but I cannot confirm,.
This features is described in (at least) 6.1 and 7.1 documentation:
"In rare instances, errors in content updates may be found. For this reason, you may want to delay installing new updates until they have been released for a certain number of hours. You can specify how long after a release to wait before performing a content update by entering the number of hours to wait in the Threshold (Hours) field."
08-30-2017 12:51 PM
Just so you know, the Threshold feature that is available on the firewalls is NOT available on the scheduled content update jobs that are pushed from Panorama. I checked all the way up to 8.0.4 and the threshold option is not available.
08-30-2017 01:19 PM
Three of your customers ;-).
Rolled back to 727...
08-30-2017 01:23 PM
Please review this article before deciding to implement a Threshold setting.
08-30-2017 01:28 PM
This update affected various applications here. Oracle, FTP etc.
Everything started working again after downgrading.
08-30-2017 02:08 PM
Was there any way to view this issue from the monitoring logs or any kind of debugging?
08-30-2017 02:17 PM
We saw logs in 'Data Filtering' relating to the application that broke for us - sawthat ms-ds-smbv2 was being flagged and even though it is set to alert only, traffic was broken. Looks as if the firewall is fragmenting a packet and this disrupts the connection and we get retransmits/resets immediately after on our captures of broken traffic.
08-30-2017 04:08 PM - edited 08-30-2017 04:08 PM
@Frederico said:
> Here we are facing a problem with a process in 100% (pan_task process), someone with the same issue?
>
> Only in PA-200 - pan_task process 100% after 729 update
The pan_task process should always be at or close to 100%, even when there's no traffic passing. You only see it on the 200 in the "show system resources" output because there is not a separate dataplane like on other platforms. You can view the same data on other systems by looking in the dp-monitor.log file if you wanted to confirm.
Depending on the platform, it's one of:
less dp-log dp-monitor.log
less dp0-log dp-monitor.log less s2dp0-log dp-monitor.log
08-30-2017 05:00 PM
This was also affected any new Cisco VPN home phone that connected to the concentrator but was unable to register. Once we reverted back to version 727 it started to work again.
08-31-2017 02:51 AM
@ejorgensen wrote:
@ajr0 wrote:
FYI on panorama 7.x.x and above I think this option is available. It may be available prior to that release but I cannot confirm,.
This features is described in (at least) 6.1 and 7.1 documentation:
"In rare instances, errors in content updates may be found. For this reason, you may want to delay installing new updates until they have been released for a certain number of hours. You can specify how long after a release to wait before performing a content update by entering the number of hours to wait in the Threshold (Hours) field."
For firewalls I see the option to delay but not for scheduled updates from Panorama. This is 7.1.6 :-
08-31-2017 05:45 AM
I take my last post back. I found an affected application with extremely slow performance, and I rolled back the Applications and Threats to 728 and volia, it works normally now. I have no idea why, as none of the traffic for the application should be crossing a firewall boundary. I would have done some packet captures if I wasn't busy with 10 other things. But at any rate count us in as another affected customer.
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!