[Solved] Lots webgui, page doesn't load



  • Hi!

    Been happily running pfsense for 2 months now and had no problem. Using pfsense as a CA, with https, DHCP, firewall of course and overall really a breeze. Currently only 2 interfaces are configured: WAN and LAN.

    Since yesterday the webgui page no longer comes: 1st time it came back after a reboot, this no longer works however.
    It seems I've lost the gui while I was in Firewall - NAT looking at adding forwarding rules (everytime) but those rules never got a chance to be saved: the gui died before.

    Everything still works 'perfectly', I can ping both IP and hostname of the firewall (running on a protectli box), a curl of port 80 gives me the page content which says basically 301 Moved Permanently & Server: nginx, a curl to port 443 simply times out.

    Any idea what's wrong and how to fix that?

    Thank you. very much.

    Fred



  • If you can shell or console to the box, try running 16, then 11 from the menu.



  • @dotdash said in Lots webgui, page doesn't load:

    If you can shell or console to the box, try running 16, then 11 from the menu.

    Before that, first option 8.

    Then

    ps ax | grep 'nginx'
    

    to see in what state nginx is - is it there ? Gone ? Zombied ? overloaded ?

    and

    ps ax | grep 'php'
    

    for the PHP part.



  • Hi!

    Thank you for the prompt responses. So yes both php & NGINX are running and 16+11 didn't fix the problem: the web configurator is still timing out :(

    I copy below the steps for clarity:

    [2.4.4-RELEASE][admin@fw.local.lan]/root: ps ax | grep nginx
      342  -  I     0:00.70 php-fpm: pool nginx (php-fpm)
      343  -  I     0:00.21 php-fpm: pool nginx (php-fpm)
    43014  -  Is    0:00.00 nginx: master process /usr/local/sbin/nginx -c /var/etc
    43220  -  I     0:00.00 nginx: worker process (nginx)
    43378  -  I     0:00.00 nginx: worker process (nginx)
    43715  -  I     0:00.00 nginx: worker process (nginx)
    43942  -  I     0:00.00 nginx: worker process (nginx)
    44228  -  I     0:00.00 nginx: worker process (nginx)
    94218  -  I     0:00.13 php-fpm: pool nginx (php-fpm)
    81250  0  S+    0:00.00 grep nginx
    [2.4.4-RELEASE][admin@fw.local.lan]/root: ps ax | grep php
      341  -  Ss    0:00.02 php-fpm: master process (/usr/local/lib/php-fpm.conf) (
      342  -  I     0:00.70 php-fpm: pool nginx (php-fpm)
      343  -  I     0:00.21 php-fpm: pool nginx (php-fpm)
    84597  -  S     0:00.42 /usr/local/bin/php_pfb -f /usr/local/pkg/pfblockerng/pf
    85115  -  I     0:00.27 /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfbloc
    85208  -  I     0:00.27 /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfbloc
    85371  -  S     0:00.39 /usr/local/bin/php -f /usr/local/pkg/pfblockerng/pfbloc
    94218  -  I     0:00.13 php-fpm: pool nginx (php-fpm)
    84185  0  S+    0:00.00 grep php
    

    Any other hint as to what may be happening to me?

    Thank you.

    Fred



  • ok replying to myself and letting people know. Since I had to enable SSH to do all of the above I can now happily ssh in and check things.

    As I enabled backup before, I simply SSH'ed in and restored the last backup before my fiddlings with port forwarding. I had the following last backups:

    04. 3/19/20 17:23:14	v19.1	admin@xxx.xxx.xxx.xxx  (Local Database)
        /system_certmanager.php made unknown change
    
    03. 3/20/20 09:23:50	v19.1	admin@xxx.xxx.xxx.xxx (Local Database)
        Firewall: NAT: Port Forward - saved/edited a port forward rule.
    
    02. 3/20/20 09:26:39	v19.1	admin@xxx.xxx.xxx.xxx (Local Database)
        /firewall_nat.php made unknown change
    
    01. 3/20/20 11:17:46	v19.1	admin@xxx.xxx.xxx.xxx (Local Database)
        Firewall: NAT: Port Forward - saved/edited a port forward rule.
    

    And all is back to normal (for) now.

    I know it's been a bit short but for some reasons I feel it fixed the problem as the problem only happened while I was adding/editing those rules.

    So thank you very much for helping me out!

    Fred



  • Typically, NAT rules always 'start' intercepting incoming traffic on the WAN type interface.
    You never (should) use that interface to interact with your pfSense GUI.

    A classic NAT rule :

    a14055ea-94e4-429b-b922-1940a610a0cb-image.png

    (the last 2 are exceptions, not created by me but the pfBlcoker-NG package)

    My NAT rule accepts traffic from the Internet, from a device I call "SYS" (SYS is an alias with some IP's to my LAN based device called Diskstation, using port 22 (SSH). It's my anti-cloud backup system.

    It would be very common to redirect WAN interface port 443 and 80 traffic to some LAN based web server : the pfSense GUI would still be accessible. Because you initiate connections from LAN.

    As you might have figured out : when editing/making rules for the firewall, open also a SSH ("console") windows.
    If the GUI thing "breaks", you have a second access to restore your settings.



  • @Gertjan Yes I think my port forwarding rules broke something but somehow it didn't break just after saving it (or applying it?), only a few minutes later.

    Also my rule was set on the LAN interface as I was trying to redirect a https port from 1 machine to a different port on that same machine. Turns out I simply edited the web server config on that machine and fixed the issue (didn't know it was possible as it's a very limited and unknown webserver). I'd still be happy to have a http to https redirect which apparently the web server cannot do but it's really not an issue per se.

    Anyway good lesson for me, and I am used to make backups of everything ;-)

    Thank you again.
    Fred



  • @bfred said in [Solved] Lots webgui, page doesn't load:

    it didn't break just after saving it (or applying it?)

    What you saw was the proof of having a stateful firewall.
    Initial connections going trough the firewall rules are matched with the firewall rules, top to bottom.
    If one rule matches as a "pass", a firewall state is created, and subsequent traffic bypasses the firewall, because it's known as accepted. This accelerates a lot traffic throughput.
    As long as you do not edit the initial matching rule, the state keeps up. Even when you add or edit a rule above your initial rule that would block such a connection.
    To really apply new rules that do not "seem to work right away" you have to manually reset the states, or, same thing : reset the firewall as does a reboot.

    See Diagnostics > States > States and Reset States.

    @bfred said in [Solved] Lots webgui, page doesn't load:

    https port from 1 machine to a different port on that same machine

    A device on the Internet ?


Log in to reply