Why is my connection refused when port-forwarding?

Question

This question is related to this: Application / Device setup for remote network connections

I have a 2wire 3801HGV router and I made some firewall settings to open some ports on one of my connected devices.

So now actually it will say:

Pinholes

external pin-holes (186 available):
pinh[0]: id 5, proto 6, sess tout 86400, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:80, n: **.**.***.**:80
pinh[1]: id 6, proto 17, sess tout 600, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:80, n: **.**.***.**:80
pinh[2]: id 7, proto 6, sess tout 86400, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:9000, n: **.**.***.**:9000
pinh[3]: id 8, proto 6, sess tout 86400, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:18004, n: **.**.***.**:18004
pinh[4]: id 9, proto 17, sess tout 600, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:9000, n: **.**.***.**:9000
pinh[5]: id 10, proto 17, sess tout 600, pinh tout 0, arg 0 natpt|user
  l: 192.168.1.253:18004, n: **.**.***.**:18004

Of course instead of those * it shows my actual, public IP.

If it says that, then how come when I go to http://www.canyouseeme.org/ and I'm checking ports 80, 9000, and 18004 it says

Error: I could not see your service on **.**.***.** on port (80/9000/18004)

Reason: Connection refused

Answer 1

When you port forward on a router, you are telling it to pass any incoming connections on those ports to an internal device.

All that the router does is change the destination IP address on the incoming packet to the internal IP address you have specified. The device at the internal address is responsible for receiving and responding to the incoming connection.

So in order for a port forward to work you need both the port forward set up, and you need the internal device "listening" on the incoming ports.

If the internal device does not have an application running that is ready to accept the incoming connection, it will send a TCP RST packet back to the source, which is generally described as a "Connection refused".

Once you have your applications running on these ports, the port forward test should succeed.

Answer 2

Connection Refused means the DVR's NIC is either sleeping or got frozen or stuck, so the service that was running inside of Linux Embedded System has corrupted which requires a DVR reboot to reset. As most DVRs are over-committing the resources and people, do not follow the recommended lower setting, and this is just one of a dozen common reason why DVRs can't stay a week of uptime.