FTP clien sends TCP RST and hangs

[alnash]

Hi,

I have two hosts in different LANs: 192.168.1.1 and 192.168.2.1. The LANs are routed, the hosts can ping each other, there seems no firewalls or something.

There's a vsftpd server on 192.168.1.1 and a standard ftp client on 192.168.2.1
The server is functional and anonymously accessible on localhost, with the same standard 'ftp' client

But when I try to connect the server from another host "ftp 192.168.1.1" -- the client says "Connected" and then hangs.
In Wireshark on 192.168.1.1 server I see that TCP connection with 192.168.2.1 get established, vsftpd sends out "220 Ready", the client sends back TCP RST package and it all hangs...

What can be an issue about it?

[mike155]

What do you see when you run Wireshark (or tcpdump) on the client? Does it receive the "220 Ready" message? What happens after that? Does the client try to open a data connection? Does it happen in both active and passive mode?

[alnash]

It happens in active and passive mode.
With Wireshark on client I see that TCP connection gets established between client and server (SYN - SYN, ACK - ACK).
Then client receives a FTP response "220 Ready" -- from router's address.
The the client sends TCP RST to the router's address -- and hangs...

The client is on the router's WAN side, and the server is on LAN side.
Somehow the server sees TCP RST incoming from the client.

[Hu]

Every packet associated with a given TCP flow ought to have the same source/destination address/port pair. As I read your most recent post, some of the traffic comes from the actual peer address, and some comes from the router's address. If that happens, then the network is misconfigured. The client is correct to send a TCP RST to a host that, as far as the client knows, has no business communicating with it. That 220 Ready should have had the same address/port as the SYN|ACK that the server sent earlier in the flow. Could you post an anonymized listing of the packet flow? Blank out any public IP settings, as long as you blank them out consistently. I just want to see something like:

client-private-IP send SYN
server-private-IP send SYN|ACK
client-private-IP send ACK
router-public-IP send 220 Ready -> This would be a misconfiguration
server-private-IP send 220 Ready -> This would be correct

[alnash]

https://i.ibb.co/fCs1GdD/wireshark.png

Well, it's kinda difficult to upload images here, please let me know if there's a better way for it.

The linked screenshot is Wireshark on the client side.
The communication starts under the blue line.
192.168.1.1 is the FTP client
192.168.10.215 is the FTP server
192.168.1.54 is the router on the client side.
The overall scheme is like this: The internets -> gateway's public IP -> 192.168.1.1 gateway's private IP -> 192.168.1.54 internal router's WAN -> 192.168.10.1 internal router's LAN -> 192.168.10.215

[Hu]

That image confirms my understanding of your previous post. I believe the router is misbehaving. It should have rewritten the address information on the packet containing the 220. To debug this further, we would need to see the iptables rules the router is using.

[pietinger]

[alnash]

Yes, it was a misconfigured router... Namely, its NAT was enabled, while it shouldn't.
Thank you!

[alnash]

Unfortunately, I run into another problem here.

I've put the internal router in NAT mode and opened port 21 (they call it "virtual server") to FTP server. It looks like this now:

192.168.1.1 (FTP client) <-> 192.168.1.54:21 (NAT-ed "FTP-server" on router)< -> 192.168.10.215:21 (FTP server)

Now the client can connect and login (as anon, because I need anonymous uploads).

But it's not possible for the client to upload (put or STOR) files -- if the client is run as ordinary user. The server says "553 Cant create file" (but actually creates, only with 0 size).
However, uploading works Ok if the client is run as root.

I tried to play with permissions on server side, but no use...

[Hu]

FTP is notoriously NAT-unfriendly. If this were my environment, my approaches in order of preference would be:

• Stop using FTP. Use SFTP, which is transported over the SSH protocol and avoids the complications of running multiple TCP connections for one logical transaction. There are sftp clients for most major platforms.
• Put the intermediate device into a straight TCP NAT passthrough, with no awareness of FTP specific rules. .1.54 can rewrite source/destination IP, but does not examine the application data at all. Require the ftp client to use PASV so that all connections are initiated by .1.1 and received by .10.215.
• Stop using NAT. Let the client on .1.1 connect to .10.215 and see that as the peer's IP. Let the server see as its peer .1.1. From a network packet inspection, there should be no sign of .1.54 in any of the packet headers.

Your issue with root is probably some oddity around use of reserved ports.