3

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

2
  • Does it work to connect to each of these ports on 192.168.1.253 from the internal network?
    – Paul
    Dec 10, 2013 at 23:41
  • No, when I try to connect to 192.168.1.253, 192.168.1.253:80, 192.168.1.253:9000, 192.168.1.253:18004 I always receive Oops! Google Chrome could not connect to ...
    – olli
    Dec 10, 2013 at 23:43

2 Answers 2

6

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.

4
  • Thanks for the hint! Sorry I can't upvote yet... I guess I'll dig deeper to see what might be wrong with the application.
    – olli
    Dec 11, 2013 at 3:07
  • So what this guy is describing here is incorrect? youtube.com/watch?v=tQrO0T01y10 He says to find out how to open ports, then check if the ports are open, and then it should work right away? I guess he assumes there is no error in how the DVR is set up...
    – olli
    Dec 11, 2013 at 3:08
  • @olli Yes, all portforwarding tutorials tend to assume that the internal device is configured and ready to recieve connections. So the first step should be to confirm that before setting up the portforwards.
    – Paul
    Dec 11, 2013 at 3:59
  • I am trying to figure out how to set up my device here: superuser.com/questions/687223/…
    – olli
    Dec 12, 2013 at 1:18
0

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.

2
  • 1
    Welcome to Super User. Connection Refused doesn't inherently mean the host has locked up or is otherwise non-functioning. Given that, can you expand your answer to explain why you believe a frozen/stuck NIC is the cause of the OP's problems? Jul 3, 2018 at 1:23
  • First of all, I don't have permission into the DVRs kernel so, to be honest, I can't read the log. However, I can replace the DHCP that will notify different syn fin ack, but the DVR still refuses. Therefore, I judge the DVR is sleeping or died, or in the coma state. And I don't think DVR drop the entire interface whole time instead of IP. But the result is inaccessible until the reboot. or what else should be the reasons for DVR's connection refuse? They all are busybox.
    – Seandex
    Jul 3, 2018 at 21:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.