Problem with VSFTPD - Allowed Remote Address(es) Field

Discussion in 'Tomato Firmware' started by arafey, Aug 1, 2012.

  1. arafey

    arafey Addicted to LI Member

    Hello all,

    I have an issue with vsftpd involving restricting remote ftp connections. I specified a URL corresponding to the IP address of a remote laptop with a DDNS client installed in the Allowed Remote Address(es) field in the FTP Server page of the GUI ( I want lan connections to be allowed as well as remote connections originating from just that URL/Dynamic IP. This actually works until the IP address changes (ie. the DDNS client updates the IP). After that point, all remote requests time out. The only way I've been able to fix this is by pressing Save on the FTP Server page. However, next time the IP changes, I run into the same issue.

    I don't have any support for this, but I think that vsftpd resolves the IP address of the URL as soon as it's started (right after I press Save) and doesn't refresh it unless I restart it again via the Save button.

    Any and all help is appreciated,
    thanks in advance

    PS: I'm running Shibby's MIPSR1-097 K26 USB Tor-VPN build on a WL-500gP
  2. arafey

    arafey Addicted to LI Member

    Help! Please?
  3. koitsu

    koitsu Network Guru Member

    The problem is exactly what you describe -- DNS resolution is done at the time the URL is entered (based on your description), not every time a client connects. I don't see any indication of where to "allow connections from a specific FQDN/host" in vsftpd's configuration file documentation, so I don't know how Shibby firmware is doing this.

    Is it done via iptables? If so, then yes, DNS resolution is done immediately when the iptables rule is added (and it has to be -- you do not want a kernel-level firewall doing DNS! The implications are horrible on so many levels that I do not even want to get into it). There is no way around this, and this kind of problem affects all sorts of services/etc. on the Internet as a whole (not just limited to vsftpd and/or Tomato).

    Your choices as I see them:

    1. Do not apply any IP-level access rules to vsftpd. Meaning, your FTP server will be open to the world. Rely entirely 100% on username/password authentication. It will be your responsibility to look at the vsftpd log to see if people are connecting and trying to brute-force logins/passwords. Often running the FTP server on a non-standard port (something other than 21) greatly diminishes this, but it doesn't stop someone from port scanning you and finding you're running an FTP server on, say, port 1234.

    2. Add iptables rules that permit access to the FTP server from netblocks that the person uses. E.g. if resolves to one day, then add as an allowable netblock (you should check with to see what the "correct" netblock size is, or otherwise use to assist in this). If the person's IP address changes to, say,, then you will need to add a new rule (NOT REPLACE THE EXISTING RULE) that allows and so on. Initially the user may have problems connecting, but as time goes on you'll end up with a good set of iptables rules that correlate with the netblocks his ISP has. Welcome to system and network administration -- this is how it is done.

    3. Have the user get a static IP from his ISP.
  4. arafey

    arafey Addicted to LI Member

    Thanks for the reply! I actually did something differently which works for now but isn't ideal. I have a cron job that executes "service dnsmasq restart ; service firewall restart" every 30 minutes. This flushes the DNS cache and then reloads iptables which, as you predicted, stores the rules. If I enable logging of DNS queries and replies, I see that whenever the cron job runs, the IP of the allowed domain is retrieved.

    My question now is, is it possible to make this only run if there is a blocked connection attempt on port 21? (ie. when the following occurs:
    DROP IN=ppp0 blablabla DPT=21)

    EDIT: Actually this would work even better. (How) can I adapt that python script for tomato? Thanks again
  5. koitsu

    koitsu Network Guru Member

    Restarting the entire firewall may severe any existing TCP sessions going through the router at the time. A cronjob doing this kind of thing is very, very dangerous. I would strongly recommend against it in the long-term. Restarting the entire firewall has repercussions and the fact that people are even doing it without knowing those repercussions indicate they don't know what all goes on under the hood within Linux's firewall stack. That's disappointing.

    If you're going to use a cronjob to re-apply the iptables rule that lets the dynamic IP client through, there is no reason to reload the entire firewall. You can use iptables -R to replace an existing rule. This will result in DNS being re-resolved for the FQDN you specify in the iptables rule and you don't have to reload the entire firewall. Doing it this way makes a hell of a lot more sense.

    As for that python script -- that guy is also an idiot (re: reloading the entire firewall). :) Use iptables -R to replace the existing rule with the same rule, where DNS will be done at the time the replacement is inserted. Seems simple enough to me, and you don't need python to do this (python people have this horrible habit of doing everything in python which can be done in shell scripts).
  6. arafey

    arafey Addicted to LI Member

    Ah, see I didn't really know the downsides of restarting the firewall. I figured it may terminate connections but hadn't noticed anything even though it was running so often. I got rid of the cron job that reloaded dnsmasq and the firewall. Now I have a cron job pointing to, which executes the following every 10 minutes:

    iptables -R INPUT 10 -p tcp -s --dport 21 -j ACCEPT
    I also disabled the dnsmasq cache so that the script would definitely prompt a DNS query. Is there anything wrong with that? There isn't a noticeable performance hit. I wish it was possible to change the TTL for my domain, unfortunately that feature isn't free.
  7. koitsu

    koitsu Network Guru Member

    Do not disable the dnsmasq cache. Let me explain why effectively that is doing nothing other than wasting your bandwidth and impacting your performance:

    Effectively what you've done is forward any DNS traffic hitting dnsmasq to your ISP's DNS servers (or whichever DNS servers you have configured to be used in TomatoUSB) for every single query. What you didn't think about, obviously, was the fact that your ISPs DNS servers are almost certainly honouring the TTL of the record by DynDNS. So effectively this accomplishes nothing, because what you've done assumes your ISPs DNS servers don't do any kind of caching as well. Bad assumption. Leave dnsmasq alone.

    Instead, explain to your friend/customer/whatever that they should use a different dynamic DNS provider that lets you set the TTL. A great, and free, example service is Please do not set the TTL to something utterly stupid like 0 (that will break more DNS resolvers than you can possibly imagine, including enterprise-grade devices like BlueCoat caching proxies), or 1 (this is incredibly rude and defeats the point of DNS entirely). Set it to something like 300 or maybe 180 -- please be reasonable.
  8. arafey

    arafey Addicted to LI Member

    I actually do use The TTL is set to 3600 and can't be changed unless you pay for a premium account. I may give it a shot, or just deal with the delay, but it would've been nice if it worked. Also, with the cache disabled, it would update the IP even if it was less than 1 hour. I wonder if there was a more elegant solution, because the delay in updating the IP causes downtime, which I would like to avoid.

    Edit: Actually it turns out switches the TTL to 60 seconds automatically if it's a dynamic IP, so it looks like problem solved and I can re-enable the dnsmasq cache. I appreciate the help, koitsu. I have much to learn about network administration so thanks for bearing with me.
  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