I am working on setting up my company’s OpenSUSE 13.2 webserver as the “gateway” for an internal FTP server via the firewall’s masquerading service (configured through YaST). External zone configured (FTP ports allowed), IPv4 forwarding is enabled on the NIC, masquerading translates <public ip : 21> to <private ip : 21>, external clients can connect to the FTP server (welcome message received, user authentication succeeds), but as soon as the PASV command is sent and the client wants to list the contents, the connection timeouts and breaks.
I’ve noticed that after the PASV command the reply packet contains the private (internal) IP address of the FTP server, and I am certain that this is the source of the problem, however, I can’t seem to find the reason for it. My primary theory is obviously a malfunctioning masquerading/NAT configuration, however, I don’t suppose that the connection could even build up to the point that user authentication succeeds on the internal FTP server from an external source, and it breaks only after that. I’ve also tried masquerading packets sent to <public ip : port 20> to <private ip : port 20>, no change, though.
Seems to be no problem present with the FTP server itself, as it works perfectly in our LAN, as part of an IP camera recording system, while it’s also accessible from any workstation.
Also, although it would be an obvious solution, it is not possible to separate the FTP server - or replace the webserver gateway - with a router that could solve the whole problem with a static PAT configuration, as the FTP server is a single-NIC machine, it must remain connected to the internal network as part of an IP camera recording system, and we don’t necessarily want to spend extra money for a router that can replace our well-working, dual-gigabit-NIC webserver gateway that otherwise has no problem at all in terms of working as a gateway for our internal network. I wouldn’t be posting this thread, either, if that solution would be available.
Harsh network schematic:
[Internet] = [OpenSUSE 13.2 webserver (gateway)] = [FTP server in the LAN]
If you have any idea on what might cause the problem we’d be glad to hear it.
If I understand your situation correctly, you are describing using openSUSE 13.2 on a completely separate box than your running FTP server app. This is important for what may or may not be possible unless you install something special like a Proxy firewall which terminates the client connection at the firewall and creates a completely new connection to the Service which can run anywhere including another machine behind the FW.
I haven’t checked this in recent years,
If you go back a few years, it was extraordinarily difficult to configure non-Host firewalls to pass PASV FTP because of its nature… that the data port is chosen randomly from a defined range instead of a single port. I don’t know if that issue still exists with modern IPv2. “Statefull inspection” firewalls (which IPv2 now implements) tracks ports which are being used so you might not be able to simply open up a range of ports for the data port.
If the problem is still insurmountable, then you’ll need to just specify that all clients should use Active FTP (which uses a single defined port for data).
In any case, although unrelated to your FW issue if you are running a supported FTP app to use the YAST FTP applet to manage your FTP server unless you’re doing something fancy.
My internal FTP server is running on another machine, separately from the OpenSUSE 13.2 gateway/firewall. I’ve already tried setting the FTP server’s “passive reply” IP, but in that case the LAN clients cannot connect to it, and it doesn’t solve the external connection issue, either.
I’ve also checked the FTP server’s accessibility from external networks by configuring a small D-link SOHO router as the gateway/firewall and testing in a completely separated mini-network, not connected to the LAN or the Internet, in the following way:
“External” network] - [SOHO router gateway/firewall with the similar masquerading/port forwarding settings* as the “real thing”] - “Internal” FTP server]
*FTP requests forwarded to the server, service allowed to pass through the firewall.
In this scenario the FTP server had no problem regarding communicating and data transfer with internal AND external clients either, so I still believe that the problem is not present because of the settings on the FTP server, but the masquerading/address translation of the OpenSUSE gateway machine.
There’s nothing fancy either in terms of settings on the FTP server, just a minimalistic FTP configuration with a few users for authentication, never had any problem similar to this whatsoever.
My first question might be why PASV is so important to you. It wouldn’t be any improvement over Active FTP unless you’re talking about extremely heavy simultaneous loads, typically hundreds or more. If you wouldn’t have more than tens of simultaneous connections, then it probably makes more sense for most to just configure Active FTP.
Nowadays, most FTP clients can be configured either way, and web browsers typically are configured to try Active FTP before optionally trying PASV (if at all).
You can try a number of configurations posted using a Google search with keywords “iptables allow pasv ftp”
I strongly recommend using only configurations posted after 2013 (might include 2013) to exclude older IPv1.
Note also that all configurations you likely are going to see will open up all ports greater than 1024 which is pretty sad. If you’re going to open up ports willy-nilly, at least try to specify a smaller range (would require configuring first your FTP server and then matching the port range with your FW settings).
One other suggestion…
If you really are going to need to support that kind of heavy traffic then you may want to re-tune your machine(s) to re-allocate more resources to your networking. I described how to do this for a much earlier version of openSUSE but should still apply to current versions https://sites.google.com/site/4techsecrets/optimize-and-fix-your-network-connection