You're right - it was luck.

In reviewing the files that came in overnight, about 50% of the ones from the cheap camera were 0KB, the others were fine. After reading your message, I opened up ports 20 and 21 on the incoming firewall (allowed incoming connections) at the remote site, and switched the cheap camera to active FTP. The 'good' cameras don't have an option for passive or active. I tried active mode yesterday without any success, as I think the iptables rules were getting in the way.

So far so good - files are coming through fine. There's nothing at the remote site that would otherwise respond to any FTP traffic, so I think I'm safe leaving the connections allowed.

Thank you!

The -nvLswitch does not start the firewall, it lists it (or at least the filter table). "iptables -nvL FORWARD" just lists the forward chain. "iptables -w" is the same as $IPTABLES, more or less. In reality it seems to call ip6tables first then if that fails, it falls back to calling iptables. The -w switch is because of a change in how the rules are applied and is needed when adding rules in bulk from a script but not listing them. Google "man iptables" for more info on the various.

FTP works in 2 ways, passive mode (PASV) and active. It looks like your cameras are working in different ways, with your branded ones using active and the no-name one using passive (I think). Have a look at their config pages. You may be able to change the mode. I struggle with the two modes but here are a couple of links: link 1 and link 2. The problem with the two links is they don't cover sending files to the ftp server. You may have also got lucky because I don't see how the response from port 20 from the server will have got back to the client in active mode, but perhaps it did not have to and could be ignored.

Thanks kindly for the response. I experimented with your suggestions and have learned the following:

1) The 'cheap' camera requires a range of open ports to send data via passive FTP. The name-brand ones will work fine with 20 & 21 open, but the off-brand one will not. Result is a 0KB file being uploaded. So, I've defined the desired passive range in ProFTPD and created a firewall rule to allow the cameras an outbound path within that range.

2) There's still an issue with $IPTABLES vs iptables. I'm not exceptionally skilled in the ways of the firewall - which is why I had to ask for help - but I'll report my observations below.

My custom firewall rules are fairly straightforward:
Two rules to block LAN-to-LAN traffic and then a handful of rules that follow, all primarily designed to block a particular device or range of devices from directly accessing the Internet.
Where required, each DROP rule is followed by an ACCEPT rule to permit SMTP, FTP, NTP traffic, etc. In short, I don't want my NAS or camera system getting out to the Internet, but I do want to get an e-mail alert if a drive fails, as well as the ability to send the odd .jpg photo via FTP.

In trying to see where the problem lies, I tried every combination of switches with both $IPTABLES and iptables I could think of with the following results:
iptables -I FORWARD success
iptables -nvL FORWARD firewall failed to restart
iptables -nvL -I FORWARD firewall failed to restart
iptables -w -I FORWARD client reports unknown error; 0KB file saved on FTP server
iptables -w FORWARD firewall failed to restart
iptables -nvwL FORWARD firewall failed to restart

$IPTABLES -nvL FORWARD client reports unknown error; 0KB file saved on FTP server
$IPTABLES -nvL -I FORWARD firewall failed to restart
$IPTABLES -w -I FORWARD firewall failed to restart
$IPTABLES -w FORWARD firewall failed to restart
$IPTABLES -nvwL FORWARD firewall failed to restart

Finally, I noticed that the first two rules in my firewall

$IPTABLES -I FORWARD -i ens1 -o ens2 -j DROP

$IPTABLES -I FORWARD -i ens2 -o ens1 -j DROP

need to have the dollar sign, otherwise the firewall doesn't start.

So, $IPTABLES on the LAN-to-LAN block, and iptables on all of the other rules.

I'm going to assume that this is indeed a bug, and will report it as such.

Thanks again Nick - I appreciate the help!

Bill

That sounds like a bug in the iptables implementation. With the old and new format of the rules, can you do an "iptables -nvL FORWARD" to compare. All "$IPTABLES" contains is "/sbin/iptables -w". I've found that leaving out the -w, as you have done, can apply the rules twice.

[edit]
That's wrong! $IPTABLES contains "/sbin/ip6tables -w" which first seems to try to apply ipv6 rules and, failing that applies them as ipv4. If it works by calling iptables directly then please can you report a bug. You will probably have to do a before and after "iptables -nvL FORWARD" as a comparison. Can I also suggest you add the -w switch? I have found that, without the -w switch, rules can get applied twice.

I've tried your first rules in a VM and they appear to apply correctly.
[/edit]

Probably poor form to answer your own question on here, but I'll post it just in case someone else is running into the issue.

I found that the problem was with " $IPTABLES ". If I removed that, and replaced it with the normal " iptables ", then the files came through without issue. So, get rid of the dollar sign, switch to lower-case, all good.

I'm not sure why 2 of the 3 cameras worked in the first place, and this one particular camera didn't.

I also cleaned up the two FTP allow rules and put one in with a port range:

--dport 20:21 -j ACCEPT