Windows Server 2012 R2 with three network interfaces; two on public networks, and the third is a private non-routable 192.168.x.x network. Routing & Remote Access enabled so that machine is acting as a router, and NAT is enabled on the two public interfaces so that clients from the non-routable third network can access services on the public networks.
Windows Firewall is enabled, and the network profiles are logical: The two public network interface connections are running with the Public network profile, and the private network interface connection is assigned the Private network profile. It's a non-Domain-joined server, and all the Windows Firewall settings are default. (e.g. Drop inbound connections by default, etc.)
All of that is working great; private network clients can access standard services like HTTP from the public networks, but also successfully access non-standard services for which no Windows Firewall rule exists at all (e.g. third-party instant messaging servers, non-POP/IMAP mail systems, etc.).
Everything except FTP. To be clear, there is NO FTP SERVER on the Windows Server 2012 R2 machine. We're talking about FTP traffic being able to pass through RAS and NAT to the public networks, not "how do I access an FTP service running on the Windows Server machine."
If a client on the private network tries to initiate a port 21 connection to an FTP server out on the public networks, the TCP SYN never makes it any further than the private network interface of the Windows Server 2012 R2 machine. Meaning if I let Wireshark capture traffic across all three network interfaces, the TCP SYN for the remote port 21 is shown as arriving on the private network interface, but is never repeated/forwarded on one of the public interfaces (post-NAT). So we're not even talking anything complicated yet like SSL or trying to enter passive/active mode; we're not getting past the initial TCP SYN for port 21.
And I would say "well, I must need to NETSH ROUTING IP NAT ADD FTP or something like that, because the NAT doesn't seem to want to handle passing through FTP client traffic." (Which I've tried, and it does not make a difference.)
But all I actually have to do to make FTP clients work is turn off Windows Firewall for the private network interface. (i.e. Exclude the private network interface from the Private network profile in Windows Firewall.) Then the TCP SYN for port 21, and everything else the FTP client does will work, and passes through NAT just fine. Turn the Windows Firewall back on for the private network interface, and FTP is blocked for the private network clients again.
And I would say "well, I must need to add port 21 & port 20 rules to the Windows Firewall, because the Windows Firewall is blocking this communication." I can create an inbound port 21 & port 20 rule for the Private network profile in Windows Firewall just fine, allowing "inbound" traffic "to port 21" for all/any programs and all/any addresses.
But defining such a rule seems to have no effect on the FTP traffic trying topass through this Windows Server router & NAT, meaning I still see the TCP SYN for port 21 still never makes it beyond arriving at the private network interface. Allowing "Edge Traversal" seems like a potentially relevant concept, but enabling that in the rule did not help either.
So what will allow FTP traffic from clients on the private network to route and pass out through NAT, without having to completely disable Windows Firewall on the private network interface? Presumably if I had an FTP service on the Windows Server itself, these firewall rules would make sense and would allow access to the Windows Server service. But what about Windows Firewall is blocking FTP traffic that would simply be routed, and isn't for a local port / program / address?