Michael Schwartz's picture

Evening. New to turnkey linux as a lxc container in ProxMox v6. I fired up the MySQL container and everything worked as expected, then all of a sudden I started getting PR_CONNECT_RESET_ERROR when trying to connect to the Adminer web page at https://xxx.xxx.xxx.xxx:12322, but could connect to Webmin. Fast forward 12 hours later.... Now I can connect to both Adminer and Webmin.. Then 30 minutes later I can no longer connect to Webmin and get the same PR_CONNECT_RESET_ERROR.  I tried Chromium and got the same message. Then tried from a Windows machine and got the same PR_CONNECT_RESET_ERROR in firefox, and IE claims the page is not available.

Purged the container and created a new one. Same results. Purged again. Removed the template and downloaded a new template. Same results.

Purged the container and downloaded the PostgreSQL template, created a container from that. Same results.

What could be the culprit? I have not made any changes in my router configuration, servers, DNS.... Tried removing all firefox extensions, cleared the cache, restarted the computer, reboot the ProxMox server.

Thoughts??? Any help would be greatly appreciated.

 

 

Forum: 
Jeremy Davis's picture

If you're running Proxmox v6.x, then I assume that these are both v16.0 TurnKey releases? Also, I'm guessing that these are unprivileged containers? And you're setting a static IP for them from the Proxmox host when setting up the machines? Working on those assumptions:

We've had reports of Webmin being a bit unreliable and was hoping that the updated package(s) should resolve that. FWIW Webmin actually runs behind Stunnel (an SSL/TLS reverse proxy).

However, we're not had any reports of LigHTTPd (aka Lighty) having reliability issues. FYI Adminer in both the MySQL and PostgreSQL appliances is hosted by LigHTTPd.

I've not come across the 'PR_CONNECT_RESET_ERROR" error personally, but a quick online search suggests that it's usually caused by the server and the browser not being able to agree on a SSL/TLS certificate version/encryption algorithm.

In v16.x TurnKey servers (both Lighty and Stunnel) should default to TLSv1.3 but should also provide the ability to downgrade to TLSv1.2 (for some older browsers/OS). It's expected behaviour for that to cause issues with really old devices that use unsupported OS and/or browsers that rely on TLSv1.1 or earlier (e.g. IE on WinXP, early Android devices, etc). FWIW anything lower than TLSv1.2 is insecure. However, that should not be an issue with a modern browser on a supported OS. And it definitely should either "just work" - or not. It should never be intermittent!

So I have no idea how a TurnKey server could be doing this?! My suspicion is that either the error message is a misnomer (and something else is actually going on) or that the issue is actually being caused somewhere else?! Perhaps an IP clash (where you are connecting to a different machine)? Perhaps something weird going on with your Proxmox host? I'd also be inclined to suspect your guest browser and/or OS, but you note that you've tried multiple browsers and OS, so that seems unlikely...

I suggest that you try to recreate the issue and when it occurs, check the status of Lighty and/or Stunnel. To check the services, you can use 'systemctl', i.e.:

systemctl status lighttpd.service
systemctl status stunnel4@webmin.service

You can see the full history of these services since last reboot via the journal, i.e.:

journalctl -u lighttpd.service
journalctl -u stunnel4@webmin.service

The Stunnel process doesn't log to file by default, but Lighty should be logging to files in /var/log/lighttpd/. So you can also check them for errors. Please feel free to post back with any of these logs if you want a hand interpreting them.

Michael Schwartz's picture

I appreciate the time you have taken to help me understand how turnkey works.

-If you're running Proxmox v6.x, then I assume that these are both v16.0 TurnKey releases? Also, I'm guessing that these are unprivileged containers?

> Correct

-And you're setting a static IP for them from the Proxmox host when setting up the machines?

> I have tried static, dhcp with and without the router assinging static ip using mac address.

Logs:

