this is quite related to this question regarding GCP, but on AWS, and also trying to solve it with a different approach.
I have an FTP client trying to connect in ftp active mode to some ftp servers located on the Internet. The FTP client has private address, and it is behind a NAT instance server (not NAT Gateway)
This NAT-server has private address too, and is itself behind the VPC Internet GW.
FTP client (10.60.0.0/24) --> NAT server (10.254.254.0/24) --> IGW --> Internet --> Firewall/NAT --> FTP Servers
NAT Server is AWS NAT Linux (kernel 4.9) with masquerading turned on.
With Active-FTP (port mode), this is not working.
I already activated CT FTP helper (nf_nat_ftp) and its triggering iptables rule:
iptables -A PREROUTING -t raw -p tcp --sport 1024: --dport 21 -j CT --helper ftp
and I can see that the "PORT" command is being correctly translated from the private IP address of FTP client to the private IP of the NAT server.
Unfortunately, this isn't enough, because the FTP Server is receiving an FTP "PORT" command still with a private address (the one of the NAT server).
So the ftp data connection, initiated from the ftp server, of course never reaches back.
I cannot, at least for now, "replace" the ftp client (it's part of a legacy application).
Is there any way to "inject" the public IP in the PORT command ? Some ideas came to my mind, but I could not find proofs whether they are realistic or I'm wasting my time:
creating a "fake" interface on the nat server with the public ip address, and selectively enabling/disabling CT helper to modify the PORT command. I have troubles with the correct routing for this, though (let alone convincing myself it's worth trying)
modifying the nf_nat_ftp helper module with hard-coded public IP (so uglyyy!)
modifying the port command on the ftp client (it's a Windows machine), don't know if a driver/tool already exists for that purpose
brute-patching the ftp client (might be the most realistic way...?)
About option 3: I tried NETSED, which actually can change the PORT command, but it seems to mess up the nat for the ftp client! :(
Other solutions are of course welcome!