Tomato FTP change WAN port and allowing all IP addresses

Discussion in 'Tomato Firmware' started by Solace50, Jan 8, 2018.

  1. kille72

    kille72 LI Guru Member

    Would it be very difficult to implement sftp in tomato?
     
  2. Sean B.

    Sean B. LI Guru Member

    There's an sftp server package available via optware-ng in nslu2-linux.org's buildroot-armeabi section:

    Code:
    root@Storage:/tmp/home/root# ipkg info openssh-sftp-server
    Package: openssh-sftp-server
    Version: 7.5p1-1
    Depends: uclibc-opt, openssl, zlib
    Status: unknown ok not-installed
    Section: net
    Architecture: arm
    Maintainer: NSLU2 Linux <nslu2-linux@yahoogroups.com>
    MD5Sum: 8ea049f8eeed8ca9d0a1a65ab0f6ac86
    Size: 39279
    Filename: openssh-sftp-server_7.5p1-1_arm.ipk
    Source: http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-7.5p1.tar.gz
    Description: sftp-server only from a FREE version of the SSH protocol suite of network connectivity tools.
    
    root@Storage:/tmp/home/root#
    It probably wouldn't take too much to add it in. However, it's rather easy to just install via optware-ng and doesn't add to the firmware size that way.

    I'm home now, I'll get started making that patch and submit it with notes this evening.
     
    kille72 likes this.
  3. Sean B.

    Sean B. LI Guru Member

    @kille72

    Code:
     Patched against tomato-arm-kille72
     Author: Sean B. @ linksysinfo.org forum
     Date: Mon Feb  5 21:06:51 PST 2018
     Issue: FTP data connection fails from WAN side when port is not 21
    
         User Solace50 @ linksysinfo.org forums reported that when the FTP server was set to a port other than
     the default 21, he was able to connect and authenticate fine, but the directory listing would fail. FTP clients
     often set PASV ( passive ) mode upon connection. In passive mode, both the control connection and the data
     connection are initiated by the client, and in this case the data connection was not succeeding. Determined the
     below DNAT rule was the cause. When the FTP server is enabled, nat_ftp.ko module is loaded into the kernel. This
     is a netfilter/conntrack helper which monitors the FTP control connection for the specific communication of PASV
     mode being set, when set the server responds with a port for the client to initiate connection on. Nat_ftp then
     informs the kernel a connection attempt from the client IP to the specified port is to be considered RELATED and
     therfor allowed. The DNAT rule is not only unnecessary, but was also causing the module to fail in its ability
     to flag the incoming data connection from the client as RELATED, thus the connection was dropped. I believe this
     issue only arose when the port was other than 21 even though the DNAT rule exists anytime WAN FTP access is enabled
     is due to the nat_ftp module by default monitors port 21, and only lost track of the control connection when the DNAT
     rule altered the packets.
    
    diff --git a/release/src-rt-6.x.4708/router/rc/firewall.c b/release/src-rt-6.x.4708/router/rc/firewall.c
    index 3782929..df50c6c 100644
    --- a/release/src-rt-6.x.4708/router/rc/firewall.c
    +++ b/release/src-rt-6.x.4708/router/rc/firewall.c
    @@ -1164,13 +1164,6 @@ static void nat_table(void)
             }
     #endif
     
    -#ifdef TCONFIG_FTP    // !!TB - FTP Server
    -        if (nvram_match("ftp_enable", "1"))
    -        {    // FTP WAN access enabled
    -            ipt_write("-A WANPREROUTING -p tcp --dport %s -j DNAT --to-destination %s\n", nvram_safe_get("ftp_port"), lanaddr);
    -        }
    -#endif
    -
     #ifdef TCONFIG_BT
             //BT Client ports from WAN interface
             if (nvram_get_int( "bt_enable" ) && nvram_match( "bt_rpc_wan", "1"))
     
  4. kille72

    kille72 LI Guru Member

    Hmm...strange, it does not work. I removed lines 1167-1172 in firewall.c:

    https://bitbucket.org/kille72/tomat...&fileviewer=file-view-default#firewall.c-1167

    Code:
    # iptables -t nat --list-rules
    -P PREROUTING ACCEPT
    -P INPUT ACCEPT
    -P OUTPUT ACCEPT
    -P POSTROUTING ACCEPT
    -N WANPREROUTING
    -A PREROUTING -p udp -m udp --dport 1194 -j ACCEPT
    -A PREROUTING -d xxx.217.9.xxx/32 -j WANPREROUTING
    -A POSTROUTING -o vlan2 -j MASQUERADE
    -A POSTROUTING -s 192.168.1.0/24 -d 192.168.1.0/24 -o br0 -j SNAT --to-source 192.168.1.1
    -A WANPREROUTING -p icmp -j DNAT --to-destination 192.168.1.1
    -A WANPREROUTING -p tcp -m tcp --dport 50101 -j DNAT --to-destination 192.168.1.101
    -A WANPREROUTING -p udp -m udp --dport 50101 -j DNAT --to-destination 192.168.1.101
    Log from LAN (port 2121):
    Code:
    Feb  6 12:08:25 Asus ftp.info vsftpd[18018]: [test] OK LOGIN: Client "192.168.1.101"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "230 Login successful."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "SYST"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "215 UNIX Type: L8"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "PWD"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "257 "/" is the current directory"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "TYPE I"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "200 Switching to Binary mode."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "SIZE /"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "550 Could not get file size."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "CWD /"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "250 Directory successfully changed."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "PASV"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "227 Entering Passive Mode (192,168,1,1,230,164)."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP command: Client "192.168.1.101", "LIST -l"
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "150 Here comes the directory listing."
    Feb  6 12:08:25 Asus ftp.info vsftpd[18020]: [test] FTP response: Client "192.168.1.101", "226 Directory send OK."
    Log from WAN (port 2121):
    Code:
    Feb  6 12:10:30 Asus ftp.info vsftpd[18318]: [test] OK LOGIN: Client "xxx.185.85.xxx"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "230 Login successful."
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "SYST"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "215 UNIX Type: L8"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "PWD"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "257 "/" is the current directory"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "TYPE I"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "200 Switching to Binary mode."
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "SIZE /"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "550 Could not get file size."
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "CWD /"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "250 Directory successfully changed."
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP command: Client "xxx.185.85.xxx", "PASV"
    Feb  6 12:10:30 Asus ftp.info vsftpd[18320]: [test] FTP response: Client "xxx.185.85.xxx", "227 Entering Passive Mode (xxx,217,9,xxx,203,145)."
     
  5. kille72

    kille72 LI Guru Member

    Talked to Shibby, he used to solve passive mode like this:

    Vsftpd Custom Configuration:
    Code:
    pasv_enable=Yes
    pasv_min_port=10090
    pasv_max_port=10100
    Scripts-Firewall:
    Code:
    iptables -I INPUT -p tcp --dport 10090:10100 -j ACCEPT
     
  6. Sean B.

    Sean B. LI Guru Member

    Shouldn't need it, that's what nat_ftp module does. I'll take a further look tomorrow. I didn't run the build to verify, as short on time so was hoping you'd do that ;)
     
    kille72 likes this.
  7. kille72

    kille72 LI Guru Member

    Last edited: Feb 6, 2018
  8. kille72

    kille72 LI Guru Member

    @Sean B. explained by Shibby:

    there are two methods: either activate the passive mode and open the ports or load the nf_conntrack_ftp module with the parameter and the new port.

    Method 1:
    Vsftpd Custom Configuration:
    Code:
    pasv_enable=Yes
    pasv_min_port=10090
    pasv_max_port=10100
    Scripts-Firewall:
    Code:
    iptables -I INPUT -p tcp --dport 10090:10100 -j ACCEPT
    Method 2:
    we load a module with a new port (in my case I launched vsftpd on port 2121):
    Code:
    # rmmod nf_nat_ftp
    # rmmod nf_conntrack_ftp
    # modprobe nf_conntrack_ftp ports=2121
    # modprobe nf_nat_ftp
     
    Last edited: Feb 6, 2018
  9. Sean B.

    Sean B. LI Guru Member

    If you look at the code of nat_ftp, it's specifically meant to open the negotiated port in passive mode. But, you guys can handle the port opening however you like.
     
    kille72 likes this.
  10. kille72

    kille72 LI Guru Member

    Don't be angry, we have no good solution yet :confused: Come with constructive suggestions...
     
  11. kille72

    kille72 LI Guru Member

    I can confirm that we have a solution by Shibby that works, thanks! Comments, reflections, ideas?

    https://bitbucket.org/kille72/tomato-arm-kille72/commits/9eb3c467ecf041bcf16620aebdcecb9b1ccaa247

    Port 2121 from WAN:
    Code:
    Feb  6 17:22:35 Asus ftp.info vsftpd[3149]: [test] OK LOGIN: Client "xx.185.85.xx"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "230 Login successful."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "SYST"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "215 UNIX Type: L8"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "PWD"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "257 "/" is the current directory"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "TYPE I"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "200 Switching to Binary mode."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "SIZE /"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "550 Could not get file size."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "CWD /"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "250 Directory successfully changed."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "PASV"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "227 Entering Passive Mode (192,168,1,1,20,147)."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "LIST -l"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "150 Here comes the directory listing."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "226 Directory send OK."
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP command: Client "xx.185.85.xx", "QUIT"
    Feb  6 17:22:35 Asus ftp.info vsftpd[3151]: [test] FTP response: Client "xx.185.85.xx", "221 Goodbye."
     
    Last edited: Feb 6, 2018
  12. Sean B.

    Sean B. LI Guru Member

    Don't over analyze, I wasn't angry at all. I realize there are multiple avenues for ftp to open the data port, and you guys can use whichever you feel is best.
     
    kille72 likes this.
  13. Sean B.

    Sean B. LI Guru Member

    There are many differences between the builds thanks to multiwan, so there could very well be more I need to find. However, considering it functioned when you removed the rule manually, I must ask if you are possibly doing something different? If you are using a web browser to access ftp, did you clear the history/cache as to be sure it's not trying to us the same data port as your last connection? Nat helpers for FTP are still enabled? User "test" is active? Etc.
     
    kille72 likes this.
  14. kille72

    kille72 LI Guru Member

    I'll try it again when I have time.
     
  15. eibgrad

    eibgrad Network Guru Member

    Good job!!

    It's important to appreciate the contributions and efforts of others, so hats off to you. Again, nice work. Only wish Sean B. was here to enjoy it. I'd like to congratulate him as well. But as you probably know, I'm currently on the enemies list for some reason.

    And btw, no need to rush this into production. Remember, we have a nice workaround available in the meantime (you know, one of those temporary bandaids you use to stop the bleeding until you can fix the underlying problem).

    https://pastebin.com/cn7Bky6P

    Can't help but laugh at the thought of Shibby, the developer of all ppl!!, offering a *hack* as a workaround bandaid. Apparently he didn't get the memo on purity and elegance the rest of us were handed out.

    Oh, and this is even more ironic. You'll just love this. I was one of the first to be skeptical about MultiWAN knowing how much of the source code would have to be changed, and the inevitable breakage that would be sure to follow.

    http://www.linksysinfo.org/index.php?threads/tomato-multiwan.71978/#post-269258

    Funny though, I don't recall many other ppl making similar objections, considering all the time, trouble, and risks in making even relatively minor changes to the source code. Apparently Shibby missed that memo too, and decided to dive in, head first. Seems most ppl just kept their mouth shut and went along w/ the program, while others (myself included) were so appalled, we refused to move to MultiWAN for YEARS! It was always my belief there should be *two* paths, MultiWAN and non MultiWAN, at least until the former had proven itself. But hey, what do I know, I'm just a chump on a forum!

    So much, so much irony.

    Anyway, that's what we do around here. We all work together, cooperate, and solve problems. End users providing workarounds, developers providing long term fixes. It's a beautiful thing (most of the time).

    Once again, congrats!

    P.S. And if you do happen to hear from Sean B. one of these days, be sure to pass along my congratulations for his efforts and a job well done.
     
    Last edited: Feb 6, 2018
    kille72 and pomidor1 like this.
  16. kille72

    kille72 LI Guru Member

    Deleted
     
    Last edited: Feb 6, 2018
  17. kille72

    kille72 LI Guru Member

    Sorry, tested again and it works with your fix!

    We have 3 different solutions to the problem, which should we take and why?

    1. https://pastebin.com/cn7Bky6P
    2. https://bitbucket.org/kille72/tomato-arm-kille72/commits/9eb3c467ecf041bcf16620aebdcecb9b1ccaa247
    3. https://www.linksysinfo.org/index.p...ing-all-ip-addresses.73970/page-2#post-294058

    @Sean B. and @eibgrad, are you ready to discuss constructively without personal attacks and irony???

    PS. Ad.3: When you restart router with FTP on, it will work. If you change the port without restarting, it will not work. nf_conntrack_ftp does not have the correct port number.
     
    Last edited: Feb 6, 2018
  18. Sean B.

    Sean B. LI Guru Member

    F
    I don't really advocate one method over the other. My issue was taken with overlapping a cheat fix ( I say cheat in regards to rewriting packets to get them around whatever has failed ) rather than figuring out what broke to begin with, as it was clear this hasn't been the way it's always operated.
     
    Last edited: Feb 7, 2018
  19. Sean B.

    Sean B. LI Guru Member

    This can be fixed with a couple lines of code. Code would be my only point to make for using the original functionality of nat_ftp. You see how little change to the code is required to fix it as my patch shows, and this part can be fixed by adding even less. No change to how users have interacted with FTP in the GUI or otherwise. However Shibby, as knowledgeable and experienced as he is, prefers a different path than I would choose when it comes to features and their implementation ( such as MultiWAN ), hence while I respect his firmware and it's accomplishments very much, I still run Toastman as the base for my builds. So it's really up to whatever you guys wanna do. My goal was to figure out the root cause of what happened, so it doesn't become another burried unknown issue to cause problems later as many things have done in Tomatos code.
     
    Last edited: Feb 7, 2018
  20. koitsu

    koitsu Network Guru Member

    Heh. I pontificated on replying to this thread for about 24 hours. I'll probably regret this, but...

    Before you guys change anything, you need to ensure that everything still works after the change.

    In fact, I would urge folks to test this before any change is made, and document what is actually seen (payload/protocol-wise) presently. I have a gut feeling some of the below scenarios don't actually work at present, but making note of the behaviour prior to change is important.

    So let's talk about the FTP protocol and its two transfer mode: passive and active. Passive tends to be the default in most FTP clients today, but not always. Good FTP clients let you switch between the two (because it's entirely client-controlled); bad ones don't.

    Passive mode is NAT-friendly because the PASV command results in the FTP server itself opening up a listening socket on a random (ephemeral) TCP port, then tells the client what that IP+port is, and the client connects to it for data transfer.

    Active mode is different and not NAT-friendly: the client opens a listening socket on a random (ephemeral) TCP port and sends to the server its IP+port in the PORT command, which the FTP server itself connects to from TCP source port 20 (yes, you heard me right) and data transfer begins.

    A directory listing is a sufficient test; LIST is effectively a file transfer.

    Kernel module nf_conntrack_ftp is what allows for conntrack-based iptables rules to keep track of what's talking to what (I believe through the state module (ex. iptables -m state), but I'm not entirely sure). This module also supports use of a ports argument (ex. modprobe nf_conntrack_ftp ports=21,1234) which tells the module what port numbers to compare against/look for when being utilised -- otherwise the default is ports=21.

    Kernel module nf_nat_ftp does rewriting of TCP payload for FTP traffic (specifically PORT, PASV, EPRT, and EPSV commands) so that the WAN IP and associated WAN port are used, not the client LAN IP and client LAN port. (If you don't understand how NAT works, you shouldn't be participating in this discussion :) )

    For whatever reason, understanding the nuances of the FTP protocol have been lost. In the 90s, most of us knew how this worked because FTP was so commonplace. We senior SAs (esp. those who worked at ISPs) tend to remember this stuff. An excellent reminder resource is here: http://slacksite.com/other/ftp.html -- I cannot stress the importance of *reading* this slowly. There are nuances/complexities with passive mode on the server side that don't apply in active mode. Once you understand the protocol and see some of the control payload/commands, you'll understand.

    As for the Linux kernel module side of things, you can read about that here (though this is kind of lacking, IMO, and it's also for Shorewall-specific devices not Linux generally): http://shorewall.org/FTP.html

    So, you guys have 4 scenarios to ensure work properly with whatever you change:

    1. Internet client connecting to FTP server running on router itself; client using active mode
    2. Internet client connecting to FTP server running on router itself; client using passive mode
    3. LAN client connecting to Internet FTP server; client using active mode
    4. LAN client connecting to Internet FTP server; client using passive mode

    You may also want to test this (more on that in a moment):

    * LAN client connecting to LAN IP of FTP server (router); client using active mode
    * LAN client connecting to LAN IP of FTP server (router); client using passive mode
    * LAN client connecting to WAN IP of FTP server (router); client using active mode
    * LAN client connecting to WAN IP of FTP server (router); client using passive mode

    You're going to need FTP clients and servers which offer debug logging, or get very familiar with using tcpdump and looking at payloads (Wireshark makes this easy; you won't like having to manually decode the LSB and MSB byte ordering of the port numbers with tcpdump -X, trust me). You're also going to need to keep an eye on firewall state tables and/or rules, because you don't want the wrong thing being opened up that might cause a security problem.

    I suggest doing the #1 and #2 tests from a machine that is not behind NAT/router (i.e. a machine somewhere on the Internet with a direct public IPv4 address). It makes things easier, trust me.

    Ubuntu Linux and FreeBSD's ftp client can toggle passive/active mode using the "passive" command. Ubuntu Linux ftp client defaults to active. FreeBSD ftp client defaults to passive but has a weird "automatic fallback" mode which makes troubleshooting annoying (and not to mention, probably doesn't handle all scenarios properly), so on FreeBSD use ftp -A for active, and just ftp for passive (since the -p argument is deprecated): fom FreeBSD's ftp(1) man page:

    Code:
         -A          Force active mode ftp.  By default, ftp will try to use pas‐
                     sive mode ftp and fall back to active mode if passive is not
                     supported by the server.  This option causes ftp to always
                     use an active connection.  It is only useful for connecting
                     to very old servers that do not implement passive mode prop‐
                     erly.
    
         -p          Enable passive mode operation for use behind connection fil‐
                     tering firewalls.  This option has been deprecated as ftp now
                     tries to use passive mode by default, falling back to active
                     mode if the server does not support passive connections.
    
    You might also be able to use curl, if it's compiled with FTP support. curl will use active mode by default, and curl --ftp-pasv will use passive mode. However, according to the man page, it may end up sending commands (like LPRT) which I don't know if said Linux modules will properly translate/use (I'm not even sure what LPRT does, but it's IPv4-specific). See curl man page, search for pasv and read.

    The EPRT and EPSV commands allow for active and passive functionality with either IPv4 or IPv6. So you may have to test that too. Everyone here knows how I feel about IPv6 though. *smirk* I don't know if IPv6 FTP even works with TomatoUSB as-is, so if it doesn't, I suggest ignoring that for now / fix it sometime later.

    General advice from someone who ran a co-located hosting service for nearly 20 years: running an FTP server can be complicated, and due to the nature of the protocol and port allocation models, is generally best-suited for a dedicated box (this can be done with TCP port forwards if the FTP server is behind NAT as well; it requires specific tuning of the FTP server/daemon for its ephemeral port range (not the system itself, just the daemon)). Running an FTP server on the same router that could handle NAT'd FTP client connections to Internet FTP servers sounds like an accident waiting to happen. There's also the issue of an FTP connection from a LAN client to the LAN IP of the router/FTP server (you better hope your firewall rules are written correctly otherwise you'll end up with payload rewriting that shouldn't happen, resulting in NAT loopback use or timeouts/failures). Caveat emptor! My strong opinion is to not run an FTP server on a router that is also doing NAT. I've always felt (personally) that the FTP server feature should never have been added to TomatoUSB -- instead just run the FTP server on a box on the LAN somewhere + add appropriate daemon bits + port forwards + you're good.

    Good luck.

    Footnote: FTP's complexity is often why network administrators prefer SFTP (not FTP over SSL! Rather SSH's subsystem called SFTP which allows for FTP-like functionality via SSH, but requires the OpenSSL sftp-server binary on Tomato, ex. /usr/libexec/sftp-server), because all they have to deal with is a single destination port: TCP port 22. But SFTP is dangerous because you usually cannot get fine-grained control within the SSH server itself to define what accounts are SFTP-only vs. SSH-only vs. both (this is one reason why sysadmins sometimes dislike SFTP). Think about the ramifications of this being used on a router that also provides root-level SSH. WAN? Bad, bad, bad idea. LAN? Much more acceptable, but depends on environment.
     
    Last edited: Feb 7, 2018
    pedro311, kille72, Sean B. and 2 others like this.
  21. eibgrad

    eibgrad Network Guru Member

    @koitsu, although this doesn't directly affect the fix (I'm sure a fix will proceed), doesn't it make a lot more sense, from a user perspective, to limit your remote FTP access via a VPN?

    You avoid the problem of exposing another port on the server. A port that you'll probably want to obscure anyway, which means ftp clients won't work by default. You get strong security/authentication. You're not transferring files in the clear. You can reference the FTP server from the LAN side. And you avoid all the issues involving active vs. passive, firewalls, etc. Yeah, I know the VPN is more of a hassle to setup, but once you do, you can use it for everything.

    So I agree w/ you that having the FTP server on the router is bit risky, but seems to me a happy middle of the road is to restrict it to LAN use, and if you must access remotely, use a VPN.

    Again (because you have to make it oh so clear in this thread), I'm NOT talking about how to fix the FTP server. Fix it! Nor redesigning it. Leave it alone! I'm talking only from an end-user perspective, in terms of best practices.

    P.S. I thought you had gone for good, nice to see you back!
     
    pedro311, kille72 and koitsu like this.
  22. koitsu

    koitsu Network Guru Member

    @eibgrad Yep, a VPN would be fine and ensure several aspects of security; your listed benefits and problems one can avoid are correct.

    However, everyone's use-cases are different, and for some people the data they transfer is acceptable to be in plaintext over the Internet. I have zero problem with plaintext protocol usage (which FTP is), especially because troubleshooting them is a lot easier. FTP's design (port-wise) makes things complicated in general though.

    Regarding VPNs, there are two problems: 1) setting up the router to be a VPN server (OpenVPN makes this easier, duh, but this forum is still plagued regularly by people asking about it + running into problems) and 2) throughput is substantially worse due to the CPU/encryption overhead on the router. In my experience, #2 is a huge turn off for a lot of people.

    So, a matter of opinion: if I had to choose between (a) running an FTP server on my LAN (on a VM, bare metal, natively on some Windows box I leave running 24x7, whatever) and set up static port forwards in the router, (b) running the FTP server natively on the router, or (c) using a VPN, I would choose (a) the majority of the time (assuming plaintext transfer was acceptable). But I'm also biased because I've decades of experience with the FTP protocol + running a public FTP server. :)

    P.S. I'm not really back, I'm just wasting 24-48 hours before continuing to apply for full-time work. You shouldn't expect to see me around past Wed or Thu this week at the latest.
     
    pedro311, kille72 and eibgrad like this.
  23. eibgrad

    eibgrad Network Guru Member

    :( bad for us, good for you I suppose. Every time you post, I seem to learn something new. It's amazing (latest pickup, xxd). Good luck in your job hunt.
     
    kille72 likes this.
  24. Sean B.

    Sean B. LI Guru Member

    Koitsu, good to see one of your detailed posts again. Hope you've been well.
     
    kille72 likes this.
  25. Sean B.

    Sean B. LI Guru Member

    @kille72 , let me know if I can be of any further assistance with whichever path forward you so choose.
     
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice