Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I am debugging access to a remote service via. my Debian VPS. IPTables is used and allows outward port 21 traffic. The remote service is an FTP server (which I can access from my own PC and is not blocked by the remote service). I have also checked that Debian can access FTP servers (which it can).

I am wondering, what might Debian be using to block the IP? IPTables shows no blocked IP addresses. I also have dos-deflate installed although I have set that up for iptables. Any ideas on what might be blocking the connection?

PS: I get a "Connection Refused" when trying to use WGET to access the remote FTP (wget works with another FTP I used for testing).

share|improve this question
    
Did you also use wget to test on your own PC? Wget defaults to passive FTP; it's rare, but maybe the remote service only works with active FTP: try wget --no-passive-ftp. –  Gilles Aug 23 '10 at 22:01
    
Unfortunately that also produced the same, connection refused, result. I've sent another message to the FTP host. –  jSherz Aug 24 '10 at 17:52

3 Answers 3

It will probably give the same issue, but try doing a telnet to the remote IP telnet ip_address 21 to ensure it's an IP/port issue. If that says refused but you can FTP other networks (make sure they are other networks) then it's a firewall issue.

Post your IPTables above (I know you say it's not the cause, but just to make sure!). You can also try asking your hosting provider to ensure that they're not blocking 21 outbound to that IP (extremely unlikely). Finally, ask the FTP service why they're blocking your IP address.

share|improve this answer
    
First of all, the FTP service provider have checked that they are not blocking my IP. I've put the output of iptables --list at pastebin.com/NkMEjAHm Telnet gives: telnet: Unable to connect to remote host: connection refused –  jSherz Aug 23 '10 at 18:48
    
From your IPTables it doesn't look as though you're blocking it. I'd recommend flushing the rules temporarily to make sure, but you've got a policy DROP in place so maybe not. If you're getting connection refused you're hitting the server (or at least a hardware firewall in front of it) and you're being reject by either the hardware firewall, software firewall, or FTP. Is it possible that their PAM is blocking you? Do you have any admin access to the server? –  James Lawrie Aug 23 '10 at 19:48
    
It's provided by a different company so I don't have admin access. PAM may be blocking me but I did ask them to check they weren't blocking me - which they said they were not (and being a professional server host one would hope that they would be right). –  jSherz Aug 23 '10 at 20:13

FTP uses two ports, one for data transfer, the other for control. 21 is the control port, 20 the data port.

You should open port 20 too (and this is active FTP, for passive FTP you need to open the ports used by your FTP software too)

share|improve this answer
    
I could successfully access another FTP site (which I used as a test). Opening port 20 did not work :( –  jSherz Aug 23 '10 at 19:07

It might be helpful if you can pinpoint exactly where your packets are being dropped. hping is pretty hand for this.

You can make your own traceroute on port 21 by incrementing the TTL (-t) from 1 - 10 as follows:

for i in `seq 20`; 
  do echo "+++++ TTL IS: $i +++++"; 
  sudo hping3 -t $i -S ftp.example.com -p 21 -c 1; 
done

Packets returned because the TTL is too low will show: TTL 0 during transit from ip= name=UNKNOWN

When you start getting 100% packet loss you'll know where to start looking.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.