ftp (PASV) timeout after exactly 3600 s

sorry, I forgot to mention the protection profile: doing AV scan up to 3 MB pass if oversize comforting client: 400 bytes every 10 s Yes I could try without AV scan. It' s just taking a long time to see if it has any effect. - W.

their is no active session timeout, so its either behaving oddly, or its actually in fact not downloading at all, so it connects sits idle for 5 mins and then times out. Do you actually see data coming down to the host retrieving the file? also try making a seperate rule for this one machine, without a protection profile, as a temporary test to see what whether its the protection profile causing it. I would guess though, its connecting and just sitting idle until it times out.

I have to download a zipped 1.4 GB file regularily via ftp. After exactly 3.600s

Are you sure your client is working in passive mode? If not, try repeating the above ttl-session settings but for ftp-data port (port 20)

Thanks for all the hints. Answers: Yes, data is coming in at 250 KB/s. This is obviously rate-limited by the server as thousands of others are making this download every month. Yesterday I set up the download in a different LAN (my office) behind a FG60 with the same firmware level. I was using the built-in Windows XP ftp client, and the download went through OK. The original download tool used is wget, which is embedded in an obfuscated perl script supplied by the database vendor. The data to be downloaded is a compressed database archive (*.gz). So that lead me to suspect that wget doesn' t " take" the client comforting packets and times out after 3.600s. I have not had the time to look into the source code yet. As to the server (ftp.wip.ncbi.nlm.nih.gov) they said 1000s of users have no problem at all and that it was our issue with the firewall. To be definite I will have to use wget at my office to see if the timeout happens there also. @abelio: > Are you sure your client is working in passive mode? How could I see that from the active session table? As I don' t have wget running here I cannot tell whether it issues a PASV command at the beginning. Hint? TIA, - Wolfgang

you might want to edit that post and remove that ftp address, i wouldn' t go posting it if its an government site... I have used wget quite a lot on linux boxes, and havent seen a problem before. if the data is coming down, i wouldnt expect it to timeout though. I would try it with a new rule for the ftp server (at the top of the rulebase) without IPS or any protection profile to see whether its the av causing it. do you not see anything in the logs? within the session list as well, you should see the timer counting down until it disconnects, it might be the initial connection is timing out, and the data stream is a seperate datastream back. If the file and URL is open to the public, then let us know the file and i could do a quick test from behind my unit and let you know.

(hard to say if you' re joking) - this site is from the NIH so nothing to hide here. For testing on my XP PC on my office I typed from the ' cmd' terminal: wget ftp://ftp.ncbi.nih.gov/blast/db/FASTA/nr.gz This is exactly the command the mascot script uses. The above command failed on my XP machine after 60 minutes just like mascot. BEWARE: this file is 1.4 GB big and takes about 1.5 hours to download (due to server limits). Funny enough, using the ftp client on a Win2000 PC worked flawlessly yesterday. The traffic was going through our FG60 with the exact same settings for ftp AV scanning. I will retry with no scanning at all. TIA, - Wolfgang

here' s a follow-up: 1. wget is using passive FTP. I' ve checked the session list according to Abelio. 2. When disabling AV scanning the download gets through. Alas, this does not determine the reason for the failure: the download rate rises from 250 KB/s to 457 KB/s and the download finished in just under 3.600 s... So it might be that the download succeeds because the timeout is not reached or because AV scanning does not interfere. 3. I wouldn' t have expected to see such a massive impact on the download rate. It shouldn' t have any influence at all as the file in question is bigger than the set limit (3 MB), accordingly the FG shouldn' t have scanned the file at all. But I can see the impact. My suspicion: the ftp proxy causes this, either because of internal timeout or failure of the client comforting feature. The 3.600 s timeout value does not seem to be adjustable. Next step will be to find a bigger download from the same server and to get past 3.600s download time. - Wolfgang

Hi, yes I' ve seen that option when I downloaded wget for Windows myself. Tried it with " -T 120" (seconds!) with no interruption, and without -T option in the original setting without timeout. BUT after 0:57 so cannot tell if it is avoiding the timeout yet. Will try again with a bigger file next week. Thanks. - Wolfgang