No web gui after updating 24.03

stephenw10

Hmm, so just the existence of those floating rules prevented access?

The floating rules created by pfBlocker could well block access from the WAN. It coukld just be the pfBlocker lists pulled in something that blocked your local source IP.

4eanlss

@SteveITS Thank you for the information. Greatly appreciated. At this point I will not be able to get the GUI from the WAN IP as my ISP works in a way that I would ultimately be hitting their equipment.

johnpoz

@4eanlss said in No web gui after updating 24.03:

I will not be able to get the GUI from the WAN IP as my ISP works in a way that I would ultimately be hitting their equipment

Huh? That would be any and all traffic from pfsense to the internet - that is how isps work, yes your traffic be hitting their equipment. So not sure what your meaning with such a statement.

4eanlss

@johnpoz I was referring to the troubleshooting option to "Add an allow all WAN rule from the shell"; however, if I attempt to load my public IP address (https) I instead get a web page for a login of my ISP devices. Maybe I misunderstand what the troubleshooting was indicating to attempt. Regardless, I've compared all my configuration backups xmls and have not found a anit-lockout rule in any from the beginning; so, not sure if a ever had a valid configuration other than I was able to use the GUI interface 4 years until the upgrade.

4eanlss

@stephenw10 Since my router is functioning normally in all other regards I'm not that concern at this time. I will become familiar with the console interface and attempt to identify the differences in my configuration before/after the upgrade and post results here.

My configuration only runs two additional services: pfBlockerNG and UPS.
My procedure was:

Shutdown the system from the GUI menu.
After confirming the system was shutdown, pulled power.
Pulled the USB from UPS and replace batteries. Note: intent was to do UPS maintenance as well and did not want a forced shutdown by UPS during upgrade.
Restarted firewall, confirmed all services were working sans UPS (USB still unplugged).
Made configuration backup.
Performed an upgrade from GUI.
After device restarted and after 10-15 minutes of no response from GUI -- realization that GUI access was blocked; however, firewall was allowing inbound/outbound traffic as expected.

planetinse

@wisepds same issue for me webgui not responding after upgrade, but everything is up and running.

Edit: yes for me it was the interface bound state change, after set it to floating - it works again.

Bob.Dig

@planetinse said in No web gui after updating 24.03:

Edit: yes for me it was the interface bound state change, after set it to floating - it works again.

So you have asymmetric routing going on, maybe fix it.

stephenw10

Yes, it would be good to know exactly what scenarios are hitting that issue. Especially if it's something unexpected. The more we can add to the docs the better.

johnpoz

@4eanlss said in No web gui after updating 24.03:

I instead get a web page for a login of my ISP devices.

Sounds like your behind a double nat, or your doing something with nat reflection and trying to access your public IP from the lan side which is really on your isp device..

I find it highly unlikely that someone out on the internet going to your IP would end up hitting some upstream isp equipment webgui along the path to your IP webgui. Your local isp equipment with your actual public IP on, sure that would make sense.

rbron01

@johnpoz

I have the same problem when I update to the latest version.

It finished normal but never comes the console back.

I have a simple connection ISP-FW-LAN Port-PC.
I can log into the fw with simply opening a shell.

Nothing in the logs to be found. I also saw that the LE CA's are gone.
My certificates are there but not the CA's. Could this also be the root cause of the issue?

johnpoz

@rbron01 So your using LE for your webgui?

What exactly happens - does it just spin and spin in your browser and then say timeout, what error happens in your browser - does it just show a white page?

If you have console or ssh access, just reset the the gui to default listening on 80 without any ssl, does it work then?

rbron01

@johnpoz

When the update finished it says reloading in xx seconds.

Then when i start a new tab it starts spinning and gives a timeout

Did not try to do a port 80

johnpoz

@rbron01 yeah if you run into any sort of craziness with the web gui, you should always be able to fall back to just basic port 80.. I believe its after you reset your webgui password, it asks if you want to fall back to 80.. I think it also asks that if you from the console change your lan IP, which you could just change to whatever it is currently, etc.

Been a while since actually used or played with those options.. Could fire up my VM and see, not in the mood to try and reset my actual webgui ;)

rbron01

@johnpoz Changed from HTTPS to HTTP and the port to 80

Done an upgrade and as usual no more Webgui

It started and is doing traffice but nothing else

johnpoz

@rbron01 is there any way you could be running into the bound to interface change in states vs floating.. Your just hitting pfsense lan IP from device on your lan right..

Are you doing anything with policy routing or vpn client or ipsec connections?

rbron01

@johnpoz I have no policy routing nor vpn/ipsec stuff.

Just plane in out traffic.

Also get a timeout when trying,

johnpoz

@rbron01 do you show your webgui even running?

[23.09.1-RELEASE][admin@sg4860.home.arpa]/root: netstat -an | grep .8443
tcp6       0      0 *.8443                 *.*                    LISTEN     
tcp4       0      0 *.8443                 *.*                    LISTEN     
[23.09.1-RELEASE][admin@sg4860.home.arpa]/root:

Mine listens on 8443.. Since you reset to 80 you should see it listening on 80

you should see nginx running on your port

[23.09.1-RELEASE][admin@sg4860.home.arpa]/root: sockstat | grep :8443
root     nginx      23204 5   tcp4   *:8443                *:*
root     nginx      23204 6   tcp6   *:8443                *:*
root     nginx      22940 5   tcp4   *:8443                *:*
root     nginx      22940 6   tcp6   *:8443                *:*
root     nginx      22793 5   tcp4   *:8443                *:*
root     nginx      22793 6   tcp6   *:8443                *:*
[23.09.1-RELEASE][admin@sg4860.home.arpa]/root:

rbron01

@johnpoz
Got the same but then with port 80

johnpoz

@rbron01 you don't have the antilock out rule disabled do you and some rule that would block? Or didn't put the blockrfc/bogon on your lan interface?

When your consoled/ssh in, if you run a curl to say loopback, do you get the page?

curl http://127.0.0.1

if I tell curl to just don't care about trusting the ssl, i get this for example

[23.09.1-RELEASE][admin@sg4860.home.arpa]/root: curl --insecure https://127.0.0.1:8443
<!DOCTYPE html>
<html lang="en">
        <head>
                <meta name="viewport" content="width=device-width, initial-scale=1">
            <link rel="stylesheet" href="/vendor/bootstrap/css/bootstrap.min.css" type="text/css">
            <link rel="stylesheet" href="/css/login.css?v=1701893452" type="text/css">
                <title>sg4860 - Login</title>
                <script type="text/javascript">
                        //<![CDATA{
                        var events = events || [];
                        //]]>
                </script>
        <script type="text/javascript">if (top != self) {top.location.href = self.location.href;}</script><script type="text/javascript">var csrfMagicToken = "sid:28ec30f520e1d8cf9085d5f5bd6398cca1521f01,1714682436;ip:9e433f3ab86fa2f558df408437777ed99de1cad1,1714682436";var csrfMagicName = "__csrf_magic";</script><script src="/csrf/csrf-magic.js" type="text/javascript"></script></head>

        <body id="login" >
                <div id="total">
                        <header>
                                <div id="headerrow">
                                        <div class="row">
                                                <!-- Header left logo box -->
                                                <div class="col-sm-4">

If that is working, that says hey httpd is serving up the page, but for some reason your client is not getting there, it for sure is listening for example.

rbron01

@johnpoz
I get a page back. However when I connect direct a laptop on the port nothing happens only the timeout