Understanding & configuring FTP behind a router with my configuration

Question

I am trying to configure my FTP running on my local machine which connects to my control panel (162.0.0.1) that has a built-in FTP client. My local server (192.168.1.30) is connected to the control panel as a game server with the public IP as (152.5.5.5). Port 20/21 is forwarded on my router, but for some reason I cannot get this FTP server to work on my local machine with access from outside my local network. Possibly I am configuring the FTP configuration wrong, but when running the FTP server can be access locally just not externally.

• 192.168.1.30 - Local FTP server with Daemon running on it & the game server behind my router.
• 152.5.5.5 - My external IP
• 162.0.0.1 - Control panel web server with the web based FTP client. This is a VPS in lalaland.

Config 162.0.0.1 --> 152.5.5.5 --> 192.168.1.30

The control panel is Multicraft made for managing game servers. They have a built in FTP client that uses net2ftp in the browser which connects to the FTP server in this case 152.5.5.5/192.168.1.30.

These are all linux machines, and the router is an ASUS with merlin firmware. Port 21, 20, 5000-6000 ports are forwarded on the router for FTP.

Here is the configuration file I am working with that is on the 152.5.5.5/192.168.1.30 machine.

[ftp]
## Wheter or not to enable the integrated FTP server, true/false
## default: true
enabled = true
## IP to listen on for FTP connections, uncomment to use the same as
## for the daemon.
## 0.0.0.0 means listening on all available interfaces (all IPs)
## default: same as the "ip" setting for the daemon, see above
ftpIp = 192.168.1.30
## See the descriptions of "externalIp" and "ip" for the daemon above
## default: same as "externalIp" if "ftpIp" is "0.0.0.0" otherwise "ftpIp"
#ftpExternalIp = 152.5.5.5
## Masquerade IP address to use for passive FTP connections when
## Multicraft is running behind a router.
## default: empty
ftpNatIp = 152.5.5.5
## A port range to use for passive data transfers. If this is not
## specified the FTP server will use random ports.
## Format: 4000-8000
## default: empty
ftpPasvPorts = 5000-6000
## Port to listen on for incoming FTP connections. Change this to
## something else if you are already running an FTP server on this
## system.
## default: 21
ftpPort = 21
## Regular expression matching files that can't be manipulated by
## users in any way. If you want users to be able to upload their own
## plugins instead of using the ones you provide for them you can
## just comment this option out.
## default: empty
forbiddenFiles = 
## Set the level of detail for FTP server log messages in the multicraft.log.
## Errors will always be logged regardless of this setting.
## Available levels:
## full  - Log all messages
## basic - Don't log client/server communication
## none  - No FTP logging
## default: full
ftpLogLevel = full
## If this setting is enabled the FTP server will not be started when the main
## daemon process is started. You can start the FTP server separately by using
## "start_ftp" instead of "start" as the parameter to the daemon command.
## default: false
ftpSeparate = false
## The PID file for the FTP only process. The path is relative to "baseDir"
## default: multicraft_ftp.pid
ftpPidFile = multicraft_ftp.pid
## The log file to use for the FTP only process. This setting has no effect if
## the FTP server is started as part of the main daemon process (i.e. if
## "ftpSeparate" is false.
## default: multicraft.log (same as the daemon)
ftpLogFile = multicraftftp.log
## Throttle the FTP bandwidth (experimental)
## Incoming data throttle (Kb/s)
## default: 0 (unlimited) 
#ftpThrottleIn = 0
## Outgoing data throttle (Kb/s)
## default: 0 (unlimited) 
#ftpThrottleOut = 0

I have tried setting the ftpPasvPorts = with 5000-6000, but had no luck. Also switching around the IP/ExternalIp settings yeilds no results. I currently have no idea what I am doing with a lack of ideas.

To add to this, the local server 152.5.5.5/192.168.1.30 has a daemon running onto it which the FTP server uses. The daemon configuration is as follows below.

## The daemon will listen on the following IP/port.
## 0.0.0.0 to listen on all available interfaces (all IPs). Note that
## you will have to use the "externalIp" setting below if you set this
## to 0.0.0.0 as the control panel needs to know where to connect.
ip = 192.168.1.30 
port = 25465

## If the external address is different from the listen address
## you can set the external address here. This setting will be saved
## to the DB and used by the control panel to connect to the daemon.
## default: same as "ip"
externalIp = 152.5.5.5

They're all in the same config file.

The daemon connects to the control panel on 162.0.0.1 which then allows the game server to be controlled from along with the FTP server. I have enabled passive FTP in the control panel.

Note* FTP works locally. I can access the FTP server 152.5.5.5/192.168.1.30 locally with filezilla, but not externally.

EDIT: Below is the error log from ftptest.net

Warning: Plaintext FTP is insecure. You should use explicit FTP over TLS.

