Still having the problem, now I have some logs

See attached file.

Tried the workaround in https://redmine.pfsense.org/issues/6862 - did not work


" bind() to 0.0.0.0:443 failed (48: Address already in use)"

What is using it?

2.3.3-RELEASE][root@pfsense.local.lan]/root: sockstat | grep :443
root    nginx      78975 6  tcp4  *:443                :
root    nginx      78975 7  tcp6  *:443                :
root    nginx      78929 6  tcp4  *:443                :
root    nginx      78929 7  tcp6  *:443                :
root    nginx      78911 6  tcp4  *:443                :
root    nginx      78911 7  tcp6  *:443                :
root    openvpn    23945 5  tcp4  24.13.snipped:443      :

@pluff:

I did kind of cover that off along with the reboots

How exactly do reboots cover browser web page refresh?

@doktornotor:

How about upgrading your pfSense to 2.3.3 and using the ACME package?

Thanks for the suggestion.  As I just mentioned, I was able to get it working.  But as my current certbot workflow is somewhat clunky, I should see if 2.3.3 w/ACME can file off some of those rough edges.  A project for next weekend…

Will be hard to guess the OTP password on the proxy gateway… then you will have to guess the gui password as well.

I need to access from work where I have not mobile data (nuclear plant, the walls are so thick). And I cannot use VPN on my workstation, only proxy access to internet.

The permission was not bring properly honored in old versions because of a bug. We fixed the glitch.

Invalid configurations "broke" when we fixed said glitch, but they were never valid. It was that or clear the privilege on upgrade, and for a bug like that we went with the secure choice.

I wanted to wait a few days to make sure I did enough testing to feel fairly comfortable.  @doktornotor That thought had crossed my mind but I have always had some sporadic connection issues (to websites where someone would get the the ERR_CONNECTION_TIMED_OUT error).  But to try to eliminate things I removed my Pi-Hole VM, my Kujo security appliance, a few consumer grade non-managed switches with decent quality HP/Dell managed switches, my consumer AP's and replaced them with rock solid Adtran BSAP-1920's.  But I would still get the sporadic connection issues.  Hell I even shut down my Guacamole VM just to be sure.

But with this latest problem I wanted to remove pfSense and I realized I still had some VM's from when I was testing various firewalls/UTM software.  I knew for sure that Sophos UTM 9 and OPNsense were functioning.  So I powered down the pfSense VM and fired up both the VMs (testing one at a time) and my connections came back (tested for about and hour).  I then powered down the other VM and powered up pfSense and back to the connection issues.  So for this past two days I've been running on Sophos UTM and everything has been just fine.  Not one single connection time out issue.  I even have my pi-hole and Cujo connected and no issues.

So I'm not sure what the hell I did with pfSense (since I don't make many changes) but something I changed/checked seemed to have hosed my config.  At this point when I get back from Portland I'll have time to reinstall pfSense and start all over.  going forward I will make sure I take detailed backups whenever I make a change.

@josemaX:

Thanks, worked for me also, only to say (if helps some), these certs are the ones on the Certification Authorities Tab.

You were posting against a subject from 2014 - using an ancient pfSense version that doesn't exists anymore …

Done: https://redmine.pfsense.org/issues/7312

Looks like it's a bug - https://forum.pfsense.org/index.php?topic=117036.msg662633#msg662633

System -> General setup

lihn.jpg
lihn.jpg_thumb

@awnz:

….

My question is: where are notifications cached, so I can clear the backlog and re-enable SMTP notifications? I can't find them :(
....

Try /tmp/notices (according to /etc/notices.inc)

Something to try as I found it caused a similar issue for me: check under System > Advanced > Notifications that the server pfSense sends administrative notifications to is correct.

In my case, it was pointing to a wrong IP address. php-fpm handles sending admin notifications and they all hung on trying to send them to a nonexistent server, making the webGUI unresponsive.