root@MariaDB ~# systemctl status stunnel4@webmin.service
* stunnel4@webmin.service - Universal SSL tunnel for network daemons (webmin)
   Loaded: loaded (/lib/systemd/system/stunnel4@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-09-21 23:58:48 EDT; 42s ago
  Process: 212 ExecStart=/usr/bin/stunnel4 /etc/stunnel/webmin.conf (code=exited, status=0/SUCCESS)
 Main PID: 221 (stunnel4)
    Tasks: 2 (limit: 77010)
   Memory: 2.1M
   CGroup: /system.slice/system-stunnel4.slice/stunnel4@webmin.service
           `-221 /usr/bin/stunnel4 /etc/stunnel/webmin.conf

Sep 21 23:58:56 MariaDB stunnel[221]: LOG3[17]: No more addresses to connect
Sep 21 23:58:56 MariaDB stunnel[221]: LOG5[17]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
Sep 21 23:58:56 MariaDB stunnel[221]: LOG5[18]: Service [webmin] accepted connection from 192.168.1.5:44190
Sep 21 23:58:56 MariaDB stunnel[221]: LOG3[18]: s_connect: connect 127.0.0.1:10000: Connection refused (111)
Sep 21 23:58:56 MariaDB stunnel[221]: LOG3[18]: No more addresses to connect
Sep 21 23:58:56 MariaDB stunnel[221]: LOG5[18]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket
Sep 21 23:58:56 MariaDB stunnel[221]: LOG5[19]: Service [webmin] accepted connection from 192.168.1.5:44192
Sep 21 23:58:56 MariaDB stunnel[221]: LOG3[19]: s_connect: connect 127.0.0.1:10000: Connection refused (111)
Sep 21 23:58:56 MariaDB stunnel[221]: LOG3[19]: No more addresses to connect
Sep 21 23:58:56 MariaDB stunnel[221]: LOG5[19]: Connection reset: 0 byte(s) sent to TLS, 0 byte(s) sent to socket

 

Thanks again for your help.

 

Mike

 

Jeremy Davis's picture

It looks like Webmin is not responding when it tries to pass the web traffic on. I'm not sure, but this does sound very similar to another user which prompted me to tweaks the Webmin service file which we ship in the package.

So if you could please upgrade to the latest TurnKey Webmin packages as documented in the blog post. Please feel free to just post back here if you have any continuing issues with Webmin. As noted in the blog post, this command will give us some useful info:

systemctl status webmin.service stunnel4@webmin.service

I'm pretty sure that your issue isn't related to the issue that Jerry hit (in the blog post comments - we never heard back but I'm 99% sure that his issue is caused by running a 'privileged container). So it's probably best to not follow the points that he and I discussed there (although feel free to read it if you're interested).

I can't guarantee that the Webmin update will resolve the issue, but hopefully it will at least rule that out as the issue.

If/when Adminer fails again, please provide the status of lighty as noted in my previous post.

Michael Schwartz's picture

I will read the info, update webmin to test, and report back.  Funny thing. When I woke up this morning webmin was accessible. Maybe it slept on it? LOL.  Anyways, here are the logs from this morning with it working.

root@MariaDB ~# systemctl status stunnel4@webmin.service
* stunnel4@webmin.service - Universal SSL tunnel for network daemons (webmin)
   Loaded: loaded (/lib/systemd/system/stunnel4@.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-09-21 23:58:48 EDT; 8h ago
  Process: 212 ExecStart=/usr/bin/stunnel4 /etc/stunnel/webmin.conf (code=exited, status=0/SUCCESS)
 Main PID: 221 (stunnel4)
    Tasks: 2 (limit: 77010)
   Memory: 2.6M
   CGroup: /system.slice/system-stunnel4.slice/stunnel4@webmin.service
           `-221 /usr/bin/stunnel4 /etc/stunnel/webmin.conf

Sep 22 08:47:14 MariaDB stunnel[221]: LOG5[22]: Service [webmin] connected remote server from 127.0.0.1:58680
Sep 22 08:49:09 MariaDB stunnel[221]: LOG3[21]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing
Sep 22 08:49:09 MariaDB stunnel[221]: LOG5[21]: Connection closed: 526177 byte(s) sent to TLS, 1134 byte(s) sent to socket
Sep 22 08:49:10 MariaDB stunnel[221]: LOG3[22]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing
Sep 22 08:49:10 MariaDB stunnel[221]: LOG5[22]: Connection closed: 1436 byte(s) sent to TLS, 337 byte(s) sent to socket
Sep 22 08:51:12 MariaDB stunnel[221]: LOG5[23]: Service [webmin] accepted connection from 192.168.1.7:60034
Sep 22 08:51:12 MariaDB stunnel[221]: LOG5[23]: s_connect: connected 127.0.0.1:10000
Sep 22 08:51:12 MariaDB stunnel[221]: LOG5[23]: Service [webmin] connected remote server from 127.0.0.1:58700
Sep 22 08:51:12 MariaDB stunnel[221]: LOG3[23]: transfer: s_poll_wait: TIMEOUTclose exceeded: closing
Sep 22 08:51:12 MariaDB stunnel[221]: LOG5[23]: Connection closed: 26511 byte(s) sent to TLS, 493 byte(s) sent to socket
root@MariaDB ~#

Jeremy Davis's picture

Intermittent issues are such a pain to diagnose! Really you can only fix something that's broken, so half the trick is catching it when it's broken.

Good idea to get status output while it's working though. It might be useful to compare to when it's not working...

Michael Schwartz's picture

So I cloned my container a ran the webmin updates. This should give me a side by side comparision if it fails again. Thanks again for your help and I will report back any issues.

Jeremy Davis's picture

Great plan! :) It seems like you might have done this before?!

Michael Schwartz's picture

So far no more issues. Looks like the Webmin update worked! Thank you.

Jeremy Davis's picture

Fantastic news! Thanks for taking the time to post back. Good luck with it all and hopefully catch you around the forums another day... :)

Add new comment