I agree on source port issue, but I don't think that in case of TLS there is nothing that can be done with FTP helper. Still we can assume that just after TLS AUTH negotiation, client will connect on high port with new connection to server. Now we are in situation, where if TLS is used, high ports on server side must be open all the time. With IPTables it was at least possible to make workaround with "recent" extension, with NFTables we have nothing. 2015-05-17 15:32 GMT+02:00 Pascal Hambourg <pascal@xxxxxxxxxxxxxxx>: > Tomek L a écrit : >> Helper doesn't have to look into encrypted payload. > > The helper needs to look into the control connection. > >> It would be enough >> if helper assumes that in the next ~3 seconds, netfilter can expect >> incoming connection from client on high port, from source port +1 >> higher than original source port used when initiating connection. > > This assumption is wrong. AFAIK there is no requirement in the RFCs that > the source port for a data connection be +1 higher than the original > source port used for the control connection. I checked my FTP client > (tnftp), it uses random source ports for each data connection. Besides, > source ports may be mangled by any NAT device in the path. > > The only requirement is for active mode, the server should use the > control port -1 (usually 21-1 = 20) as the source port for data connections. -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
