TelNet Error Message

"Forcefully" presumably means "There is something listening on that port, but it refused my connection request," as opposed to "The system rejected my connection request" due to nothing listening on that port.

The security logs on the target system might reveal more information.

Thank you.  Where can I find the security logs on a windows 10 pc?

Just an addition to what Dr Klahn already stated

It's possible that the device is listening on a different port, or if forwarding is required it may not be setup or setup properly

Run a port scan on the device (assuming you're able to) and see if and where Telnet is running.

Where can I find the security logs on a windows 10 pc?

https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing/view-the-security-event-log

If you have access to the target system, download a copy of Microsoft TCP View and see if there is anything listening on port 23.

https://docs.microsoft.com/en-us/sysinternals/downloads/tcpview

How do I run a port scan.  I have two identical devices (race timing machines) and both have always connected just fine.  One still does and one suddenly does not.  The settings look the same and nothing was (consciously) changed.  I really appreciate your help!

This just means the telnet connection was answered with a port unreachable icmp packet rather than just ignored. this is the answer you get when you are on the same lan or internal network and the host is not firewalled.

Stealth cases produce timeouts. Whether the session is blocked by a separatd firewall or the host's.

router or firewalls which block the connection actively normaly should return a host unreachable. Some misconfigured firewalls may return a port unreachable. But that is less likely.

You'll refer to the logs on the server (machine you're connecting to, not from) to debug this.

You can also post the exact telnet command you're using... something like...

telnet foo.com 25

Select allOpen in new window

Remember...

Telnet != OpenSSL

So if the listener is a SSL/TLS connection, you must use the openssl command, rather than telnet.

there is nothing to debug : nothing listens on that port, there is no firewall, the server answers with port-unreachable. this is normal behavior.

Of course, as skullnobrains says, if a telnet service is not running on that machine with a hole punched through the Windows firewall for it to see the outside world ... then this would be the expected situation.

@drklahn : you may want to review your first post : there is no way a software program can reject connections. you barely can accept and then close or reset them. and you cannot know where the connection comes from before you accepted it.

again, this is the default way ip traffic works on all hosts since the beginning.

actually most local software firewalls are capable to return port-unreachable packets and it is good practice to do so whenever connections come from non broadcast lan addresses. microsoft thinks otherwise so many people think simply not answering is the "normal" behavior. it is not. and it is essentially pointless.

the normal behavior is to forcefully reject which makes debugging much easier and allows the client to know the connection cannot work immediately and act adequately ( failover, notify the user ) rather than hang uselesly in mid-air for dozens of seconds.

on the WAN, things are quite different and you would typically not respond to ping nor send said port-unreachable packets in order to prevent hosts discovery and rather inefficient reflexion attacks.

The issue was a static ip address conflict.  Someone in my home must have added a wireless lan adapter or something...I have to find that out and adjust but I learned so much from this thread.  Thank you all!