TCP Port timeouts - Mapped Drive

[#1]

WAN environment. Remote XP pro clients map a drive back to a centralized IBM iSeries server share. Fortigate 200A at the remote locations route across dedicated WANs back to a centralized DC to Fortigate 310B. XP > 200A > WAN LINK > 310B > iSeries Certain clients scan documents that are copied to the mapped drive automatically by the application. The issue is that if a period of inactivity occurs and the client does not scan (1 hour or more), the scan will fail. I have done extensive testing and everything points to the fortigates. A tcp session timeout seems to be the culprit but I can' t figure out the correct port. I have bumped up the timeouts for ports 135, 137, 138, 139, 445, 23, and more. This error occurs at four different locations, each using fortigates. I have eliminated any power-save and auto-disconnect features on the XP machines with no luck. Double-clicking the mapped drive in My Computer will reset the connection and the scan will work. Any ideas?

[UkWizard]

I doubt this is a session timeout, sounds more like the VPN is dropping. Check the VPN status next time you get an issue. With the port timeout setting, you can change the global setting, which affects all ports, but wouldnt recommend this is a long term, but just to prove it you could try it. But i really doubt thats the issue, as this timeout is when an existing TCP SESSION goes inactive, which apps shouldn' t do with tcp anyway. and even if they did, they should just reconnect anyway. Sounds more like the vpn is going down and its taking a number of seconds to come back up again which is causing the timeout.

[#3]

Thanks for the reply but sorry this network has no VPN. Dedicated circuits, not public. We have actually had several issues with TCP port timeouts and this application. It is a healthcare management system that uses several interfaces and sub-apps that open tcp port sessions but are not continuously used and the ports go inactive. Such as the scanning. Raising the timeout to over 24 hours has fixed several of these issues. Unfortunately this has proved a little more difficult. Yesterday I downloaded a port monitoring tool and had a breakthrough. Testing revealed that multiple ports get opened during the scanning process. But once it has finished scanning, three ports remained in an open state. Prior to this I had ran the Fortigate sniffer and found tcp ports 137, 138, 139, 445, and 23 were opened along with several others that would change from test to test. What I saw yesterday with this tool was that port 445 remained open and ports 8473 and 8476 stayed opened as well. This is something the Fortiage sniffer would not tell me. I raised the timeout for ports 8473 and 8476 and now have eliminated the error. In the end, applications that communicate through a Fortigate and opens tcp ports but have periods of inactivity can have tcp session-ttl timeout issues.

[UkWizard]

You should of seen the open sessions anyway within the GUI, that would also have told you what ports and sessions were being kept open.