Problem with passive mode (urgent problem - please help)

[cpi-ivu]

Hi!
I have an urgent problem: I'm running Filezilla Server on an Amazon EC2 instance. I want the server to be accessible
from intern (IP: 172.100.51.4). Now the EC2 instance has a public elastic IP. Now the problem: As I have to use passive
mode, either the clients from inside kann transfer files (Settings -> Passive Mode Settings -> IP set to [Default]), or
the Clients from outside can connect (Settings -> Passive Mode Settings -> IP set to [the public IP]).

It seems that because the IP 172.100.51.4 is internet routable, the server doesn't accept
transfers because it thinks the IP is Public and therefore adds the real public IP to the FTP packages.

How to solve this problem?

Thanks!

[botg]

Leaving it at default should work in all cases.

Is their a NAT involved that changes the source IP of incoming connections?

[cpi-ivu]

Is their a NAT involved that changes the source IP of incoming connections?

No. It's an EC2 instance with elastic Public IP adress. It should act like an normal internet-connected server.

Leaving it at default should work in all cases.

So what we have discovered is, that if you choose "default" the client is told to use the internal IP of the instance (172.100.51.4). So for internal clients there is no problem when connecting and transferring. But if an external client tries to connect, it gets the same (172.100.51.4) IP and therefore doesn't know how to transfer (you can see the 172.100.51.4 in the response log of the server) - although the connection is successful.

If we set the external IP in the settings, it's vice versa: the external clients can connect and transfer, but the internal only can connect and not transfer.

We have now connected the internal instance that is holding the client to the internet and connected against the public IP of the server holding isstance. We can now connect to the serve successfully.

The question is: why do internal clients get the external IP as target if they come from 172.100.51.4? Why don't they simply get the source IP (=172.100.51.4) as target to connect? Is that because 172.100.51.4 is outside Class B?

Thanks in advance!

[boco]

FileZilla Server has an option to handle local connections. Unfortunately, the "local" IP you have does not fall into one of the private ranges reserved for that purpose.
Alone the fact that you have both an "internal" and external IP means there is some type of gateway (most probably NAT) in place. A direct dedicated connection to the Internet would provide you with one public IP address only.

Pragmatic solution: Have internal clients use Active (PORT) mode. That should work as the client will propose the IP.

[cpi-ivu]

FileZilla Server has an option to handle local connections. Unfortunately, the "local" IP you have does not fall into one of the private ranges reserved for that purpose.

Ok. But what is the action by the server then (saying: there comes an connection from 172.100.51.4)? It allows the login but denies the transfer? Why accepting the login?

Alone the fact that you have both an "internal" and external IP means there is some type of gateway (most probably NAT) in place. A direct dedicated connection to the Internet would provide you with one public IP address only.

Yes your're right. But there is no extra NAT Gateway. Only the standard AWS NAT way.

Pragmatic solution: Have internal clients use Active (PORT) mode. That should work as the client will propose the IP.

Sadly, that's no option for us as our software can't manage active FTP connections.

So all in all: we only have the option to access over the right Class B net or through the external IP?