webGUI over HTTPS not working after restoring backup
-
Hi,
https : tell us about the cert - is it an auto generated one ? from acme ? date and time ok ? pfSense time ok ?
@tgoltz said in webGUI over HTTPS not working after restoring backup:
As a side comment about restoring the backup....the process would be a lot less painful if the backup also kept track of what packages were installed
Well : it is !
Have a look at the config file you have used to restore ! All the installed packages and their settings are there !
When you re install pfSense "from scratch" and you import the backed up config file, all packages het installed, and their settings.
Open the config file using an editor like Notepad++ and see for yourself.Look for "<installedpackages>". All packages and settings are listed there.
edit : that is : if you checked this one then you have what you're asked for :
@tgoltz said in webGUI over HTTPS not working after restoring backup:
'm using does not support AES-NI
Me neither. And that not an issue at all for me.
Maybe my OpenVPN server access is what slower but I don't care : my VDSL is limiting anyway. -
I was (and still am) using the self-signed certificate that's generated at installation.
I do have it working now. The secret seemed to be turning HTTPS back on, switching the SSL certificate to the cert I'm using for the VPN, and then back to the self-signed certificate. Once I did that (and turned the HTTP redirect back on), then HTTPS started working normally again.
On the backup issue: I did have it backup the package information (and it was backed up), but I ended up with the package information restored but no packages installed. Part of the problem may have been that the system wasn't able to reach the internet until after the restore was complete and I restarted the machine.
-
@tgoltz said in webGUI over HTTPS not working after restoring backup:
Part of the problem may have been that the system wasn't able to reach
....
Didn't thought about that one !If you do not have a setup like the default DHCP, which connects on initial boot right after install, but a static IP and no DHCP aviable on the WAN network, or a PPPOE setup as a WAN, then you should setup this one first, in the GUI, manually.
Then, as WAN comes up after applying, you import the config.xml.
WAN settings won't change, they are identical, but package info will get read in, settings applied, and during the reboot all comes back.Thanks for the feedback.
-
And the problem came back after I rebooted. Much troubleshooting later, it appears that the problem is that OpenVPN is somehow binding port 443 on localhost/LAN, even though my OpenVPN profiles that use port 443 are bound specifically to other interfaces (WAN, and OPT2) with the listen set to TCP on IPv4 only.
When I booted the router up, attempting to connect to https from the LAN resulted in the connection being unexpectedly closed. The first clue was when I tried to restart webconfigurator from the console and it threw errors indicating that it couldn't bind to 0.0.0.0:443.
I found articles talking about squid taking over 443 and preventing webconfigurator from working, so I killed squid and that didn't help. Next up was OpenVPN, and once I had killed the OpenVPN tasks, I could then restart webconfigurator without errors and was then able to connect to https and login. After that, I restarted OpenVPN and everything is now working.
There seems to be some kind of race condition between webconfigurator and OpenVPN. Any suggestions on a good way to make sure that OpenVPN doesn't start until after webconfigurator? Is there a way to tell webconfigurator to only try to bind to the address of my LAN interfaces?
-
Euhhh, OPenVPN will never ever bind to port 443 TCP.
As you already found out, nginx, the GUI web interface binds to 0.0.0.0:443 aka all the available networks.
Starting OpenVPN fill produce a fail, or the GUI fails on all pfSense installs that use OpenVPN, and lately, that's a lot.So .... check your OpenVPN config ;)
Btw : it's possible to use 443 TCP for OpenVPN. In that case, move the GUI web server out of the way first.
@tgoltz said in webGUI over HTTPS not working after restoring backup:
Is there a way to tell webconfigurator to only try to bind to the address of my LAN interfaces?
Short answer : no.
Long answer : of course.
Check the nginx web configuator config file.
Locate where and how "bind to 0.0.0.0:443" is written.
Now, look up where the config file is build (probably /etc/inc/services.inc) and change the part where the "listen ..." is laid out - and hardcode your LAN interface there. Beyond that : make a drop list in the GUI, store the selection in the config file, and use that one to select your interface. Consider even making a pull request and your code will live forever.edit : The coding of the Anti-lockout on System > Advanced >Admin Access will probably need some attention. The word LAN over there would be the interface where nginx is listening.
-
Sorry to dredge up an old topic, but I am facing the exact same issue. How do you end the OpenVPN sessions from the console?
-
@pfguy2018
Which one ?
pfSEnse as an OpenVPN client ?
The client connected to the VPN server ?What will work :
Kill the running OpenVPN instances. -
@gertjan
I managed to stop the OpenVPN server and then restart the webgui via the console. But when I rebooted, the same problem recurred. -
@pfguy2018 said in webGUI over HTTPS not working after restoring backup:
I managed to stop the OpenVPN server and then restart the webgui via the console. But when I rebooted, the same problem recurred.
The answer was here all the time :
@pfguy2018 said in Can't access webGUI:
nginx: 2021/11/14 18:13:15 [emerg] 61928#100494: bind() to 0.0.0.0:443 failed (48: Address already in use)
Rephrasing it :
nginx: cant use "any address": https port as some other process is already using it.
Which boils down to : the admin forgot to mention that the port 443 was used for more then one process. Both the GUI and OpenVPN were listening to the same port.
That's like two people having the same phone number. That can't happen neither.What happens is : the first process that grabs 0.0.0.0:443 wins, the second (nginx = the GUI) fails and logs a line, complaining.
Relocate the GUI to another port like 444 or 4343 or whatever ** and things will get back to normal.
** tell the admin about this !.
-
Yep - did exactly that and problem was fixed. Thanks!
