RE: ENETUNREACH - Network unreachable in 3.11.0

Need help with FileZilla Client? Something does not work as expected? In this forum you may find an answer.

Moderator: Project members

Message
Author
DailyLama
500 Syntax error
Posts: 13
Joined: 2015-07-28 07:17

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#31 Post by DailyLama » 2015-07-29 14:07

botg wrote: That's the problem. The control connection source IP cannot possibly originate from 127.0.0.1 when you are connected to a public IP address, 127.0.0.1 is the unroutable localhost loopback address. The only time this can happen is if a firewall (or traffic redirection malware) redirects traffic in a forbidden way.
I will send you a new netstat, but please take a look at the attached pictures. The firewall component is not running...which component is doing this then :(?
Attachments
Capture2.JPG
Capture2.JPG (16.21 KiB) Viewed 8463 times

DailyLama
500 Syntax error
Posts: 13
Joined: 2015-07-28 07:17

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#32 Post by DailyLama » 2015-07-29 14:12

So, yes, after deactivating Kaspersky it works.
I was not aware that even with the firewall module inactive it does things like this.

Sorry, I stand corrected.

Do you maybe have an detailed explanation of what is exactly going on so I can open a ticket with Kaspersky?

DailyLama
500 Syntax error
Posts: 13
Joined: 2015-07-28 07:17

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#33 Post by DailyLama » 2015-07-29 14:17

Solution for Kaspersky Endpoint Security

If you manage it with Kaspersky Security Center, add this exception to the policies
Trusted Applications ->
Path %ProgramFiles(x86)%\FileZilla FTP Client\filezilla.exe
) Do not inherit restrictions of the parent process
) Do not scan network traffic

Then FileZilla can do it's work again :)
Attachments
Capture.JPG
Capture.JPG (30 KiB) Viewed 8460 times

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#34 Post by botg » 2015-07-29 15:16

DailyLama wrote:Do you maybe have an detailed explanation of what is exactly going on so I can open a ticket with Kaspersky?
Kaspersky inspects and filters network traffic. For some reason, instead of using a simple filter driver, it opts to transparently redirect all network traffic through avp.exe at 127.0.0.1:1110


Let's say FileZilla does FTP with 93.184.216.34.

This is what normally happens, without a firewall:
- FileZilla establishes the control connection to 93.184.216.23
- Initially no source IP is set, it automatically gets assigned by the operating system. Let's say 10.0.0.123, which is a typical address for users behind a NAT router.
- Once the connection has established, FileZilla knows that it is possible to connect to 93.184.216.23 from 10.0.0.123, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 10.0.0.123 [1] and connects to 93.184.216.23

This is with Kaspersky firewall running:
- FileZilla wants to establish the control connection to 93.184.216.23.
- Kaspersky redirects the connection to avp.exe on 127.0.0.1:1110 which in turn connects to 93.184.216.23
- This time around the source IP assigned by the operating system is 127.0.0.1
- Even though the connection is clearly redirected to destination IP 127.0.0.1, as can be seen in netstat output, getpeername() still returns 93.184.216.23
- FileZilla now knows that it is possible to connect to 93.184.216.23 from 127.0.0.1, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 127.0.0.1 and tries to connect to 93.184.216.23
- Due to being the loopback address, no other addresses can be reached from 127.0.0.1, so the result is ENETUNREACH


So far the facts. Here's a bit of conjecture what happens: Even though the traffic is redirected, Kaspersky fakes the result of getpeername() so that the original destination IP is still reported. At the same time though it does not fake the output of the getsockname() API function.



[1] The binding is new since FileZilla 3.11.0-rc1. It is not only a security feature but also a necessary compatibility feature when running on a host implementing RFC 4931.
Last edited by botg on 2015-07-29 15:22, edited 3 times in total.
Reason: Fixed a typo

