**********Never mind: this was the result my own stupidity -- sorry for the trouble ************
I had earlier changed the FTP mode from Passive to Active and forgotten to change it back when addressing this issue.
I am having issues trying to get Filezilla FTP client working from internal client machines to outside public FTP sites. I'm using the standard packet filter generated by installation, but not the FTP proxy. The FTP connection tracking helper is turned on.
What happens is that the connection sets up properly all the way to the LIST command, at which time it stalls (the LIST is the first time it tries to use the secondary (data) channel which was agreed upon earlier in the FTP setup sequence).
A look at the Live Dropped Packets log shows that indeed all the packets on the data channel are being dropped -- they show in red and say "Default Drop". However, there are two earlier packets also shown in the list which are gray rather than red and do NOT say "Default Dropped", and then there are two other response packets dropped that are still on the control channel (port 21).
Here is the relevant part of the dropped packet log:
12:34:13 TCP 72.x.y.84:18675 → 199.84.164.13:21 [ACK PSH]
12:34:13 TCP 72.x.y.84:18675 → 199.84.164.13:21 [ACK PSH]
12:34:13 Default DROP TCP 199.84.164.13:21 → 72.x.y.84:18675 [ACK PSH]
12:34:14 Default DROP TCP 199.84.164.13:21 → 72.x.y.84:18675 [ACK PSH]
12:34:14 Default DROP TCP 199.84.164.13:20 → 72.x.y.84:18676 [SYN]
12:34:17 Default DROP TCP 199.84.164.13:20 → 72.x.y.84:18676 [SYN]
12:34:23 Default DROP TCP 199.84.164.13:20 → 72.x.y.84:18676 [SYN]
12:34:35 Default DROP TCP 199.84.164.13:20 → 72.x.y.84:18676 [SYN]
12:34:59 Default DROP TCP 199.84.164.13:20 → 72.x.y.84:18676 [SYN]
The first two of these are gray, and the rest are red -- what does gray signify?
The thing is that 72.x.y.84 is not my external interface address, it is an address in the range of our public IP addresses, and is normally mapped using DNATs to an internal server here, and is the specified in the "use address" field of the masquerading entry for the internal subnet. So these first two packets are from after the masquerade translation, but I can't think why they would be treated any differently from any of the previous setup packets.
I have looked for knowledge base articles on the subject, but can't find anything at all about FTP that isn't using the FTP proxy.
What am I doing wrong?
Thanks in advance,
Paul
This thread was automatically locked due to age.