Ubuntu 19:10 - ftp: setsockopt (ignored): Permission denied (connecting to FTP server in active mode)

2

I'm currently running Ubuntu 19:10 as my primary operating system. I need to connect to an FTP server where the connection needs to be in active mode. I have tried this with Filezilla by enabling active ftp and also via the command line.

I can connect to the FTP server, however, when running it in debug mode by passing the -d flag to the ftp command, I am met with errors when attempting to list files.

Here is a screenshot of my terminal window:

terminal window

Probably worth mentioning I can successfully run pwd and I can change directories with cd given I already know the name of two directories.

The first error I see is this:

ftp: setsockopt: Bad file descriptor

followed by:

ftp: setsockopt (ignored): Permission denied

500 Illegal PORT command

ftp: bind: Address already in use

From doing a lot of googling I saw a variety of suggestions such as enabling passive mode, and checking my firewall. However, when enabling passive mode I am met with the following problem:

terminal window passive

Likewise, I've verified that UFW is inactive from running:

sudo ufw status

I've also checked that there is nothing blocked in iptables. I can connect to a regular FTP server in passive mode without issue. This is the first time I've been required to use active mode when connecting.

The question I therefore have is in two parts:

1. Is this likely to be an issue with my end (the client) or the FTP server?

2. If it is an issue on my end, what can I try to fix it?

Any help will be much appreciated!

Matt Kent

Posted 2020-01-12T00:33:46.673

Reputation: 123

have you viewed this or any page such as this https://linux.die.net/man/2/setsockopt setsockopt(2) - Linux man page "For setsockopt(), the argument should be nonzero to enable a boolean option, or zero if the option is to be disabled."

– vssher – 2020-01-12T03:07:00.737

Answers

1

The FTP protocol, written before today's concept of firewall existed is quite complex: while the client connects to the server for commands, for data transfers (including the output of the LIST command, but not the output of the PWD command which is directly in the command connection) in so-called active mode that is the server which initiates the connection (usually from port 20, to a random port chosen by the client).

All this makes it difficult for "dumb" firewalls to let FTP work with the PORT command. The PASV command instead makes the client initiate connections twice to the server: one for command and one for every data transfer. But the difficulty is now reversed: that's the server's firewall side which must cope with the random port chosen by the server when transmitting the PASV command's answer containing the IP and port.

What's the result for you?

  • you stated that you can't use passive mode: that usually means the FTP's server side is behind a restrictive (local or on the network path) firewall which has no configuration to allow the FTP server to open temporary random listening ports corresponding to the output of the PASV command.

  • for active mode:

    I noticed that the PORT command's address you're using is in the 100.64.0.0/10 network which is in RFC 6598:

    This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices.

    and

    o routing information about Shared Address Space networks MUST NOT be propagated across Service Provider boundaries. Service Providers MUST filter incoming advertisements regarding Shared Address Space.

    o packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links.

    That's the probable reason the server returns 500 Illegal PORT command.. Since the client is behind CGN, it's not possible (without some difficulty involving total control of both sides attempting such a connection) for the client to be reachable from outside. Probably no provision is done anywhere (by equipments doing NAT) to translate and handle an incoming connection for this FTP PORT command and it's rejected by the server since it's a non-routable address (but more directly because the FTP server will accept only the same address used in the command connection to avoid so-called FXP transfers, and your address is not the one the FTP server sees).

So in short:

  • the FTP server you connect to can't use passive mode
  • your ISP can't let you use active mode

There's no solution without investing in something else:

  • if you have leverage to the right persons to have the FTP server accept passive mode, try it.

  • change ISP

    Get an ISP not giving you Carrier-Grade NAT addresses. Then any random home router (probably including the one provided by the ISP) will handle correctly the translation of the PORT command in active FTP.

  • use a VPN

    This shouldn't be a simple commercial VPN to anonymize clients using it. It should be a full VPN on which you have full control to allow incoming traffic and correct handling of the FTP protocol. It could be a limited one allowing to port-forward some ports, which then also requires configuration on the client side to match the same address and ports, or it could be for example a Linux VPS where you can load kernel modules like nf_conntrack_ftp/nf_nat_ftp and use iptables or nftables, to automatically translate the PORT command from your client (as long as there's no encryption used in FTP).

  • don't use FTP for the resource you seek

    Have it available on HTTP, HTTPS, SFTP (that's along SSH, not related to FTP)...

A.B

Posted 2020-01-12T00:33:46.673

Reputation: 2 008

Thank you, this answer is brilliant and really detailed! I just had a thought, aside from all the other suggestions, would connecting via SSH and using an SSH tunnel work? – Matt Kent – 2020-01-12T16:29:21.313

Having SSH allowing tunnels allows more things. I can't tell if this would allow FTP to work. It depends where's the blocking FTP firewall. This would require configuring the client to always specify specific ports: the ports you open with the SSH tunnel. This might still not work because of the FTP daemon configuration then (by default remote ports (using -R) must be only on 127.0.0.1 on the server side). But if you have such access chances are you don't even need FTP at all. Chances are you might be allowed to use SFTP, or maybe even a shell? then there's scp, tar | ssh ... etc. – A.B – 2020-01-12T16:33:15.777

Hum, did you mean SSH to a third party? This scenario would be identical to the "It could be a limited one allowing to port-forward some ports , which then also requires configuration on the client side to match the same address and ports". In such case I suggest "good" clients. for example lftp.

– A.B – 2020-01-12T16:37:27.073

Essentially, I do not own the server. I'm doing some freelance work, but they have said the connection must be in active mode, hence all of the above problems came about. I was just thinking that if they gave me low level SSH access to just what I needed I could do "FTP over SSH" where it uses the regular FTP protocol but places an ssh tunnel between me and the server. I just wasn't sure whether I'd still face similar problems doing this. – Matt Kent – 2020-01-12T16:42:13.843

1If you're given ssh, use ssh to transfer files and be done with this. Anyway FTP gives in the clear the account's password and the data, which can be eavesdropped (for example by your ISP). ssh doesn't let this happen, and can use ssh keys for authentication. – A.B – 2020-01-12T16:45:12.877

Ah fantastic! Thanks for your help :) – Matt Kent – 2020-01-12T16:46:14.687

Asked: 2020-01-12T00:33:46.673

Viewed: 578 times

Active: 2020-01-12T16:16:46.123