DailyLama
500 Syntax error
Posts: 13
Joined: 2015-07-28 07:17

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#35 Post by DailyLama » 2015-07-30 08:53

Wow, that's messed up by Kaspersky :(

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#36 Post by botg » 2015-07-30 09:01

It gets even better: For some users, Kaspersky injects fake TLS certificates into TLS connections.

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#37 Post by boco » 2015-08-02 08:27

botg wrote:It gets even better: For some users, Kaspersky injects fake TLS certificates into TLS connections.
It's by far not alone with this.
No support requests over PM! You will NOT get any reply!!!
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org

dmikester1
500 Command not understood
Posts: 2
Joined: 2012-05-09 13:48

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#38 Post by dmikester1 » 2015-08-06 12:56

DailyLama wrote:So, yes, after deactivating Kaspersky it works.
Do you maybe have an detailed explanation of what is exactly going on so I can open a ticket with Kaspersky?
Hopefully you will have better luck than me. I opened a ticket with Kaspersky. I explained the issue to them using several quotes from mod on this forum. They kept trying to blame Filezilla and they wanted to me to do a whole bunch of extra work testing on my end! Their first idea for a "solution" was to just disable the FTP scanning. Well, that sounds pretty secure doesn't it! Then they asked me to upgrade our Kaspersky version to the latest version to see if that would fix it. Well, we have Kaspersky on a lot of computers here, and that is just not possible. I wasn't very happy with how they handled it.

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#39 Post by botg » 2015-08-06 18:45

That's really sad :(

My services are for hire, perhaps Kaspersky should consider bringing me in a consultant so that I can explain to them how TCP and the Windows API works. 8)

freekieran
500 Command not understood
Posts: 2
Joined: 2015-09-28 04:58
First name: Kieran
Last name: Cook

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#40 Post by freekieran » 2015-09-28 05:03

botg wrote:
DailyLama wrote:Do you maybe have an detailed explanation of what is exactly going on so I can open a ticket with Kaspersky?
Kaspersky inspects and filters network traffic. For some reason, instead of using a simple filter driver, it opts to transparently redirect all network traffic through avp.exe at 127.0.0.1:1110

Let's say FileZilla does FTP with 93.184.216.34.

This is what normally happens, without a firewall:
- FileZilla establishes the control connection to 93.184.216.23
- Initially no source IP is set, it automatically gets assigned by the operating system. Let's say 10.0.0.123, which is a typical address for users behind a NAT router.
- Once the connection has established, FileZilla knows that it is possible to connect to 93.184.216.23 from 10.0.0.123, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 10.0.0.123 [1] and connects to 93.184.216.23

This is with Kaspersky firewall running:
- FileZilla wants to establish the control connection to 93.184.216.23.
- Kaspersky redirects the connection to avp.exe on 127.0.0.1:1110 which in turn connects to 93.184.216.23
- This time around the source IP assigned by the operating system is 127.0.0.1
- Even though the connection is clearly redirected to destination IP 127.0.0.1, as can be seen in netstat output, getpeername() still returns 93.184.216.23
- FileZilla now knows that it is possible to connect to 93.184.216.23 from 127.0.0.1, as returned by the getpeername() and getsockname() API functions
- To transfer a file or directory listing, a data connection needs to be established. Both source and destination IP of data connection must match the control connection to mitigate the FTP data connection stealing attack.
- FileZilla binds the source IP of the data connection to 127.0.0.1 and tries to connect to 93.184.216.23
- Due to being the loopback address, no other addresses can be reached from 127.0.0.1, so the result is ENETUNREACH


So far the facts. Here's a bit of conjecture what happens: Even though the traffic is redirected, Kaspersky fakes the result of getpeername() so that the original destination IP is still reported. At the same time though it does not fake the output of the getsockname() API function.



