Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Lost WebGui Access after upgrade

    Scheduled Pinned Locked Moved General pfSense Questions
    22 Posts 3 Posters 3.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • GertjanG
      Gertjan @ashima
      last edited by Gertjan

      @ashima said in Lost WebGui Access after upgrade:

      rc.restart_webgui: creating rrd update script

      Is it to do with corrupt rrd.

      The message "rc.restart_webgui: creating rrd update script" is normal.
      It's not really creating the rrd update script file, it's just assuring that one exists.

      Why do you think something is corrupt ?

      edit : ok, already answered

      No "help me" PM's please. Use the forum, the community will thank you.
      Edit : and where are the logs ??

      1 Reply Last reply Reply Quote 0
      • A
        ashima LAYER 8 @Gertjan
        last edited by

        @Gertjan I have no web access. I don't know how to enable Log errors from web server process using command line.

        GertjanG 1 Reply Last reply Reply Quote 0
        • A
          ashima LAYER 8 @stephenw10
          last edited by

          @stephenw10 Yes, I tried from different browsers and also from different clients.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            Is 172.16.1.2 the client you're testing from?

            Are the nginx logs you do see current? Do you see new entries each time you try to access the page?

            Do you have any port forwards on the firewall for port 443 that might be redirecting requests?

            A 1 Reply Last reply Reply Quote 0
            • A
              ashima LAYER 8 @stephenw10
              last edited by

              @stephenw10

              1. Yes, I am accessing firewall over vpn. 172.16.1.X is tunnel network.
                I get the same issue when I try to access from local device.

              LAN is 192.168.37.X

              1. Yes the nginx logs are current with correct time stamp. Yes I see a new entry every time I try to access the webgui.

              As suggested by @Gertjan I tried using curl -k -f 127.0.0.1 and curl -k -f 192.168.37,1 I see an entry in nginx log instantly.

              1. No port forwards. I access the network frome remote only via openvpn.

              Is there any other thing that I need to check.

              1 Reply Last reply Reply Quote 0
              • GertjanG
                Gertjan @ashima
                last edited by

                @ashima said in Lost WebGui Access after upgrade:

                I don't know how to enable Log errors from web server process using command line.

                Of course. Stupid me.

                Type
                viconfig + enter
                /<syslog> + enter

                Now you'll see the content of the block <syslog> ...... </syslog> which contains the syslog settings.
                if there is a line (probably the last in the block) :

                <nolognginx></nolognginx>
                

                then place the cursor on that line, and type

                dd
                

                and then
                ESC (the key on the keyboard, top left) and

                :wq
                

                Now you've existed viconfig.
                Exit the command line, your back in the console menu. restart the webConfigurator = option 11.

                But I presume the web server (webConfigurator) isn't doing anything wrong here, it's working just fine. No need to do this 'viconfig' manipulation.

                To check - just to have a look - your firewall rules :
                Same thing :

                viconfig
                

                and search for <filter> :

                /<filter>
                

                if you do not see this :

                2bc58ea8-9a54-4186-a393-d90d569ca2e5-image.png

                then type n for next :

                n
                

                Now you see your wan firewall rules lisrted in detail, one by one.
                After wan, you have the lan firewall rules.

                Btw : you can also see the rules here :

                cat /tmp/rules.debug
                

                My firewall LAN rules :
                ...
                pass in quick on $LAN inet6 proto udp from fe80::/10 to ff00::/8 port 5352 >< 5356 ridentifier 1607406256 allow-opts keep state label "USER_RULE: Pass link local multicast traffic => 5353/5" label "id:1607406256"
                pass in quick on $LAN inet from 192.168.1.0/24 to any ridentifier 1576252665 keep state label "USER_RULE: Years of investigation was needed to find this rule." label "id:1576252665"
                pass in quick on $LAN inet6 from 2a01:cb19:907:a6dc::/64 to any ridentifier 1670835584 keep state label "USER_RULE: This one was found faster." label "id:1670835584"
                ....

                The GUI identical part :

                ac5df4c8-d3f6-4f64-915c-29239d78f038-image.png

                Your issue is : pfSense web gui traffic, http or https, coming from a LAN based device, doesn't arrive, or is blocked at - the LAN interface, so the web server can react on it.
                It could be a simple blocking firewall rule.

                You can't edit the /tmp/rules.debug file, as it is regenerated from the config.xml file.

                GUI from OpenVPN works, or not ?

                I've been trying to use tcpdump on the command line, with filters for port 80 and destination IP-pfSense and source IP-your-device-on-LAN to check if any web traffic actually reaches your LAN NIC, but I wasn't able to create such a command for myself.

                No "help me" PM's please. Use the forum, the community will thank you.
                Edit : and where are the logs ??

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Mmm, it seems like the firewall rules must be present since the client here sees the cert error. If it was blocked you would not see anything.

                  GertjanG 1 Reply Last reply Reply Quote 0
                  • GertjanG
                    Gertjan @stephenw10
                    last edited by

                    @stephenw10
                    Wow. That's true.
                    Broken browser ? Device with it's own firewall playing tricks ?

                    @ashima : take your phone, or whatever other device, and use that.

                    No "help me" PM's please. Use the forum, the community will thank you.
                    Edit : and where are the logs ??

                    1 Reply Last reply Reply Quote 0
                    • A
                      ashima LAYER 8
                      last edited by

                      Thank you @Gertjan @stephenw10 for sharing so much of info. Good learning experience.

                      I have already tried from 3 different devices and different browsers.

                      Well I have sent a replacement firewall at the location and asked them to sent the old device to me.

                      I guess I am exhausting out of options. Planing to do a fresh install.

                      If any one has more suggestion I am ready to try once I get the firewall before I do a fresh install.

                      1 Reply Last reply Reply Quote 0
                      • A
                        ashima LAYER 8
                        last edited by

                        @Gertjan @stephenw10

                        Thank you for the support. I received the device at my office. So tried all possible commands, but the web gui failed to show up. I also did factory reset to default but that didn't help. Finally I have decided to reinstall the system.

                        1 Reply Last reply Reply Quote 1
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.