Status: Resolving address of 152.5.5.5
Status: Connecting to 152.5.5.5
Warning: The entered address does not resolve to an IPv6 address.
Status: Connected, waiting for welcome message...
Reply: 220 Multicraft 2.1.1 FTP server
Command: CLNT https://ftptest.net on behalf of 152.5.5.5
Reply: 500 Command "CLNT" not understood.
Command: USER cisnet.3
Reply: 331 Username ok, send password.
Command: PASS **********
Reply: 230 Login successful
Command: SYST
Reply: 215 UNIX Type: L8
Command: FEAT
Reply: 211-Features supported:
Reply: EPRT
Reply: EPSV
Reply: MDTM
Reply: MLST type*;perm*;size*;modify*;unique*;unix.mode;unix.uid;unix.gid;
Reply: REST STREAM
Reply: SIZE
Reply: TVFS
Reply: UTF8
Reply: 211 End FEAT.
Command: PWD
Reply: 257 "/" is the current directory.
Status: Current path is /
Command: TYPE I
Reply: 200 Type set to: Binary.
Command: PASV
Reply: 227 Entering passive mode (192,168,1,30,186,215).
Error: Server returned unroutable private IP address in PASV reply

EDIT #2 I have finally figured out the main FTP problem. FTP now works from the external 152.5.5.5 address which connects to my local 192.168.1.30 machine by changing the ftppasv= 152.5.5.5. The control panel however does not want to connect to the FTP even in passive mode... trying to locate the control panel logs to uncover the hidden secret.... Also the FTP port was changed from 21 to 513.

Answer 1

The question is currently tagged with sftp but doesn't mention SFTP at all.

Most modern protocols will rely on the information in the IP header. Routers that support features such as "port forwarding" (for incoming traffic) and "network address translation" (NAT) (for outgoing traffic) tend to look at the headers in IP packets and make appropriate changes.

FTP is a rather unique protocol. Like ICQ chat, it is a very old protocol that includes IP addresses in an IP packet's data payload. This breaks things horribly when firewalls block incoming traffic except for known ports.

Routers in the middle can modify IP headers by translating addresses between public IP addresses and private IP addresses, and TCP port numbers might get changed in the process. That's usually fine as long as the routers can keep track of individual conversations and keep changing the IP addresses (and possibly TCP port numbers) in a consistent way. However, FTP expects the data payload to also match what IP address(es) and TCP port number(s) get used. Routers typically don't adjust the data payload section of the IP address, and so it breaks.

The proper fix to this situation is to abandon the use of FTP, which typically requires authentication, and transmits authentication details without encryption, and transmits the files without encryption, and has issues with firewalls (which happened because FTP was designed in an era before firewalls were common). Instead, use SFTP, or SCP, or HTTPS, or maybe FTPS.

There is one other approach that can resolve the issue. Unlike ICQ, which had this same problem, FTP is an older protocol which has historically been quite popular. Many routers do support a feature called "FTP proxy". Basically, this causes the firewall to interfere more with the FTP communications, and change the data payload in a way that will cause the FTP connections to work.

So, those are your options.

Let me get into passive mode, since that was brought up. In some cases, using passive mode may fix some of the issues, or insufficiently partially fix the issues. In other cases, it may have no effect.

So the way FTP works (using "active mode" FTP), is that the FTP client creates a TCP connection to the FTP server (which is usually listening on TCP port 21). You may be able to log in, and see file listings. Then, when a user requests that the software transfer a file, the FTP server will tell the FTP client what TCP port the FTP client should listen to, and the FTP server will create a second TCP connection which usually involves TCP port 20.

With "passive mode" FTP, the FTP client creates a TCP connection to the FTP server (which is usually listening on TCP port 21). You may be able to log in, and see file listings. Then, when a user requests that the software transfer a file, the FTP server will tell the FTP client what TCP port the FTP server will listen to for a second TCP connection, and then the FTP client will create a second TCP connection which usually involves TCP port 20.

So, with passive mode, if the FTP client is behind a router, the problem may be largely circumvented. However, that will require that the FTP server is not behind an unproxied router that may changes addresses. If you have an FTP server that is not behind an unproxied router that may changes addresses, that one computer may be able to serve many FTP clients without issue. Therefore, many people tried using FTP passive mode and thought they trained themselves that "FTP passive mode" is some process that seems to magically fix these weird errors with FTP which allow viewing directory listings but not transferring files.

However, using passive mode simply shifts a responsibility from the client to the server. People using FTP clients and trying "passive mode" may have found that this "magical" fix worked on some FTP sites, but not others. Furthermore, when more people got interested in running FTP servers, they found that "FTP passive mode" didn't seem to fix things.

So, you can try the workaround of using passive mode, but realize that such a workaround just doesn't resolve all scenarios.

Some available documentation discussing this: OpenBSD pf: FTP.

So again, to recap the options:

• Can try passive mode. Won't fix all scenarios.
• Can enable FTP proxy. Will allow FTP to work, but doesn't fix critical privacy flaws (snoopable passwords, snoopable file data contents)
• Use other protocols:
  • SFTP (great choice, no drawbacks except whether software supports this great choice)
  • HTTPS (often used for manually-initiated file uploads, due to widespread bundled clients that support it)
  • SCP (resolves issues, but not likely to get future updates)
    • The comment about future updates is based on some documentation that was historically available at https://www.openssh.com/faq.html#2.10 but, at the moment I'm posting this answer, it seems that URL is returning a 404 and Archive.org is having technical issues. Maybe you'll have better luck viewing that at another time.
  • or maybe FTPS (essentially FTP with some support to add some security).