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

I'm hitting a very strange problem - when I try to connect to one of our servers the client hangs with SYN_SENT if something listens on the port (e.g. Apache on port 80, sshd on port 22 or SMTP on port 25) but if I try to connect to a port on which nothing listens then I immediately get a "CONNECTION refused" error. Connecting to other applications (e.g. rsyncd on some arbitrary port) succeeds.

I ran tcpdump on the server and see that the SYN packets arrive to it but it only sends a response if nothing listens on that port.

e.g.: on the server I run:

# tcpdump -nn port 81
06:49:34.641080 IP 10.x.y.z.49829 > server.81: S 3966400723:3966400723(0) win 12320 
06:49:34.641118 IP server.81 > x.y.z.49829: R 0:0(0) ack 3966400724 win 0

But if I listen on this port, e.g. with

nc -4lvvv 81 &

Then the output of tcpdump is:

06:44:31.063614 IP x.y.z.45954 > server.81: S 3493682313:3493682313(0) win 12320 

(and repeats until I stop it)

The server is CentOS 5, the client is Ubuntu 11.04, the connection is done between two LAN's over per-user TCP OpenVPN.

Connection to other servers on that network do not have a problem. Connecting from the other servers on the same network to that server works fine. Connections from other clients in our office over openvpn is also not a problem.

What am I missing?


share|improve this question
It sounds like you have some broken firewall settings. –  David Schwartz Nov 14 '11 at 8:52
There are no firewalls on either client or server. Also the tcpdump on the server should have shown a response packet going out, just like I see the connrefused packet, even if a firewall was blocking them in another hop. –  Amos Shapira Nov 14 '11 at 22:12
It could be something that is in fact a firewall that you don't think of as a firewall. For example reverse path filtering. –  David Schwartz Nov 14 '11 at 22:23
Interesting about RPF. How would that sit with the following additional facts: 1. This host has only one interface (eth0). 2. rp_filter is turned on for eth0 (and default), just like on other servers which don't have the problem. 3. the connrefused packets to get routed fine. 4. connections to some of the ports are answered correctly. I realise that you gave rpf just as an example of something which could intervene, like defensive network handling or routing, but these would have affected other connections as far as I can tell. –  Amos Shapira Nov 14 '11 at 22:29
RPF was just an example. I doubt RPF is actually the issue here. –  David Schwartz Nov 14 '11 at 22:31

Your Answer


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

Browse other questions tagged or ask your own question.