Migration from Juniper to Palos

[Mack]

Hi all,

We're in the process of migrating from Juniper ScreenOS devices onto our new Palos and I have some questions about ALGs and service timeouts.

On our Junipers, there were a couple of ALGs that we had to turn off due to them mangling the application they were supposed to handle.  The most prevalent of this was the SQL ALG, which seemed to have a tendency to terminate SQL sessions prematurely on longer running queries.  Is there anyone who has migrated from ScreenOS to Palos that has experience with the ALG problem and can let me know if the Palos handle SQL better, or if I should create an Application override for it?

Secondly, we had a number of services for which we extended the timeouts, most notably SSH (because keepalives didn't seem to work and our admins didn't like to log in repeatedly) and LDAP (because idle connection pool sessions would be timed out by the firewall too soon).  Does anyone have experience with how the Palos handle these services/applications (especially the connection pools)?

Finally, it looks like I can make a custom app that has longer timeouts (but it is not possible for a service/port definition - why?).  On the Objects->Applications page, there is a clone button, but I can't seem to get it to work.  Any idea of how I could clone an application, for instance the SSH application and give it an extended timeout?

[HULK]

Hello Sir,

As per my understanding regarding SQL ALG:

Protocol Description:

Oracle SQL*Net is a network access protocol for Oracle databases. In operation a database client would connect to the Oracle server on the well known port of TCP/1521 or TCP/1525 for SQL*Net V1. The server would then send the client connection information for the actual data communication. The main reason for this behavior is that SQL*Net was developed at a time when there were a very wide range of network protocols in use, and it was designed to be independent of any particular transport. TOP/IP was only one of more then 8 options in the original SQL*Net specification.

ALG Behavior:

This is a very straight forward ALG. It will parse any replies from TCP/1521 and look for the string “(IP=a.b.c.d)(PORT=x)” in ASCII and then open a pinhole for the subsequent server connection. Nat can also be applied at this point to translate public to private IP addresses and vice versa.

ALG Timeout:

The control channel on TCP/1521 (1525) is not linked with the resulting data connection. While the SQL session inherits the time out from this connection, they are not linked and the control channel can time out without affecting the data channel.

Application overrides, will skip the layer 7 processing on PAN FW, hence PAN will not modify the payload and will not create any pinhole. It will simply route the packet.

Thanks

[HULK]

For SSH application, PAN FW is having default time out of 432000 seconds. ( for normal TCP/UDP the time out values are 3600/30)  You as a administrator is always having an option to play with this values on PAN firewall.

FYI..

Thanks

[_slv_]

Hi Mack

I migrated from ScreenOS to PAN OS over a year ago.

I haven't problems like You (SSH, SQL) but with VoIP sessions. I have case opened for more than a year! Finally I have a workaround with app overwrite, and I'm waiting for PAN 6.0.2 or 6.0.3 to upgarde. Now I'm on 5.0.9.

Version 6.x is free of such bug (for me is a bug, Screen OS worked fine without any problem). The problem is related to:

layer7 processing

: completed

So if You can, please start playing with PAN 6.0

Regards

SLawek

[HULK]

Hello Sir,

You can create a custom application with a longer timeout value and also define the port/protocol etc.

Here is an example of a custom-application to open TCP port 6000 and UDP 7000 to 8000:

You can only clone custom application on the PAN firewall and not for the default app signature..

FYI.

Hope this helps.

Thanks

[pulukas]

I had major issues with PanOS and sql connections.  There is a bug that dropped some packets coming through the PA for SQL streams.  This was finally addresses in PanOS 5.0.9.  Prior to this release we had to create an app override for all the sql connections passing the PA.

Voip is another issue that we still have open for Avaya connections.  The behvaior was similar, the packet captures show dropped packets through the PA.  The solution was the same, we created app overrides on the random high ports in udp and the control ports in tcp used by Avaya for the voip connections.

For the screenOS services with longer time outs on custom or non-standard ports, we also needed app override created to respect the longer timeouts.  The custom application definition was not enough without the app override.

[SabreAce33]

Do you have a Bug ID for that SQL issue?  Getting ready to drop 5.0.4 in our datacenter and there's a ton of SQL.

[ericgearhart]

SabreAce33 it's in the release notes for 5.0.9 I believe. Without realizing I had stumbled on a bug, I ran into similar issues with SQL when I had various threat profiles enabled on 4.1. Turning off all threat profiles got SQL to work.

[SabreAce33]

Yikes...thanks.  Guess it's time to look at 5.0.10.  Needed to do so anyway after the recent vulnerabilities.

[ericgearhart]

Don't look at 5.0.10, there are some huge HA bugs. Look at 5.0.11. That's what we're going to move to.

[SabreAce33]

Ah, ok, yeah...I actually discovered this bug a long while back.  It's #56003, and only applies to Data Filtering.  It caused major issues when we turned it on.

Thanks for the heads up on 5.0.10.  The QA on PAN-OS is driving me mad.  Slow your feature releases if you can't get it right before the X.0.10 release.

[ericgearhart]

SabreAce33 you are preaching to the choir here brother (sister?), I've been beating on the "improve QA and slow down on new features" drum for about two years now. The drum lining is falling apart at this point honestly.

[pulukas]

The QA versus feature release schedules is pretty much a universal problem in technology companies.  Sure I wish QA was better at preventing bug releases here, but I don't hold out any hope that feature releases will slow down to make sure the QA is complete.

That's why we still call it the bleeding edge.

I do agree that Palo Alto does seem to be worse than average at producing bugs in .0 releases.  And they should try to at least raise the QA bar to reach average.

[SabreAce33]

Looks like we're going to go with 5.0.9 and revisit in a month or two.  Can't run the HA risks with 5.0.10 and our SE says not to go to 5.0.11 yet.  Shame we can't make it to the security fixes present in 5.0.10 yet, but we'll have to live with it a while longer.  This is quite frustrating, as with our previous vendor (Juniper), we never really had to worry about game-breaking bugs in minor revisions.