webGUI over HTTPS not working after restoring backup
I have a stable pfSense 2.4.5 system that I've been running for about a year now, but unfortunately the hardware I'm using does not support AES-NI. I have a new machine that does which I've installed pfSense on. The webGUI worked fine using HTTPS after install.
I updated the new machine with my configuration by restoring a backup made on my original machine. Since the network devices are named differently, I had to update the interface assignments. That's been done, but I can no longer access the webGUI over HTTPS. When I try, the browser comes up and announces that the remote closed the connection unexpectedly.
For the moment, I've switched webGUI over to use HTTP, where it's working fine. Network addresses remain the same. I've tried it with a virgin browser that's never seen the old machine without any success. HTTPS was working fine on my original system.
I can't find any lurking references to my original IGB network devices. SSH works fine. Any suggestions on what I can do to get HTTPS working again?
(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 at time of backup and would attempt to automatically reinstall them at time of restore. I was fortunate that I had the original machine as a reference, but if I was doing this as a result of a catastrophic hardware failure, I wouldn't have had a current list of packages and would have had to guess/figure it out.)
Gertjan last edited by Gertjan
https : tell us about the cert - is it an auto generated one ? from acme ? date and time ok ? pfSense time ok ?
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 :
'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.
Gertjan last edited by
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?
Gertjan last edited by Gertjan
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.
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.