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?
As per my understanding regarding SQL ALG:
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.
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.
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.
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
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..
Hope this helps.
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.
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!