Can you find out why connection refused happens if you are not the sender of request?

Question

I have read a few posts and articles about why a connection would be refused. This usually talks about it in general, like this one What causes the 'Connection Refused' message?.

But my question is how or when can you be certain that there is something wrong with the other side (lets say someone sending a request to you).

In this scenario if you call a request to a public ip and port that you set up and the connection goes through and everything goes right (from different devices, ips and networks) but then, if someone else sends it it gets refused. How do we know what the issue is ?

Answer 1

When a client attempts to connect to a service/server there are roughly the following scenario's:

1. The connection succeeds.
2. The connection attempt fails, because the client receives no response. It receives neither positive nor negative response and the connection attempt eventually simply fails from a time out.
3. The connection attempt fails, but the client receives an error message.

When you try to debug from the client

• scenario #1 is easy ;)

• scenario #3 usually shows as a "connection refused" error.
  When you run a packet capture on the client you'd be looking for :

  • either TCP reset/RST packet
  • or an ICMP packet such as "unreachable - admin prohibited".

  Both of which contain a source IP-address which either matches the IP-address of the server you're connecting to, or not.

  • When the error comes from the server either nothing is listening or there might be a host-based firewall active on the server.
  • When the IP-address is not from the server, it comes from the (first) device on the path between client and server that is blocking the connection attempt.

• scenario #2 sometimes shows as a "connection time-out" and sometimes a bit incorrectly as "connection refused".
  This is usually the result from a firewall configuration that silently drops all connection attempts that are not allowed. From the client it is inconclusive where that happens. A packet capture shows nothing and you can't debug that from the client. You don't know where that happens, on the server or somewhere on the path between client and server.

When you try to debug from the server

• scenario #1 is easy ;)

• To debug both scenario #2 and #3 you can run a packet capture on the server:

  A packet capture on the server will see all incoming packets. Incoming packets are still received when no service is listening on the port. Regardless of the fact that an host based firewall may be active, a packet capture shows packets before they're processed and possibly rejected/silently-dropped by a host-based firewall.
  _{Linux reference here or Windows here}

  1. When packets from the client are received:
     Debug further on the server (check: the configuration of the host-based firewall, if the service is enabled, healthy, has active ACL's etc. etc.)

  2. When packets from the client are NOT received:
     The connection attempt is blocked somewhere along the path between client and server. From the server you can't learn where.