Reason to upgrade to 4.0.2 ? ! ?

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.

Reason to upgrade to 4.0.2 ? ! ?

Not applicable

Just recently upgraded to 3.1.8

Like others here, wondering the REAL advantages of upgrading to 4.0.2

I don't want to run into the issues missed by QA in version 4.0.1 that I have seen here

  • management console not working via https
  • Qos issues
  • IPSEC Tunnels not working

would like everyone's feedback

Those who have upgraded for a specific feature set

Thos who haven't or have reverted back to 3.1X release due to issues

17 REPLIES 17

L3 Networker

We will stay at 3.1.8 until a stable version of 4.0 comes out. Based on our expiriences with 3.1.x, not till then 4.0.3 it makes sense to think about upgrades.

greetings

Manfred

New install here, but for us is the ability to use NAT in Panorama. So far only one I've notice not working is AD Group, for some reason it will not push policy in gateways.

L0 Member

I've upgraded ours to 4.0.2 and the only issue I've had so far is that when you do a commit or a similar function at the end of the ajax call rather then success often you get an AJAX error.   At which point if you close that window and click anywhere in the web GUI you get booted back to login.

If you login again you'll then see that you have two sessions open.  The old broken one and a new one.

I have also the same problem.

Using WIndows 7 with IE9.

Maybe a browser issue. Is IE9 supported to manage the paloalto?

Regards.

I was in Windows 7 w/ Firefox 4.0.

So the issue shows up in more then one browser.

That said I did several commits today and didn't get the error once.

L0 Member

After upgrading to 4.0.2 we experienced the following issues:

- AJAX error after Cimmit on WebGUI

- Commit would clear all Captive Portal sessions (user to IP mappings)

- Errors during Commit due to issues in URL profiles. It was comming up with: profiles -> url-filtering -> "URL PROFILE NAME HERE" -> alert ‘military’ is already in use

'milirary' URL profile was initially set to aler in that profile. After chainging alert to allow, it jumpped to another URL profile and complained about this category. After chaining this particular category to allow in each single URL profile it jumpped to another category'malware sites'. I gave up at this point and went back to 3.1.x

I am not sure if it is related as I am using 4.0.2. I installed Client Cerfification Profile, but revoked certificate was treated as valid and allowing to login. OSCP responder is working.

L4 Transporter

I'd be interested in any feedback on the major benefits in going from 3.x to 4.x as well.

Frankly I think Palo Alto have scored a bit of an own goal in bringing out a major OS release but doing a pretty poor job of actually telling their customers a) the benefits of upgrading and b) on what basis they should upgrade.

Let me clarify that a little.  Right now, I have a box running 3.1.8.  As far as I'm aware there is no document anywhere that says "If you have a PA-500 the current recommended release of PAN-OS is xxx" so it's left for me to "somehow" figure out which version of PAN-OS I should be running.  So far as 4.x, the feedback and vibe I get from here is very non-committal and to me it almost comes across as if 4.x is still some sort of beta and isn't actually recommended for production unless you really need something it offers that 3.x doesn't have.

If you are like me and jumped on the 50xx series you don't have a choice since there was no relase <4.0.x.  I would make sure you test the packet capture filters for your 4.0.x deployment if that is something that is of importance to you and your troubleshooting ability.  I know in the 50xx series it doesn't work and I am pretty sure support confirmed that it was a bug in the 40xx series as well.  For some reason getting a packet capture on a box seeing 500+ megs of throughput itsn't really viable when you can't filter it Smiley Wink

networkadmin wrote:

I'd be interested in any feedback on the major benefits in going from 3.x to 4.x as well.

Frankly I think Palo Alto have scored a bit of an own goal in bringing out a major OS release but doing a pretty poor job of actually telling their customers a) the benefits of upgrading and b) on what basis they should upgrade.

Let me clarify that a little.  Right now, I have a box running 3.1.8.  As far as I'm aware there is no document anywhere that says "If you have a PA-500 the current recommended release of PAN-OS is xxx" so it's left for me to "somehow" figure out which version of PAN-OS I should be running.  So far as 4.x, the feedback and vibe I get from here is very non-committal and to me it almost comes across as if 4.x is still some sort of beta and isn't actually recommended for production unless you really need something it offers that 3.x doesn't have.

I'm with you on this one - given what I've seen on the forums, I'm not upgrading to the 4.x series until I'm well convinced it's actually stable without introducing more bugs!

Unfortunately, this means I have to live with an annoying, but non critical bug with HA synchronisation on 3.1.x - occasionally (it can be once a day, or once every 3 weeks), the "Cert and Block" pages get out of synchronisaton between the active and passive partners in the HA cluster - PA's response to my bug report/trouble ticket "It's a known bug in 3.1.x which is not going to be fixed. Upgrade to the 4.x series".

Not impressed, but will NOT be upgrading until I see better comments from people here than I have so far!

+>- AJAX error after Cimmit on WebGUI

Had this as well and did a "commit force" on the CLI. After that the error was gone...

I've only saw this the first time I tried to click on commit button but after restart of my browser I have not seen it anymore. So far we have not encounter any major show stopper, we need NAT to work on Panorama and 4.x release is the only way to go from what we have seen.

price,

Thanks for that info. We were told to *not* deploy our 5050, because of the issues with 4.0.2. They wouldn't tell us *why*; PAN support & sales just told us not to.

They've recommended we keep our 20+ 4000 series boxes on 3.1 as well.

MJ

L3 Networker

I'd like to address some of the issues without addressing all of the individual issues.

There are two reasons to upgrade to a new major release:

1) New features that have been added.

2) Fixes that will not be back-ported to the previous release. Depending on the code changes, not all fixes can be back-ported.

For a description of the new features offered in a major release, please refer to the release notes and consult the Admin Guide for more detailed information.

The best place to find what is fixed in a maintenance release is in the release notes.

4.0.2 is proving to be a very stable release with no significant stability issues.

In regards to mthomasson’s specific questions on https to the management interface, QOS and IPSEC:

"HTTPS not working on the management interface after the upgrade”.  The workaround for this issue is to enable http on the Management interface before the upgrade.  Then after the upgrade attempt to log into the WebUI using HTTPS.  We do have a known issue with some certificates.  If after the upgrade the web UI does not come up, log into the PAN using HTTP.  Then, Go to Device Tab -> Certificates and open the certificate used for the web UI.  The Usage column will be labeled "Certificate for Secure Web GUI".  Deselect the check box for "Certificate for Secure Web GUI".  This will cause the PAN to use the default certificate included with the web UI.

I believe the QOS problem mthomasson is referring to might be from the following Knowledgepoint entry:

https://live.paloaltonetworks.com/message/5782

This entry mentions that Support told the user to turn off QOS until 4.0.2 was available.  This specific issue is caused by QOS profiles that include "any" in the source and destination zone fields, this is an issue that exists in 3.1.X and can also affect IPSEC.  Customers can work around this issue by specifiying the source and destination zones in the QOS policies instead of using "any".

I am verifying that both the certificate issue and the QOS policy issue are fixed in 4.0.3 and will confirm tomorrow.

  • 7034 Views
  • 17 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!