FTP problems on Core 155 - ALG FTP remove responsible?

Networking
1

Hi,

Since upgrading to core 155 we have timeout problems when clients connecting to our FTP server.
The FTP server is connected to a public address (running on proftpd).

ftp-connectiosn from inside our office works (listing is immediately) but when establishing a connection from outside our office just trying a listing it takes forever and then the server spits out:

Data connection to xxx.xxx.xxx.xxx:57575 timed out.
Falling back to PORT instead of PASV mode.

I tried several things, like:

  • proftpd: Using passive mode
  • proftpd: disabled DNS lookup etc.
  • Added passive ports to ipfire’s iptables with command:
    iptables -A INPUT -p tcp -m tcp --dport 49152:65534 -j ACCEPT
  • Port forwarding to internal ftp-server

No change…I even installed a second proftpd server with a different Linux distro but same timeout error.

So I wonder if it’s not the remove of ALG for FTP, SIP on the latest 155 which is causing the issue ?

Thank you for your clarification and a possible solution

2

I had many problems with 155, so I had to downgrade to 154.

3

Which problems did you have?

4

I consider also to downgrade to v154 since our main ftp-server has timeout errors and it’s impossible to transfer data.
Is there an easy way to downgrade ?

5

Problems because of not being able to choose to use FTP, H.323, IRC, PPTP, SIP, TFTP Application Layer Gateways. Not everything is up to me, if my suppliers/work use them I also need to use until they don’t.

6

Do you surely know, that you need ALGs?
Or doesn’t your IPFire config not really allow servers on your LAN ( GREEN and ORANGE! ) ?

7

Right! the option to choose ALG should be there with descriptive warnings…
I’m really annoyed about this…haven’t found a solution yet for the timeouts of our ftp-server!

8

Yes, I know

9

I downgraded to v154 and our FTP-server works again…no timeout etc.
Our main ftp-server is on Orange with Public IP-address…
I only enabled FTP on the “Application Layer Gateways”, all others are OFF.
Hopefully there will be a fix to let people choose or I really need to find another solution…

10

You must find another solution, because ALGs are insecure!

3 Likes
11

As I said, we live in a real world where not everything is up to us as individuals, if our suppliers/work use them we also need to use until they don’t.

12

@bbitsch is right - as @ms - as @pmueller - …

PLEASE, @ all blaming IPFire:

  • disclose your exact type of ISP connection
  • esp. “DS Lite” being involved is a must to mention honestly.
2 Likes
13

OK thanks…will try to setup an SFTP-server ASAP.

1 Like
14

after Update from 154 to 155 i can´t use ftp (passive) to a ftp-server from our vendor anymore. I have only a few firewall rules to go outside (80,443, 21) and the rest is forbidden.

In the firewall logs i can see (rule-log enabled):
09:24:20 FORWARDFW green0 TCP 192.168.0.5 63688 801.461.x.x 21(FTP)
09:24:21 DROP_FORWARD green0 TCP 192.168.0.5 63689 801.461.x.x 21314
09:24:22 DROP_FORWARD green0 TCP 192.168.0.5 63689 801.461.x.x 21314

When i enter a new firewall rule with destport “any” FTP works and the log contain only one line
09:26:33 FORWARDFW green0 TCP 192.168.0.5 63718 801.461.x.x 21(FTP)

I can´t believe that this might an error concerning to ALG, or?

15

No, you need to allow connections to the high ports of this FTP server as well.

1 Like
16

With Core154 and befor everything worked as should - no modification in the firewall was neccessary.

Now you say i have to “allow connections to the high ports of this FTP server as well.”.

So how might this dynamicly possible only in conjunction with outgoing ftp?

17

From wikipedia

Communication and data transfer

Illustration of starting a passive connection using port 21

FTP may run in active or passive mode, which determines how the data connection is established.[7] (This sense of “mode” is different from that of the MODE command in the FTP protocol, and corresponds to the PORT/PASV/EPSV/etc commands instead.) In both cases, the client creates a TCP control connection from a random, usually an unprivileged, port N to the FTP server command port 21.

  • In active mode, the client starts listening for incoming data connections from the server on port M. It sends the FTP command PORT M to inform the server on which port it is listening. The server then initiates a data channel to the client from its port 20, the FTP server data port.
  • In situations where the client is behind a firewall and unable to accept incoming TCP connections, passive mode may be used. In this mode, the client uses the control connection to send a PASV command to the server and then receives a server IP address and server port number from the server,[7] which the client then uses to open a data connection from an arbitrary client port to the server IP address and server port number received.[8]

So, this data connection port (21314 in your example ) must be open also. With ALG this was handled by IPFire, with ‘destport any’ rule this special port is allowed.

2 Likes
18

I guess from that also if they know the IP address of the FTP server they could also create a rule to allow port 20 in from that IP to use in active mode right? Ah still needs to send out from Port M, so I think no actually lol

19

until now it was for me a security feature to block also outgoing ports which are not neccessary. Now - if I need ftp i have to open any (unknown range) high port(s)?

20

No, not every port, just port 21314, as indicated by @bbitsch