03-24-2011 01:38 AM
SQL & Telnet / ssh sessions are getting disconnected .
I have set the SQL Telnet / SSH time out values two 2160 Minutes , but stil this is getting disconnected.
I have enabled the ALG for SQL .
I have a Policy - ANY - ANY from Client to Server zone configured on Netscreen.
Following is the output of Getflow :
ns5200-> get flow
flow action flag: 28000034
flow GRE outbound tcp-mss is not set
flow GRE inbound tcp-mss is not set
flow change tcp mss option for all packets is not set
flow change tcp mss option for outbound vpn packets is not set
flow change tcp mss option for bi-directional vpn packets is not set
flow deny session disabled
TCP syn-proxy syn-cookie disabled
Log dropped packet enabled
Allow dns reply pkt without matched request : NO
Check TCP SYN bit before create session & refresh session only after tcp 3 way handshake : NO
Check TCP SYN bit before create session : YES
Check TCP SYN bit before create session for tunneled packets : YES
Enable the strict SYN check: NO
Use Hub-and-Spoke policies for Untrust MIP traffic that loops on same interface
Check unknown mac flooding : YES
Skip sequence number check in stateful inspection : NO
Drop embedded ICMP : NO
ICMP path mtu discovery : NO
ICMP time exceeded : YES
TCP RST invalidates session immediately : NO
Force packet fragment reassembly : NO
flow log info: 0.0.0.0/0->0.0.0.0/0,0
flow initial session timeout: 100 seconds
flow session cleanup time: 2 seconds
early ageout setting:
high watermark = 100 (1000064 sessions)
low watermark = 100 (1000064 sessions)
early ageout = 2
RST seq. chk OFF
MAC cache for management traffic: OFF
Fix tunnel outgoing interface: OFF
MCAST HW Ssss install: NO
session timeout on route change is not set
reverse route setting:
clear-text or first packet going into tunnel: prefer reverse route (default)
first packet from tunnel: always reverse route (default)
Close session when receive ICMP error packet: YES
Passing through only one ICMP error packet: NO
The SQL throws an error : " END of Communication Channel " in the client .
The Ping to the server does not show any drops !!!
The Telnet session to the server also gets disonnected .. ( mostly in session idle conditions)
Solved! Go to Solution.
03-24-2011 01:52 AM - edited 03-24-2011 01:56 AM
I am guessing but if you are using ScreenOS 6.2.0.r4 there is a problem with the ALG. As you may be aware the ALG (Application Layer Gateway) is a specialised algorithm to codify a particular application or protocol's behaviour.
Any protocol that has a well-known "listener" port and assigns data transfer to another (usually dynamically assigned) port requires an ALG in order to maintain statefulness. I think you can safely assume 1521 would be covered by this so the ALG extracts the dynamically assigned port information, opens a pinhole for the port and then closes the pinhole when the session is complete to prevent additional data leakage.
There is a KB article 491466 which confirms there is an issue with ALG and SQLv2. However. when you try to find the article it doesn't exist for public viewing.
A user in this forum said when he contacted Juniper the TACs response and only solution was: "there is a known issue with the 6.2 firmware. It is documented. it would be resolved in version 6.2.0r6. You should upgrade to OS 6.3 version or stay on the older version 6.1.0r3". The PR is confidential right now so they won’t provide any details.
I think this may be your issue. You should also read my reply to about SSG-550 SIP ALG ISSUE? which highlites other ALG related issues and provides some background. If you don't really need it I would turn it off.
03-24-2011 02:03 AM
HI Gavrilo ,
Thanks a lot for the post . Below is my software version,
My firmware version is : 6.0 2 (r 8 )
I have tried increasing my SQL service (1521 ) time out to " Never "" .
Is this firmware version ok .
Is there any known issues with this firmware ?
Another issue is Even my Telnet SSH sessions gets disconnected .
03-24-2011 02:13 AM
I have seen some weird issues with ports below 5000 when ALG is enabled. As I have said I don't think the chipset implements it correctly so if you can do without it I would disable it. Alternatively, reassign the service to a port above 5000. I pushed SQLNet up to 8010, stuck the listener on 8010 and all my problems went away.
03-24-2011 02:22 PM
You can change those timeouts all day long but until you put them into a policy they do not apply. So any any any is not using the time outs you have specified. You must have a policy with any any SQL for example.
03-26-2011 06:55 AM
Thanks to all..
The issue is resolved . I had added a policy for SQL & Telnet as mentioned by Jason.
It works perfectly .. special thanks to Jason..