Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We're experiencing some issues connecting to a remote FTP site (we randomly get timeouts on connect), and while we tend to think that the issue is with the remote FTP server (one clue is that we're only having issues with this specific server, all others work fine), we're trying to make sure that the issue does not come from our side.

I stumbled upon the following entry in kern.log of our proxy server (Debian 6.0) :

proxy kernel: [ 4421.346444] deny-forward IN=eth0 OUT=eth1 DST=yyy.yyy.yyy.yyy LEN=40 TOS=0x00 PREC=0x00 TTL=62 ID=59026 PROTO=TCP SPT=32116 DPT=21 WINDOW=8192 RES=0x00 ACK PSH FIN URGP=0

iptables -L gives the following output for chain forward (shortened for clarity) :

Chain FORWARD (policy DROP)
target     prot opt source               destination         
TCPMSS     tcp  --             tcp flags:0x06/0x02 TCPMSS clamp to PMTU 
ACCEPT     all  --             state RELATED,ESTABLISHED 
ACCEPT     tcp  --             state NEW tcp dpt:53 flags:0x17/0x02 
ACCEPT     udp  --             state NEW udp dpt:53 
ACCEPT     tcp  --             state NEW tcp dpt:53 flags:0x17/0x02 
ACCEPT     udp  --             state NEW udp dpt:53 
ACCEPT     tcp  --           state NEW tcp dpt:21 flags:0x17/0x02 
LOG        all  --             LOG flags 0 level 4 prefix `deny-forward ' 
REJECT     all  --             reject-with icmp-port-unreachable

Are those dropped packets related to the issue described here ? Could those be the reason the connection to the remote server sometimes fails ?

share|improve this question
up vote 1 down vote accepted

Yes dropped packets could be the reason the connection sometimes fails. And since the problem is only with that server I am pretty sure the problem is not on your side. You can do simple tests to see if you have any packet loss, such as pinging for a few hours and see if it reports packet loss, also ping another server or two to compare results (there are better ways to test packet loss, but I have found ping to be a quick and easy way to test, you can move on from there if you find a problem).

As to what causes the packet loss is anyone's guess. It could be a bad router, overheating firewall, bad ethernet port, or cable, somewhere... I've had experience with a firewall being utilised too much and occasionally just overheating and becoming unstable, dropping connections and being just overall unresponsive.

You may want to run tcpdump to sniff the ftp traffic between your side and the remote server. It should give you a good idea what is happening. Especially if you make it more verbose, i.e.:

tcpdump -w example.dump -i any -nnvvXSs 65535 tcp port XXX

That will record the whole packet. Then use tcpdump or some other tools to analyse and pipe it to grep, less, what have you

tcpdump -nnvvXSs 65535 -r example.dump

You can specifically search for things such as a tcp-rst like this:

tcpdump -nnvvXSs 65535 -r example.dump 'tcp[tcpflags] & tcp-rst != 0 and tcp[tcpflags] & tcp-ack != 0' and tcp port XXX
share|improve this answer
Well, pinging won't do any good as the remote server does not reply to ping (they have a very restrictive security policy). I'll try with TCP dump and see if I can get any useful information. Thanks :) – T. Fabre Oct 11 '12 at 6:31
As you said, the issue is with the remote FTP. We finally managed to reproduce the issue on another Internet connection without any proxy/firewall, which was not easy since the problem is pretty random. Thanks for your answer. – T. Fabre Oct 11 '12 at 8:58
Glad you made some progress. By the way it's a pity that ping is blocked at the remote server. It's not a measure that increases security at all and, as you noticed, it hinders proper network troubleshooting and a lot of other things that need icmp. – aseq Oct 12 '12 at 0:25

Your Answer


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.