Lost SQL Server sessions

[#1]

Hi everyone I recently installed a a number of Fortigate 200' s. Currently they are configured with a scan/nids profile only. There are _no_ traffic limiting policies in place - all ports and all directions are configured with a any/all/accept policy. The firewalls carry very low traffic volumes; we have an average of 3-5 Mbit/s load. Since the firewalls were installed, we have started experiencing problems with database (SQL server) connections and session timeouts. I' m not too concerned about the session timeouts, we have made some adjustments where necessary and I believe the rest can be addresses by ' firewall-aware' programming. However, there is one issue that we cannot find an explanation or solution for. The following error started appearing randomly and fairly frequently after the firewalls were installed: [DBNETLIB][ConnectionOpen(Connect()).]SQL Server does not exist or access denied Any ideas? You assistance will be much appreciated.

[#2]

hi, To solve this problem, you should increase session_timeout for SQL connections. Try these: config system session_ttl config port edit 1433 set timeout 3600 next end end where, 1433 is the sql port value and 3600 is the session time in second. umit.

[#3]

hi umit, Thanks for your input, but this we have already done and it did not help. It seems like the session does not time out, but something else breaks and generates the error I mentioned. We have found references to other users experiencing this sort of problem on Oracle after installing a Fortigate, but nothing for SQL Server. thx Deon

[#4]

Deon, I don' t have a solution for this issue, but I think I know what is going on in that Fortigate 200 box of yours. I am currently trying to convince Fortinet R&D about a bug related to the way Fortigate handles TCP half close connections (FIN_WAIT2 state). Your description of this issue looks rather familiar to what I am experiencing with raw LPR and RSH connections: Most connections work fine but it occurs at random that some connections seem to be time-out, although the session_ttl was set to a couple of hours and filtering is obviously not causing the problem. Below my findings, hope it makes any sense to you. I am convinced that Fortinet has implemented the 2*MSL WAIT for TCP connection termination during the half close (FIN_WAIT2 state), instead of after the full close (TIME_WAIT2 state) as defined in RFC793. What this means is that a time-out is set during the the half close and if the remote party does not fully close the connection within the time-out set by the Fortigate, the session expires. According to the TCP specification no time-out should be used during the half close state, but the unwanted implicit " indefinite" wait has caused many implementations to use a time-out value here anyway. It seems to me that the Fortigate firewall launches the 2*MSL wait during the half close. I have setup some tests and I have seen that my Fortigate(s) lower the active session_ttl when the connection state transitions to the half close state. On MR6 this was 120 seconds followed by an additional wait of 10 seconds. With MR7 and higher, this time-out value was lowered to 30 seconds, without the additional wait of 10 seconds. The latter is a very common 2*MSL implementation nowadays (RFC1323), however, the issue here is obviously that Fortinet either implemented a very low time-out during half close (FIN_WAIT2 state), which looks very much like a 2*MSL implementation to me or it launched the 2*MSL wait too early! My advise for now is to check what SQL transactions take longer than 30 seconds to complete and tune them, or downgrade to MR6 so your SQL transaction have more time to finish. Brgrds, Frank

[#5]

Frank, Thanks very much for the response. What you describe is a bit outside my level of expertise, but it makes perfect sense and fits my situation. I' m escalating this to Fortinet. If I get anywhere, I' ll let you know. Cheers Deon

[#6]

Deon, I was glad to see someone else experiencing similar problems, which will make my case much stronger now! I have escalated the issue some time ago and it is now at R&D; I will let you know too... GOOD LUCK! Brgrds, Frank

[#7]

Deon, Check the tcp-halfclose-timer in MR10. Good luck with your tweaking! Rgrds, Frank