Opened 8 months ago

Closed 8 months ago

#12421 closed Bug report (worksforme)

Passive mode not honoring first connection IP when using proxy

Reported by: miguel.g757 Owned by:
Priority: normal Component: FileZilla Client
Keywords: ftp passive nat Cc:
Component version: 3.53.1 Operating system type: Windows
Operating system version: 10

Description

Hello,

I'd like to understand if this is a bug - it does very much look like one to me.

Scenario: FTP server behind NAT

Behavior without proxy:
When using FTP passive mode, and the server replies with its real IP address, Filezilla ignores it, uses the original IP instead, and uses the port for data connection. This is absolutely correct.

Behavior with proxy:
When using FTP passive mode, and the server replies with its real IP address, Filezilla send a new request to the proxy but uses the server reply. The proxy tries to contact the server's real IP, and (in most scenarios) fails.

I found this issue with FTPS, not plain FTP, but the implementation might be the same. It doesn't help that the traffic is encrypted, otherwise I could have found some workaround. But with encrypted traffic I have no chance to do so.

BR,
Miguel

Change History (1)

comment:1 by Tim Kosse, 8 months ago

Resolution: worksforme
Status: newclosed

I found this issue with FTPS, not plain FTP

This is due to malicious routers and firewalls modifying FTP traffic. Instead of exposing easy to fix server configuration issues, they hide them. Obviously if using FTP over TLS, they can no longer modify FTP traffic and the configuration issue finally gets the exposure it deserves.

real IP address

What is a real IP address? There are two types of IP addresses: Public and private ones. I assume you wrongly think private IP addresses are "real" based on the described symptoms.

Behavior without proxy:
When using FTP passive mode, and the server replies with its real IP address, Filezilla ignores it, uses the original IP instead, and uses the port for data connection. This is absolutely correct.

No, this is not correct. If FileZilla connects to a server behind a NAT through its public address, yet the server returns a private IP address in its PASV reply, the server isn't configured correctly. This simply cannot work. Because it cannot work, FileZilla instead tries the public IP address of the server, in the hopes that even though the server might not be configured correctly, the NAT router is with the correct ports forwarded. To fix this, the server must advertise its public IP address in the PASV reply.

Behavior with proxy:
When using FTP passive mode, and the server replies with its real IP address, Filezilla send a new request to the proxy but uses the server reply. The proxy tries to contact the server's real IP, and (in most scenarios) fails.

Every proxy has two endpoints, a client-facing and a server-facing one. If a proxy is used, the client doesn't know anything about the network on the other end of the proxy, it has no choice but to trust the data it receives from the server through the proxy. The previous "cannot work" heuristic would break working, properly configured setups if a proxy is used.

The TL;DR: Fix the bug in the server configuration.

Note: See TracTickets for help on using tickets.