FTD Bug - FTP transfer failing

After encountering a few bugs with how FTD handles FTP traffic I thought I woud do a little write up for engineers scratching their heads why FTP data traffic would not pass through cisco firewalls running FTD.

On ASA the modular policy framework (MPF) can be used to enable application layer gateway (ALG) functionality to handle certain (crappy) protocols like SIP and FTP. On FTD devices this inspection is automatically enabled on lina and snort but there are two pariticular bugs I have encountered recently which resulted in ftp inspection not working correctly.

CSCve45948

Using FTD 6.2.0.2 on an FPR4100 series firewall I encountered an issue with how snort handles ftp traffic. The control channel (tcp/21) worked fine but when we tried to transfer data using passive or active ftp, the data channel wasnt correctly associated with the ftp session. Due to this problem neither active- nor passive-ftp data traffic would work if the rule was created using an access-contol-policy.

Workaround: Create a pre-filter policy rule for ftp traffic. Since pre-filter policy rules are only processed by the layer 4 engine (lina) ftp should pass through the firewall now.

Solution: A fix should be provided in the near future. It will probably hit FTD version 6.2.2.

CSCve09249

In contrary to CSCve45948 this bug is related to lina (asa). If you try to establish an active-ftp data transfer from a source ip address that is being translated (e.g. internal client accesses ftp server on the internet) and you are using the extended keyword for your NAT rule, traffic on the ftp data channel would not pass through FTD running version 6.2.0.2.

Workaround: remove extended keyword from NAT rule

Solution: A fix should be provided in the near future. It will probably hit an upcoming FTD minor release (6.2.3)

I have encountered CSCve45948 before so I was aware of the defect and the workaround. When I enabled the pre-filter policy rule I was quite confused why active ftp traffic still didnt work. After some troubleshooting with TAC we found CSCve09249 and were able to solve the issue by removing the extended keyword from the NAT policy defined in FMC.