Ah, man I'm tired now. I've spent the whole day looking this one over, researching and trying different things and I am still stuck on this:
The reply from the FTP server 227 Entering Passive Mode (192,170,1,1,19,41)., which contains the Data port range info for the client to connect on just doesn't appear to be getting to the client machine (Wireshark logs in the previous post hint at that as there is just nothing in the Client after the PASV command is issued). This is totally weird - it's like the whole TCP conversation just ends after the server sends the reply to the client.
The client never even attempts to connect to the Data port as it never receives the 227 Entering Passive Mode (192,170,1,1,19,41). response from the server telling it which ports to connect on.
I took a close look at the Hardware Firewall System Logs and this is what I see when a client FTP session fails at the PASV command:-
May 27 16:38:19 kernel: conntrack_ftp: ip mismatch: 192,170,1,1 != 192.168.1.*
May 27 16:38:26 last message repeated 5 time(s)
May 27 16:38:26 kernel: conntrack_ftp: ip mismatch: 192,170,1,1 != 192.168.1.*
May 27 16:38:35 last message repeated 1 time(s)
I've obfuscated the last octet in the IP addresses with *'s for posting here (probably not worth doing but hey) I did a little Googling on the conntrack_ftp bit and some of it looked worriesome - these messages might indicate that my return message packet is getting silently dropped by the firewall (perhaps???) due to some obscure error. I am unsure though as I don't know much about the Linux kernel that runs in the Snapgear firewall.
I've double checked the Data Port ranges in both the IIS settings and in the Hardware Firewall Filters and NAT rules and they are identical (I used 4900-4910 as per your (Steve's) blog post).