R80.30 broke FTP

[Darren_Fine]

Had a client that wanted to use the new URL filtering features of R80.30.

Upgraded them on Monday morning (yesterday morning early) they are a media house and they do alot of file transfers for their content to get printed and posted etc (yes I know it should be encrypted with ftps or scp rather but that is another discussion) and R80.30 seemed to break this entirely.

First after a couple of hours of troubleshooting I resorted to allowing any service/any port from the servers sending the ftp traffic - this seemed to quell the issue for a short time but they still had intermittent failures yesterday afternoon. Furthermore no changing of active/passive ftp types on the client side made any difference.

Today alot more was not working and the IT guys were getting alot of heat which was being passed down to us.

I tried to log a high ticket with TAC etc but after 2 hours of no traction and the any service /any port allow not being a viable workaround we have to revert to the R80.20 snapshots.

As soon as R80.20 snapshots reverted all the FTP's from all the servers worked instantly.

So not sure if anyone else out there has R80.30 running and have issues with FTP traffic - let me know .

(I did install R80.30 in our lab and try and recreate the problem in the live environment - but could not. The client is using ISP redundancy with Load Sharing - perhaps this is causing the issue but no way of knowing now .)

(Also the drop reasons were for the dynamic ports as if the firewall did not understand the FTP protocol or the ports it was dynamically assigning . or some cryptic fwpslglue_chain Reason: PSL Drop:  xxx yyy xxx yyy . That was not usual or searchable on the knowledgebase or in CheckMates.)

I am a bit sad that my first R80.30 in production was so short lived 😞

[TP_Master]

Hi Darren,
Did you notice any logs in Smartlog that could be related? Logs either from the firewall or any other software blade (IPS? Anti virus?)

[Aidan_Luby]

Hey Darren,

You might be experiencing the same issue we did when we went from R77.30 to R80.10. The issue we had was rules which allowed multiple FTP service types all of a sudden didn't work and we saw FTP being allowed but then random ports being blocked immediately after in the logs. 

What we found out is that you need to have a specific FTP service in your rule that matches what the application uses for your use case. What I've found is that usually ftp-pasv is the service to use for us, but sometimes ftp-port works as well.

The thing is it seems FTP starts with port 20/21 but then during transfers it needs to dynamically open up other ports. I believe what most FTP clients use nowadays is passive mode which means the firewall needs to listen to the client and server to see if requests are made to open new ports for the session and then if the firewall allows passive mode it will dynamically open those ports for you. This is why having multiple FTP services in a rule doesn't just allow any FTP, it tries to use the first service listed and if that doesn't work then it's already too late.

Try ftp-pasv as the only service in your rule and if not try another service like simply "ftp" or "ftp-port".

[Darren_Fine]

Hi Aidan,

Thanks for the reply.

I did have the same thoughts as you when I saw all the new shiny ftp service/ application options. I did try a few of them individually but did not seem to have any luck. (also had time contraints)

I also tested them here in our lab but they seem to work whichever I choose 🙂

Also the client uses a specific ftp application (not just filezilla or somethings simple - almost like a batch automation tool which is not very verbose with regards to what type of ftp traffic it is trying.)

The other strange thing is its working just fine on R80.20 . With the single ftp protocol selected as per the attached pic.

So if it worked in R80.20 thought it would work in R80.30.

Thanks

[Darren_Fine]

Hi Guys,

I wanted to update this issue because I wanted to explain what has happened subsequent to this event.

IT SEEMS THAT THIS HAD NOTHING TO DO WITH THE UPGRADE TO R80.30 AT ALL.

SO BIG APOLOGIES.

It seems that Murphy's law transpired and the Internet provider had a intermittent physical fibre issue that occured just as we were doing the upgrade to R80.30 😞   (I mean what is the odds of that)

Also since this customer is using ISP redundancy in load sharing mode this was very difficult to diagnose. Especially since these devices are merely for Internet facing services and other services like surfing and email was not effected - probably because it was sometimes sent down the working line - or it is more resilient and less "real time" than FTP.

So in short - I have redone the upgrade this week after a battle with the ISP and everything is running swimmingly.

Goes to show - most times its "not the firewall" hahahaha

Regards

[G_W_Albrecht]

This is a very good example of correlating one activity to a newly started issue "because issue came after we did that". There is a possibility that any change can be followed by an issue it has caused, but it may also well be that this is only a misconception.

Last time customer did report an issue after enabling Inspect with HTTPS Inspection - after some time we did find out that this issue only occurres with Secure XL on but had nothing to do with HTTPS Inspection 😉

[joecool]

I know the thread is old but we had a group of the ftp protocols in an allow FTP rule, every other FTP packet was being dropped with an error that said "Passive reply (227) received while working in Active mode", I followed your idea and moved ftp-pasv into it's own rule (right before the old FTP rule) and the rejects stopped happening. Oddly enough they were not having trouble using FTP and those passive replies were being rejected for long before the issue but for some reason it started breaking FTP a couple days ago.

Joe

[Mike_Lenormand_]

Thank you, it worked