Outbound FTP and FTPs connections result in Client-RST and never allow connection

[bcote]

Hi ,

since we migrated to a Fortigate solution, I have been having some issues with connecting to outbound FTP servers. Currently, I have an issue with 2 government entities that require us to upload information to their systems. One uses plain FTP(in this day and age...) and the other FTPs... nothing to help me out. So far the same result happens when I use a client or server that resides behind my Fortigate and tries to do an outbound connection. I have tried different FTP clients(Filezilla, CoreFTP, and others) with no positive results. When I look through the forward Traffic, I see the outbound connections being detected by the Application control applied on my policy, states that it is allowed and that the action is Client-RST. I've read that the RST isn't necessarily indication that something went wrong, but so far it is the only thing I can look into. I have opened a ticket with support, but in the meantime, I was wondering if any of you had experienced this type of issue beforehand.

I can use the same configurations(on the client FTP) on my laptop which uses a different line to bypass the firewall and I am able to connect and get a directory listing. When I am through the Fortigate, I get "connection successful" but then it hangs at directory listing and after 20 seconds, timeouts and retries. I've tried removing all Security policies, removing outbound firewall NAT to simply use the ISP provided IP.. nothing seems to matter. 

I expect FTPs to be a bit of an issue simply due to the nature of it, but FTP on port 21.. why would this be an issue? 

Any input would be appreciated.

Ben

[oheigl]

Can you explain your solution to me further? You now created a VIP with destination IP set to your FTP client? Are you translating the IP address or only a specific port? Still baffled about the thing that the packets arrive on two different ports 

[bcote]

Yeah so basically, I created a VIP with an external public IP I own that translates to a specific computer and that port forwards a range from 2000-2100. This solution only works for 1 user though, but in my case, that single user/computer is what I need. Certainly not the desired scenario, but the only one that works. Then on the Filezilla client, I force it into active and apply that same port range. That allows my client to connect and download/upload normally. Keep in mind, a newer FTPs server would most likely not require this. It simply seems like the configuration of the FTPs I am trying to connect too does not support pin-hole ports? That's what the engineer thinks is the issue as normally, the traffic would be handled correctly through the session-helper.

As far as the packets leaving one interface and coming back another, although I did change the SD-wan algorithm to sessions so that this wouldn't happen, the FTPs connection still wouldn't work. We had made temporary routing policies to make sure the FTP traffic would be sent out and received on the same interface, and still it wouldn't work. Only the port forwarding approach was a success.

Let me know if you have any other questions.

Ben

[ghdcc]

Hello,

Did you actually get to the bottom if this and fix the problem?  We are having the same issue and don't seem to be getting anywhere.

thanks

Gary

[fcb]

I know this post is pretty old but I want to say that I had a similar issue and the FTPS was ultimately the issue. The session helpers cannot work due to the encryption that starts the FTPS conversation. Since it's encrypted the Fortigate does not know that it's FTP traffic so the session-helper cannot work... It's a nightmare but we ultimately forced active FTP and allowed SRC port 20 outbound back out from the FTP server and it worked. FTPS has got to be the biggest piece of crap ever. Hide my password but also hide the fact that I'm using FTP to the firewall.