Filezilla IPv6 timeout on LIST

[raidenii]

Hello,

I am using Filezilla 3.14.1 x64 on Windows connects to my FTP server running vsftpd 3.0.2 with implicit FTPS.

The connection works totally fine over IPv4, but when connecting via IPv6, Filezilla will stuck at the LIST command until timeout, while the server log does not prompt anything wrong. I switched to FlashFXP and tested with IPv6 connection and it works fine. I guess it's a bug in Filezilla.

Thanks.

[Tim Kosse]

Please post a complete and unmodified log from FileZilla showing the error. A log from FlashFXP for comparison would be useful as well.

[raidenii]

'Replying to codesquid:

Please post a complete and unmodified log from FileZilla showing the error. A log from FlashFXP for comparison would be useful as well.

Can I have my server's address, port and username erased?

FileZilla:

Status: Resolving address of server.addr
Status: Connecting to [ipv6:addr]:port...
Status: Connection established, initializing TLS...
Status: Verifying certificate...
Status: TLS connection established, waiting for welcome message...
Response: 220 Private FTP Server
Command: USER user
Response: 331 Please specify the password.
Command: PASS *
Response: 230 Login successful.
Command: SYST
Response: 215 UNIX Type: L8
Command: FEAT
Response: 211-Features:
Response: AUTH TLS
Response: EPRT
Response: EPSV
Response: MDTM
Response: PASV
Response: PBSZ
Response: PROT
Response: REST STREAM
Response: SIZE
Response: TVFS
Response: 211 End
Command: PBSZ 0
Response: 200 PBSZ set to 0.
Command: PROT P
Response: 200 PROT now Private.
Status: Connected
Status: Retrieving directory listing...
Command: PWD
Response: 257 "/"
Command: TYPE I
Response: 200 Switching to Binary mode.
Command: EPSV

Response: 229 Entering Extended Passive Mode (

|40016|).

Command: LIST
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing
Status: Disconnected from server
Status: Resolving address of server.addr
Status: Connecting to [ipv6:addr]:port...
Status: Connection established, initializing TLS...
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Could not connect to server
Status: Waiting to retry...
Error: Connection attempt interrupted by user

FlashFXP:

[14:22:17] FlashFXP 5.2.0 (build 3890)
[14:22:17] Support Forums ​http://www.flashfxp.com/forum/
[14:22:17]
[14:22:17] Winsock 2.2 -- OpenSSL 1.0.2d 9 Jul 2015
[14:22:30] [R] Connecting to [ipv6:addr] -> DNS=[ipv6:addr] IP=ipv6:addr PORT=port
[14:22:30] [R] Connected to [ipv6:addr]
[14:22:30] [R] TLSv1.2 negotiation successful...
[14:22:30] [R] TLSv1.2 encrypted session using cipher AES256-GCM-SHA384 (256 bits)
[14:22:32] [R] 220 Private FTP Server
[14:22:32] [R] PBSZ 0
[14:22:32] [R] 200 PBSZ set to 0.
[14:22:32] [R] USER user
[14:22:32] [R] 331 Please specify the password.
[14:22:32] [R] PASS (hidden)
[14:22:32] [R] 230 Login successful.
[14:22:32] [R] SYST
[14:22:32] [R] 215 UNIX Type: L8
[14:22:32] [R] FEAT
[14:22:32] [R] 211-Features:
[14:22:32] [R] AUTH TLS
[14:22:32] [R] EPRT
[14:22:32] [R] EPSV
[14:22:32] [R] MDTM
[14:22:32] [R] PASV
[14:22:32] [R] PBSZ
[14:22:32] [R] PROT
[14:22:32] [R] REST STREAM
[14:22:32] [R] SIZE
[14:22:32] [R] TVFS
[14:22:32] [R] 211 End
[14:22:32] [R] PWD
[14:22:32] [R] 257 "/"
[14:22:32] [R] PROT P
[14:22:32] [R] 200 PROT now Private.
[14:22:32] [R] EPSV

[14:22:32] [R] 229 Entering Extended Passive Mode (

|40049|).

