ftp (PASV) timeout after exactly 3600 s

[ede_pfau]

Using Fortigate-1000 3.00-b0572(MR5 Patch 4) I have to download a zipped 1.4 GB file regularily via ftp. After exactly 3.600s the download stops and is retried, over and over again. Problem occurred because this file has increased in size over time so that (with a slow server) a download takes about 1.5 hours. remedy: I have set the session timeout to 7.200 s: config system session-ttl set default 600 config port edit 21 set timeout 7200 next end end As this affects the idle-timeout only it doesn' t help at all. I see the expiry timer stay at " 7200" or " 7199" as long as the transfer goes on. After killing the download manually the session stays in the session table for 7.200s and is removed then. Basically, I need help with 1. is there a session timeout for active sessions? 2. how could I determine that the timeout occurs not on the firewall but on the ftp client, for instance by sniffing? Any hints greatly appreciated. - Wolfgang

[ede_pfau]

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.

[UkWizard]

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.

[rwpatterson]

Are you sure this is not a server issue??

[abelio]

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)

[ede_pfau]

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

[abelio]

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.

my bet: it' s not an issue related with your FortiGate. Look the arguments passed to wget in that script. ' wget' supports a timeout option, maybe you can find a switch " -T 3600 or --timeout=3600" in someplace within the script.

@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?

Not from session table, but sniffing your traffic with something like " diagnose sniffer packet any ' host <your ftp client IP> and host <NIH ftp IP> ' " Active FTP : command : client >1023 -> server 21 data : client >1023 <- server 20 Passive FTP : command : client >1023 -> server 21 data : client >1023 -> server >1023 (extracted from my favorite link ( http://www.slacksite.com/other/ftp.html))

[UkWizard]

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.

[ede_pfau]

(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

[ede_pfau]

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