We've ruled out a general block on outgoing connections to ftp servers from your network, which is good. Next step is probably traceroute; your network may be having problems accessing the netblock where the destination server lives. Fortunately, they allow traceroute
, so your next step is probably to traceroute to the destination, and see where things fall down. I've pasted my traceroute output in for comparison.
[me@risby]$ traceroute ftp20.extendcp.co.uk
traceroute to ftp20.extendcp.co.uk (79.170.44.20), 30 hops max, 60 byte packets
1 192.168.3.1 (192.168.3.1) 0.200 ms 0.113 ms 0.102 ms
2 lns18.inx.dsl.enta.net (188.39.1.30) 23.466 ms 23.318 ms 24.988 ms
3 gi1-8.inx.dist.dsl.enta.net (188.39.1.29) 23.782 ms 24.622 ms 25.546 ms
4 te2-2.interxion.dsl.enta.net (78.33.141.89) 26.186 ms 26.963 ms 26.802 ms
5 te2-3.interxion.core.enta.net (87.127.236.209) 27.554 ms 28.360 ms 29.085 ms
6 te4-2.telehouse-east.core.enta.net (87.127.236.137) 28.818 ms 28.512 ms 28.349 ms
7 * * *
8 mx01-xe2.3.0-lon.gs.nodefour.net (83.166.164.85) 28.397 ms 29.967 ms 30.681 ms
9 mx01-xe2.2.0-lon.gs.nodefour.net (83.166.164.34) 31.404 ms 31.112 ms 32.733 ms
10 mx02-xe1.2.0-dry.dc2.nodefour.net (83.166.164.38) 32.465 ms 33.060 ms 33.776 ms
11 83.166.164.54 (83.166.164.54) 33.529 ms 34.628 ms 34.356 ms
12 ftp20.extendcp.co.uk (79.170.44.20) 34.043 ms 30.541 ms 30.543 ms
It would also be useful to see whether you can access anything else on the destination; could you paste the output of ping ftp20.extendcp.co.uk
?
Edit: now we've established you're using linux on the desktop, you could productively use tcpdump
to see how far away the refusal is coming from. Here's my output from tcpdump -n -n -v -i p1p1 host 79.170.44.20
, when I do a telnet ftp20.extendcp.co.uk 22
(which connects), then a telnet ftp20.extendcp.co.uk 23
(which gets a Connection refused
, as it should):
14:20:40.047720 IP (tos 0x10, ttl 64, id 57773, offset 0, flags [DF], proto TCP (6), length 60)
192.168.3.11.57105 > 79.170.44.20.22: Flags [S], cksum 0x5a67 (correct), seq 2606771394, win 14600, options [mss 1460,sackOK,TS val 6671727 ecr 0,nop,wscale 7], length 0
14:20:40.078615 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto TCP (6), length 60)
79.170.44.20.22 > 192.168.3.11.57105: Flags [S.], cksum 0xc8ec (correct), seq 28398605, ack 2606771395, win 14480, options [mss 1412,sackOK,TS val 609884153 ecr 6671727,nop,wscale 7], length 0
[packets deleted]
14:20:48.193195 IP (tos 0x10, ttl 64, id 34283, offset 0, flags [DF], proto TCP (6), length 60)
192.168.3.11.57462 > 79.170.44.20.23: Flags [S], cksum 0x1fa0 (correct), seq 2030528683, win 14600, options [mss 1460,sackOK,TS val 6679872 ecr 0,nop,wscale 7], length 0
14:20:48.222609 IP (tos 0x0, ttl 47, id 0, offset 0, flags [DF], proto TCP (6), length 40)
79.170.44.20.23 > 192.168.3.11.57462: Flags [R.], cksum 0xae1d (correct), seq 0, ack 2030528684, win 0, length 0
Note how the ttl
field in the very first packet back from the server in the first case is 47
. Note how the ttl
field in the reset packet (flags [R.]
) in the second case is also 47, which is right and proper for a reset that comes from the destination server. If you see a much higher TTL, it strongly suggests the refusal is coming from somewhere much closer.
Edit 2: given what you've said about the TTLs in your case, it really does look as if that server has decided not to accept your connection. It's possible that something en route is faking that TCP-port-unreachable, but getting that right is difficult, and most firewall tools don't bother (iirc, even the great firewall of China famously failed to set TTLs on its refusals correctly).
As for why the remote server has decided to do this (automatic, maybe via fail2ban? manual, because of excessive downloads?), who can say? Unless you can contact the server admins, you probably won't find out why. If you have a business relationship with ftp20.extendcp.co.uk, escalate via those routes. Otherwise, I'd shrug, and use a proxy if there were a couple of files I desperately needed to get to or from that server.
Best Answer
Some versions of
nc
has strange behavior, related with specifying of listening port and listening address. Try to runnc
with-v
(verbosity
) option:Other way to troubleshoot similar issues is checking of the listened sockets: