Description

This article describes why an FTP packet is dropped by FTP ALG due to no CRLF at the end of an FTP header.

CRLF: Carrige Return(\r) / Line Feed(\n)

Symptoms

The following packet capture is one of the standard FTP control packets. The CRLF(\r\n) is seen at the end of the FTP header in the control packet.

In this case, FTP ALG forwarded this packet.


alt



However, another FTP application used LF(\n) instead of CRLF(\r\n), as seen in the following packet capture.

In this case, FTP ALG will drop this packet as a malformed FTP packet by default.

alt
 

Solution

FTP ALG checks the FTP format to see if the FTP control packet ends with CRLF.

SRX supports CRLF for FTP control packet by default. It also supports LF if the following command is configured:
 

#set security alg ftp line-break-extension


For line-break-extention configuration, see ftp (Security ALG) :


line-break-extension—Enable line-break-extension. This option will enable the FTP ALG to recognize the LF as line break in addition to the standard CR+LF (carriage return, followed by line feed).


Notes:

  • If FTP control packet does not end with CRLF or LF, FTP ALG is not able to forward the FTP packet. SRX does not support this scenario.
  • This may occur in a scenario where the FTP data packet uses the same port number as the FTP control packet. This may happen if there is an FTP proxy server between an SRX and an FTP server.


The other possible cause is PR1750148. there is a logical problem in jbuf length handling, which led to jbuf usage high at the time of some kind of ftp traffic. Developer had a fix now, the fix will be in 21.2R3-S7

Modification History

2023-10-26 - testing edit function
2023-12-22: adding 2nd possible cause