FileZilla Client (Windows) uses IPv6 in preference to IPv4 - Fallback to IPv4 does not work in all cases

[Michael Gruber]

Ticket #4204 is still an issue:

In preparation of the World IPv6 Day at 8 June 2011 we added AAAA Records in the DNS to the host names of our servers.

We can successful connect to all the services at the server via IPv6 - with the exception of the FileZilla Server, that does not offer IPv6 support.

This should not be an issue, because the Clients like web browsers or mail clients typically first try IPv6 and then fallback to IPv4, if no IPv6 connection can be established.

But the FileZilla Client does no fallback to the IPv4 address (what is also sent by the DNS server), FTP doesn't work any longer.

This could get an big issue and could cast a damning light on the FileZilla Client after IPv6 will be enabled by more and more ISP - not only at the World IPv6 Day!

[Tim Kosse]

FileZilla Client _does_ fall back to IPv4. Only when the initial TCP handshake succeeds, no fallback will be done.

You should be able to check with a network sniffer that the initial handshake does not fail in your case, meaning that something is listening on the IPv6 port.

[Tim Kosse]

From a connection attempt I just did on an IPv6 enabled server:

Status: Resolving address of filezilla-project.org
Status: Connecting to [2a01:4f8:61:61a3::2]:21...
Status: Connection attempt failed with "ECONNREFUSED - Connection refused by server", trying next address.
Status: Connecting to 213.239.222.5:21...
Status: Connection established, waiting for welcome message...

[Michael Gruber]

It seems like FileZilla Client does no fall back, if a timeout occurs:

Status: Resolving address of srv01.agelero.de
Status: Connecting to [2a01:4f8:101:5381::2]:21...
Error: Connection timed out
Error: Could not connect to server
Status: Waiting to retry...
Status: Resolving address of srv01.agelero.de
Status: Connecting to [2a01:4f8:101:5381::2]:21...
Error: Connection timed out
Error: Could not connect to server

C:\Users\Michael>nslookup srv01.agelero.de
Server: localhost
Address: ::1

Name: srv01.agelero.de
Addresses: 2a01:4f8:101:5381::2

178.63.1.22

C:\Users\Michael>nslookup filezilla-project.org
Server: localhost
Address: ::1

Nicht autorisierende Antwort:
Name: filezilla-project.org
Addresses: 2a01:4f8:61:61a3::2

213.239.222.5

If I try filezilla-project.org, it works fine for me as well. If I try our server (IPv6 Port 21 is not blocked by a firewall on that server, just nothing listens on this port) FileZilla Client runs into a timeout and retries IPv6 again and again.

The DNS Records seem to be similar for both hosts.

[Michael Gruber]

Tests with Wireshark show one difference in communication:

filezilla-project.org:
Client -> Server: SYN-Packet via IPv6
Client <- Server: RST, ACK via IPv6
Client -> Server: SYN-Packet via IPv6
Client <- Server: RST, ACK via IPv6
Client -> Server: SYN-Packet via IPv4
Client <- Server: SYN, ACK via IPv4
Connection established!

srv01.agelero.de:
Client -> Server: SYN-Packet via IPv6
Client <- Server: [no response]
Client -> Server: SYN-Packet via IPv6
Client <- Server: [no response]
Client -> Server: SYN-Packet via IPv6
Client <- Server: [no response]
Client loops with IPv6 only tries.

It seems like the fall back of FileZilla Client is only triggered, if the connection gets blocked by a [RST, ACT] Packet from the server - but not, if a timeout occurs.

[Tim Kosse]

Badly configured firewall at the server. It fails to reply with a RST if trying to connect to a port that isn't open.

Please contact the server administrator for assistance.

[Michael Gruber]

Please note, that not the firewall is badly configured.

This is the default behavior of the Windows Firewall with Advanced Security in Windows Server 2008, Windows Server 2008r2 and Windows 7, a "feature" called Stealth Mode: "Stealth mode blocks outgoing ICMP unreachable and TCP reset messages for a port when no application is listening on that port" (Source: <​http://technet.microsoft.com/en-us/library/dd448557%28WS.10%29.aspx>).

If anyone else has the similar issue:

This behavior cannot be switched off by a simple button in the Windows GUI - of course - that would be too easy. Instead you have to create several registry entries and reboot Windows after that:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall]

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\DomainProfile]
"DisableStealthMode"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PrivateProfile]
"DisableStealthMode"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\PublicProfile]
"DisableStealthMode"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsFirewall\StandardProfile]
"DisableStealthMode"=dword:00000001

This causes Windows to send RST as required by RFC 793 and FileZilla Client to work as intended.

Maybe it would be easier if FileZilla simply would use the next ip address (as it does, if a RST is received), if the server doesn't send a RST...