Any issues with PANOS 4.0.5?

[bchan]

Has anyone ran into issues with PANOS 4.05?

My previous past experience with PANOS 4.0.x was not the greatest.

High CPU utilization, network latency, GUI issues, and logging issues were not

the greatest. The end result was tech support and rollback to PANOS 3.1.x.

[mjacobsen]

I believe the dataplane must be restarted after removing any profiles with Block IP actions in order to avoid the problem. If you have done that and it is still happening, be sure to mention that to support as it would indicate that the issue might be different than the one being addressed in 4.0.6.

Mike

[mhorne]

Indeed! I got the message last night just to do that right after it had restarted itself.  Already updated my case as well with that info.

[toddinva]

This may be a dumb question, but what do you mean by Block IP actions?

[mhorne]

I created a vulnerability protection policy for SSH bruteforce attacks and changed it fromt he default action of alert to block.

That is what was at issue in my case. Hope that helps.

[mhorne]

Ok issue at hand is the problem keeps resyncing across the data plan, you litterally have to make sure that you stop everything hitting the block counters.  Enter this on one of your systems 'show counter global | match blk' (no quotes) if you have negative numbers then call support asap!

This is what we did for a active passive 5020 cluster. once we got everything that was triggering the block counter disabled.

disable sync between the FW's passive then the active nodes, reset the passive dataplane, fail over taking a session hit to the passive node, then reset the data plan on the second FW. reenable the HA data sync on the active then the passive nodes.

Verify that the blk is not incrementing any more and hope that stability ensues again.

4.0.6 fixes this issue, then you should be able to enable the blocks again. two weeks is the estimated time from engineering.

BTW Gary! Awesome job getting figuring this out.

Thank and hope it helps

Mike

[toddinva]

I'm not currently in HA which this issue seems to be about.  As for the previous message, are they basically saying to stop blocking all threats until this gets fixed if you want to stay with 4.0.5?  Wow.

[costerbrink]

we are currently facing a problem in 4.0.5 with vpns with hide-nat in place.

all vpns which use hide-nated networks/proxy-id's on the palo-side are broken whereas the vpn's without hide-nat are still fine.

the regarding packets are present in drop-layer packet captures.

in 4.0.4 this does not happen.

anyone else running 4.0.5 with vpns using hidenat?

[friento]

I've finished deploying 4.05 and so far the only issue I have is the amount of time it takes to push policy from Panorama (remind me on why I agree to buy this piece again), it's not consistent sometimes it pushes fast sometimes it take as long as 10 mins!! Which is forever when you are trying to fix an issue.

[wayne_webner]

In addition to my previous comments,

SSL decryption (forward-proxy) has some real issues:

>> there is a bug in 4.0.5 which causes outbound ssl sessions to become very slow and inconsistent. I believe its to do with OCSP and CRL lookups from the PAN device ( note: this was not enabled on 3.1.x as far as i recall )

Keep this inmind if you do decryption.

Ps, inbound decryption does not appear to be an issue

[jroth]

We are a new install, single box, no HA.

We are running 4.0.5 and have seen occasional instances of high CPU, it normally maxes out at at 13%, it will spike to 60% and will then only selectively pass traffic. I say selectively because I will be able to ping our edge switch and router, but not telnet to them, we will not be able to connect to external sites, etc. We also have clients complaining of connected/throughput issues even when the CPU is not high.

I have support looking into it but they have yet to turn up anything. The odd thing is that it ran fine since last week, but then this all started on this wednesday evening. I did notice that our Application/Threat signatures updated to 270-1140 wednesday morning. Has anyone else seen an issue realted to this app/threat signature? We have not changed anything else on the system.....

[wittejj]

I think Panorama is useful and I like using it, but it took me some time to adjust my perception of things so I understood what's going on.  The things that gave me the biggest difficulty with Panorama were the following:

1) What exactly shared objects are and how  they relate to the devices.  While it's listed in documentation, you don't really understand the shared resource thing until you actually deploy it and get hammered with error messages because you've defined duplicate named objects,services, etc on the devices.  That's when I discovered that for us the best way to handle it was to build ALL of the objects, services, etc on Panorama and push it to devices whether they needed them or not.

2) Realizing that all because Panorama is a centralized management platform, doesn't mean that everything is centralized by default.  For example, by building the policies on Panorama, I assumed that the logs would automatically be sent to Panorama.  NOPE.  You have to manually configure the rules  to be sent to Panorama.  In retrospect, it makes sense now, but in the beginning you just assume that a centralized management platform will do things  like that behind the scenes.

I do think that its greatest strength is being a centralized POLICY and LOGGING platform rather than a DEVICE MANAGEMENT platform.  Normally I NEVER switch to a device context in Panorama.  I usually just log into the devices directly to make the configuration changes.  But that still doesn't diminish my opinion of Panorama.

[JOEHIDALGO]

wittejj I'm over coming the same experience you speak of especially when it came to syslog, certificates, basically anything configured under Device Tab.

I shared the same pain.

[frank_henry]

Any word provided about 4.06?  4.1 is here, but no 4.06?

[friento]

4.06 was replaced by 4.07 because of some issue. So there is no 4.06.