Migration from Juniper to Palos
cancel
Showing results for 
Search instead for 
Did you mean: 

Migration from Juniper to Palos

L2 Linker

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?

13 REPLIES 13

L7 Applicator

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







L7 Applicator

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..

SSH.JPG.jpg

Thanks

L4 Transporter

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

L7 Applicator

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:

custom-app.JPG.jpg

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

FYI.

Application-clone.JPG.jpg

Hope this helps.

Thanks

L7 Applicator

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.

Steve Puluka BSEET - IP Architect - DQE Communications (Metro Ethernet/ISP)
ACE PanOS 6; ACE PanOS 7; ASE 3.0; PSE 7.0 Foundations & Associate in Platform; Cyber Security; Data Center

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.

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.

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

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.

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!