[14:22:32] [R] Opening data connection IP: ipv6:addr PORT: 40049
[14:22:32] [R] LIST -al
[14:22:32] [R] TLSv1.2 negotiation successful...
[14:22:32] [R] TLSv1.2 encrypted session using cipher AES256-GCM-SHA384 (256 bits)
[14:22:32] [R] 150 Here comes the directory listing.
[14:22:33] [R] 226 Directory send OK.
[14:22:33] [R] List Complete: 115 bytes in 0.79 seconds (0.1 KB/s)

[Tim Kosse]

{{{Command: EPSV

Response: 229 Entering Extended Passive Mode (

|40016|).

Command: LIST
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing
Status: Disconnected from server}}}

Everything looks absolutely normal until the failure.

{{{Status: Resolving address of server.addr
Status: Connecting to [ipv6:addr]:port...
Status: Connection established, initializing TLS...
Error: GnuTLS error -15: An unexpected TLS packet was received.
Error: Could not connect to server}}}

This is most interesting, it indicates a deeper underlying problem with the server or an active networking component sitting between client and server.

Could you please attach a packet capture, e.g. using Wireshark, of an attempt to LIST and the subsequent reconnect failure?

[raidenii]

Wireshark Capture

[Tim Kosse]

Unfortunately the data connection is missing from the dump, it only shows the control connection(s).

Please create a dump that includes the data connection.

The second control connection contains this plaintext message: "421 There are too many connected users, please try later."
Note that, since it is plaintext, an attacker could have forged this message. It is not being protected by TLS.

[raidenii]

Replying to codesquid:

Unfortunately the data connection is missing from the dump, it only shows the control connection(s).

Please create a dump that includes the data connection.

The second control connection contains this plaintext message: "421 There are too many connected users, please try later."
Note that, since it is plaintext, an attacker could have forged this message. It is not being protected by TLS.

Interesting, that must be a bug of vsftpd. It shall never send those control messages over plaintext especially when I have specified that all control and data should use ssl.

Plus, I think this should be related to my firewall - I'm using Symantec Endpoint Protection and seems that when I disable it, the connection over IPv6 went through. Although I still have no idea that 1)why the IPv4 works without any problem and 2) other IPv6 traffic works totally fine, for I have checked the IPv6 rules in SEP and didn't find anything that specifically blocks the ports I use, and that does not explain why that while firewall is on, FlashFXP can work without problems.

I'm not exactly sure how to capture the data stream - the filter I use was to limit the ipv6 source address to be either local or the server address, and vice versa. I didn't limit the ports it listens so it should have captured all.

[Tim Kosse]

Interesting, that must be a bug of vsftpd. It shall never send those control messages over plaintext especially when I have specified that all control and data should use ssl.

Yes, it unfortunately checks some limits and sends an error on an exceeded limit before doing the handshake.

Note that implicit FTP over TLS isn't standardized, there's no RFC for it. As such it is considered deprecated. You should use explicit FTP over TLS which has been properly specified in RFC 4217 (​https://tools.ietf.org/html/rfc4217).

Although I still have no idea that 1)why the IPv4 works without any problem and 2) other IPv6 traffic works totally fine

Could be many things. Different TCP options or subtly different timing.

Another possibility is the data connection's source IP. FileZilla ensures that the data connection's source IP matches the control connection's source IP. It is a necessary feature in order to connect to servers that require a matching IP to mitigate FTP connection stealing attacks. Many third-party clients do not have this security feature. Unfortunately binding the data connection IP seems to trigger bugs in several popular firewall products (e.g. ​https://forum.filezilla-project.org/viewtopic.php?p=137317#p137317), perhaps SME has such a bug as well.

I'm not exactly sure how to capture the data stream - the filter I use was to limit the ipv6 source address to be either local or the server address, and vice versa for ipv6 dst. I didn't limit the ports it listens so it should have captured all.

That means that the firewall must have blocked the connection completely so that no packet was actually sent.

[raidenii]

Thanks so much for the explanation. I would close this ticket since it does not seems to be a bug of Filezilla but rather the firewall.