Hi
I opened the port 25374, this is the port TCP emulate, then I use canyouseeme.org to verify if really it is opened.
I have the very rare (strange) problem:
When the eMule was working, canyouseeme.org it saw my port. I received the message: ' success: I see its service in xxx.xx.xxx.xx in the port (25374) its ISP is not blocking Port 25374'
When enclosure emulates then he(she) verifies the new port of canyouseeme.org I have: Error: I could not see its service in xxx.xx.xxx.xx in the port (25374) reason: exhausted the connection time
But when I am going to extinguish the windows firewall it gives me a different error: Error: I could not see its service in xxx.xx.xxx.xx in the port (25374) reason: Connection refused
Can someone tell to me please why it happened this way and how to make the port always open?
Thanks.
EMule – canyouseeme.org to verify the port is opened
Hi Arthur!
There is no problem with your port forwarding, and it is working as expected. Port forwarding is nothing but just a feature of your router that guides how to route packets to a specific port to a specific host. It will do that whether or not the destination host's port is actually open or closed.
Even when the destination host has the destination port closed, the router still continues to forward any connection request packets to the destination host. The destination host will counter back with a RST packet informing the remote host that the port is closed instead of a SYN-ACK reply to proceed with the connection. This is the method a TCP SYN ping is based on, and it is how many port scanners work.
However, if the port is aggressively blocked by a firewall, then even the RST reply will get blocked. This is when the network activity will look like this:
1. The external host sends a SYN packet to the router.
2. The router receives the SYN packet and recourse it to the destination host.
3. The destination host accepts the SYN packet, but it gets blocked by Windows Firewall. Even if eMule were running, the application would not accept the connection request.
4. The external host hangs around for a RST or SYN-ACK response informing it that the destination port is closed or the connection request has been accepted; however, nothing happens.
5. Eventually, the external host's client application decides it has waited long enough, and the connection times out.
This is a feature of firewalls that merely drop traffic. A firewall that discards traffic will still send an RST response/an ICMP destination inaccessible. However, this represents more information about the network to potential attackers, which is why some network administrators prefer simply dropping blocked traffic.
