I'm trying to establish a Stunnel link between to system; a Linux server and a Windows client. Stunnel server and client show in their logs that they can reach each other but then they show the "Connection reset by peer" in their logs:

Window Client:

LOG3[682]: readsocket: Connection reset by peer (WSAECONNRESET) (10054)

Linux Server :

LOG3[97]: TLS fd: Connection reset by peer (104)

What's wrong here that I can't understand and fix it?

  • I should mention that I'm using this Stunnel Server from a Linux Client perfectly.
  • One more thins; this is an over WAN connection! and the network between my Linux Client to Linux Server and my Windows Client to Linux Server are different and I'm not able to test both of them in the same network.
  • (1) ITYM 'obviously'; there is no such thing as an oblivious TLS connection, and if there were you couldn't log it (2) does the reset happen immediately or soon after connecting, or after some amount of time and/or when idle? (3) can you make a connection between simpler programs like telnet or netcat/ncat/nc, or maybe an SSH connection, and if so does that get reset? Jun 21, 2018 at 8:39
  • 1
    This sounds very much like someone (or something) actively killing the connection from between the two systems to me. It's possible, with some pretty basic packet inspection, to determine the correct sequence numbers for a TCP connection you can observe, and then all you have to do to kill the connection is send TCP packets with the RST flag set to both ends spoofed to look like they're coming from the other end of the connection. Jun 21, 2018 at 19:39
  • 1
    (@Austin+)... and some networks have middleboxes that deliberately block certain things for one or another reason. Does the network connection for the failing case go through anything other than an individual home, such as a business, organization, school, hotel or apartment building? Jun 22, 2018 at 7:24
  • 1
    (@dave_thompson_085) Nothing is different, but ISPs! Jun 23, 2018 at 2:48
  • 1
    Then it has to be something in the 'bad' ISP's network, possibly a mistake or bug somewhere. Are you using an unusual port, and if so can you try using 443 or 8443 or 465 or similar and see if that helps? Can you try connecting to other destinations, or via a different ISP, maybe a rented hotspot? Is your client system's MTU compatible with the network (though that usually gets ICMP or timeout instead of RST)? Jun 24, 2018 at 6:47


You must log in to answer this question.

Browse other questions tagged .