SSL changed from 443 to 8443

Hello there,

When PRTG is (re-)starting and port 443 is not available, it will try to switch to a different port. This usually happens when another application is grabbing the port before PRTG is able to bind it. PRTG's logs do not state though which other process is holding the port, it only logs that the port is not available. You could check with TCPView for example which process is listening locally on 443.

We also had cases in the past where certain Windows updates for Server 2008R2 and Server 2012R2 (KB4338815, KB4338818) caused the web server to be unable to bind its ports again after a service restart. This was solved with follow-up patches for 2008R2 and 2012R2.

Kind regards,

Erhard

Thanks for the info. PRTG is running on Win Server 2016 and PRTG is the only application running on that server. I did find a scheduled reboot of PRTG for last Friday in the event viewer that is most likely the culprit.

Right, when rebooting it tries to get a hold of the configured port again and in case the port is taken/occupied, it tries an alternative port by itself.

Kind regards,

Erhard

I had a similar problem today running PRTG on Windows Server 2012R2. I needed to change the User account the PRTG Core Server service was running as, and I did this in the Windows Services panel. I then tried to stop the PRTG service in the Windows Services panel, and the service went to "Stopping" status, and stayed there for 10+ minutes. I tried killing the task, and after several attempts was finally able to do so. When I restarted the PRTG Core Server service, it started on port 8443. I used NetStat -a -n to make sure no processes were listening on TCP port 443 and used the PRTG web interface (Setup menu) to restart the core service. However, this indicated that the server would still be restarted to listen on port 8443. I tried changing the web server setting to specifically enter port 443 and restarted the server, with the same result (listening on port 8443 instead.) I tried using PRTG Administration windows application on the server to restart the service with the same result. I repeatedly checked TCP ports in use with NetStat and also TCPView (mentioned above in this thread), and port 443 was never listed. I also checked Windows Updates, and the follow-up patches (mentioned above in this thread) were not listed in the available Windows Updates (all updates have been recently applied.) Only a Windows server restart finally allowed PRTG to listen on port 443 again.

Hello FleetillaMarc,

This sounds very much like the described above induced by a particular Windows update (unable to grab 443 although not held by another process).

Kind regards,

Erhard