Stunnel Configuration - Address already in use (WSAEADDRINUSE) (10048)

[BiNewbee]

Dear Friends,

I know what you are going to say - This issue has been posted several times and so go check it out. Believe me, I spent more than two days searching this message board and others and I could'nt find any suggestions that helps resolve my problem. This is my last effort before giving up and trying NGROK.

My goal is to have a secured remote access of my cameras. Here is my setup and its pretty simple.

1. BI5 installed on a Windows 10 machine and the software works fine. The system uses the Windows defender firewall and Antivirus.
2. I use the ZyXEL router configured the port forwarding setting to forward a port to the BI5 installed manchine.
3. Installed Stunnel, edited the conf file as this:
   [https]
   accept = 443
   connect = 81
   cert = stunnel.pem
4. Installed Stunnel as a service and started up the service

Several posts said the " Address already in use (WSAEADDRINUSE) (10048)" means the port is already used by some other application so change the port #. i tried several other ports ( repalcing them in BI5, Router config and Stunnel conf) but nothing is working and getting the same message.

What I am I doing wrong or what I am I missing to configure? Please help.

 

[catnhat]

Did you ever find a resolution? I am hitting the same thing right now.

 

[Hail2030]

Did you ever find a resolution? I am hitting the same thing right now.

Did you get it working? I was getting the same error and then I found this guide. It works fine now.

Set up stunnel on Blue Iris 5 server

Required:Blue Irisstunnel Links:Self Signed CertificateForum discussion on SSL ErrorBlue Iris and stunnel video Note: It is a good idea assign your BI Server with a static IP address, after assign…

blueiristips.wordpress.com

 

[DebrodeD]

I've come across this problem several times as well and it's caused by launching the stunnel GUI when the stunnel service is already running. Just stop the service and then start the GUI again and it should work just fine (remember to stop the GUI before launching the service).

Another note for others and future self:

In the stunnel.conf file, you'll see the following default SSL config:

; Enable support for the insecure SSLv3 protocol
;options = -NO_SSLv3

You need to force stunnel to use TLSv1.2 with the follwing line:

sslVersion = TLSv1.2

So, your SSL config should look as follows:

; Enable support for the insecure SSLv3 protocol
;options = -NO_SSLv3
sslVersion = TLSv1.2

 

[Jason Poriss]

I bumped into this issue out of the blue after running stunnel for years. I wasn't able to determine WHY, but I have a workaround.

In the stunnel.conf configuration file, I changed [blue iris] to [blue iris 2].

Problem solved.

 

[kennnnnnnnnnnneth]

I did a little googling and it appears this is a known Stunnel bug. Just stop the service, and start it with the GUI. There isn't an ETA for a fix.
You can also modify the config a bit (just add something to the name in the config file like Jason did above)


Some technical stuff I pulled out of Wireshark and Event Viewer for people who care about it:

• Apparently, simply starting the Stunnel service doesn't load the configuration file; when the Stunnel service is started automatically by the system, manually in the Services tool or by using Stunnel Service Start, it does not pull a new copy the config file or network settings, and instead it starts with a cached copy of the config and network settings from when the service was last running. This is likely to allow the process to start before the OS has connected to the network and reduce resource usage.
• If something like the config file or the network settings change while the service is offline (ie., you change subnets or switch ports or add something to the config), the cache will fail a checksum against the new settings and config, and Stunnel will pull a fresh config and network settings.
• However if you lose network connection while the process is running (outage, changing switch ports, etc), and Windows believes that you have connected to a new "network" (you know, like when you bring your laptop to work and plug it in, and because you're on a new switch port that day it goes from "network 4" to "network 5" in the adapters because it sees a new switch port MAC address even though you have the same IP address), Stunnel will still sometimes think you're connected to the "old" network. This is an edge case, but I was able to reproduce it twice in 16 attempts.
• Even if you have the same IP address as before, this screws up how Stunnel sees the network, but in a way that is not included in the values used to calculate the checksum. Therefor, the service will keep restarting, run its checksum, think the cache is still valid, load the faulty cached network settings, fail, and the process repeats.
• Specifically, it appears that the "old" network settings prevent Stunnel from properly handling TCP segments (the virtual wrapper for your data packets in the Transport layer). The end user machine trying to connect to the Stunnel server will send a request to connect, and receive a malformed (invalid) packet from Stunnel in response; all the data is making the journey across the network layer, but the information contained in the segment (wrapper) for that data does not match up with the information contained in the segment that the end user machine sent to the server, so the end user machine will discard the packet.
• When you stop the Stunnel service and start it from the GUI, it forces the service to pull a fresh config and network settings.
• You can also force the service to pull a fresh config and network settings by changing anything not commented-out in the config file, which will make the cache fail its checksum.