Please enable JavaScript to view the comments powered by Disqus.

CONN_TIMEOUT vs CONN_REFUSED (Firewall DROP vs REJECT)

In Problems When Setting Up WriteFreely Part 2: Firewall, I explained how I couldn't access my blog over https because of the firewall I've set up ages ago and forgotten.

I showed the outputs of two curls:

╭─teddy@teddy-ubuntu ~ 
╰─$ curl -vvv http://teddyh.dev
*   Trying 54.151.219.0:80...
* TCP_NODELAY set
* connect to 54.151.219.0 port 80 failed: Connection refused
* Failed to connect to teddyh.dev port 80: Connection refused
* Closing connection 0
curl: (7) Failed to connect to teddyh.dev port 80: Connection refused
╭─teddy@teddy-ubuntu ~ 
╰─$ curl -vvv https://teddyh.dev
*   Trying 54.151.219.0:443...
* TCP_NODELAY set
* connect to 54.151.219.0 port 443 failed: Connection timed out
* Failed to connect to teddyh.dev port 443: Connection timed out
* Closing connection 0
curl: (28) Failed to connect to teddyh.dev port 443: Connection timed out

I failed to notice this at the time, but there is a subtle difference between the two outputs: Connection refused vs Connection timed out.

What do they mean?

It is easier to understand if we take a peek at the TCP layer when the curl requests are being sent:

Connection refused

─teddy@teddy-ubuntu ~ 
╰─$ sudo tcpdump -nn "host teddyh.dev and port 80"  
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:33:25.540898 IP 192.168.10.117.43884 > 54.151.219.0.80: Flags [S], seq 2847222361, win 64240, options [mss 1460,sackOK,TS val 564702358 ecr 0,nop,wscale 7], length 0
10:33:25.543802 IP 54.151.219.0.80 > 192.168.10.117.43884: Flags [R.], seq 0, ack 2847222362, win 0, length 0

Connection timed out

(Induced by firewall DROP rule)

╭─teddy@teddy-ubuntu ~ 
╰─$ sudo tcpdump -nn "host teddyh.dev and port 443"                                                                                                                                                          130 ↵
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp7s0, link-type EN10MB (Ethernet), capture size 262144 bytes
10:34:34.541405 IP 192.168.10.117.44816 > 54.151.219.0.443: Flags [S], seq 1786361284, win 64240, options [mss 1460,sackOK,TS val 564771358 ecr 0,nop,wscale 7], length 0
10:34:35.569866 IP 192.168.10.117.44816 > 54.151.219.0.443: Flags [S], seq 1786361284, win 64240, options [mss 1460,sackOK,TS val 564772387 ecr 0,nop,wscale 7], length 0
10:34:37.589852 IP 192.168.10.117.44816 > 54.151.219.0.443: Flags [S], seq 1786361284, win 64240, options [mss 1460,sackOK,TS val 564774407 ecr 0,nop,wscale 7], length 0
^C

*Note: Client IP address is 192.168.10.117, Server IP address is 54.151.219.0

Interpretation

Connection refused

The client tried to open a connection (SYN), but the server closed the connection (RST). Put simply, you (the client) knocked on your friend Bob's front door and his mom (the server) told you “Bob's not home!”

How could this happen?

  1. Bob's mom was lying. Bob was grounded, so his mom didn't want you to meet Bob. This is analogous to a firewall REJECT rule
  2. Bob's mom was telling the truth. Bob indeed wasn't at home. This is analogous to no service/process listening to the destined port on the host.

Connection timed out

Connection timed out means the client kept trying to open a connection to the destined port on the host, but there was no reply — so the client gave up trying. The client tried to open a connection (SYN) again and again, with no reply from the server. Put simply, you (the client) kept knocking on your friend Bob's front door and there was no answer.

How could this happen?

  1. Bob's at home but didn't hear you knocking. The sound of your knocks didn't reach him. This is analogous (well, not really) to a network congestion
  2. Bob's whole family kept quiet and didn't answer the door. They hear you, but they choose not to answer you. This is analogous to a firewall DROP rule
  3. Bob's whole family is not at home. This is analogous to a powered-off host. (I've confirmed this by trying to open a TCP connection to a powered-off host.) Contrast this with the Connection refused scenario in which we received a response from the server — indicating that the host is up.