[1] The binding is new since FileZilla 3.11.0-rc1. It is not only a security feature but also a necessary compatibility feature when running on a host implementing RFC 4931.
-----------------
So, how did it all work BEFORE this raised its ugly head? what part was specifically corrected in Filezilla that needs to be reflected in Kaspersky's FW (and others I presume)?

User avatar
boco
Contributor
Posts: 26913
Joined: 2006-05-01 03:28
Location: Germany

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#41 Post by boco » 2015-09-28 06:18

The data connections are now specifically bound to the same local IP address the browsing connection originates from. This is to prevent connection stealing. Previously FileZilla asked the OS for an IP every time, so you could end up using a different IP for browsing vs. data connections.

Those firewalls silently rewrite IPs to redirect the traffic through their processes. They simply assume that programs always ask the OS for IPs. When FileZilla now attempts to do the explicit binding, the IP it gets for the browsing connection (127.0.0.1 / [::1] / localhost) is incorrect (since it has been modified by the firewall). That localhost address cannot be used as it simply redirects to the same PC. Connections fail.
No support requests over PM! You will NOT get any reply!!!
FTP connection problems? Please read Network Configuration.
FileZilla connection test: https://filezilla-project.org/conntest.php
FileZilla Pro support: https://customerforum.fileZilla-project.org

freekieran
500 Command not understood
Posts: 2
Joined: 2015-09-28 04:58
First name: Kieran
Last name: Cook

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#42 Post by freekieran » 2015-09-28 06:39

please excuse my ignorance here. I understand the idea behind wanting to secure the product from potential connection stealing.
Is this something that is unique to Kaspersky's firewall, or is this potentially a larger scope issue?
I've dealt with perimeter security gateways previously that intercept FTP traffic. In order to connect to the intended remote location you would proxy through the GW by directly connecting to it.
For example
ftp -> gw address
user -> user@<remote address>
pwd -> normal password

is this something we could possibly look at for filezilla?

ftp -> localhost
.... now that i'm typing this... I guess it would need to be the firewall which facilitates this translation... <thinking out loud>

Do other ftp clients work like this as well? Google ENETUNREACH appears to show that filezilla is the only client recently to be exhibiting this behaviour.

is there ANYTHING we can do as a short term work around while we work with the likes of Kaspersky to try to fix this, apart from this http://www.tidbitsfortechs.com/2015/08/ ... reachable/

User avatar
botg
Site Admin
Posts: 35508
Joined: 2004-02-23 20:49
First name: Tim
Last name: Kosse

Re: RE: ENETUNREACH - Network unreachable in 3.11.0

#43 Post by botg » 2015-09-28 06:56

This issue is independent of FTP proxies.
Do other ftp clients work like this as well? Google ENETUNREACH appears to show that filezilla is the only client recently to be exhibiting this behaviour.
Unfortunately many other clients do not ensure that the data connection source IP matches the control connection source IP, leading to other types of connection failures different than ENETUNREACH.

Simple example: IPv6 environment with enabled privacy extensions (RFC 4941), configured with a short renewal interval (low TEMP_PREFERRED_LIFETIME). Connect to any FTP server that guards against connection stealing, wait until your preferred IP changes (yet the old IP is still valid), then try to obtain a directory listing on the previously established connection. Works with FileZilla, fails with other clients that do not bind the data connection IP.

Same thing can happen if establishing a VPN connection while a FTP client is already connected to a server. Works fine with FZ, other clients will need to reconnect.
is there ANYTHING we can do as a short term work around while we work with the likes of Kaspersky to try to fix this, apart from this http://www.tidbitsfortechs.com/2015/08/ ... reachable/
Yes. You can uninstall your firewall, or if that's not desired, at least change its configuration to no longer disrupt FileZilla.



On related news: Did you see http://googleprojectzero.blogspot.de/20 ... blems.html ? In my opinion people put way too much faith into firewalls and AV products.
Last edited by boco on 2015-09-28 08:14, edited 1 time in total.
Reason: Corrected URL BBCode.

Post Reply