WebGUI no longer works; login page never displayed
-
After adding two more interfaces to an existing pfSense 2.5.2 installation and rebooting, I lost access to the WebGUI. Nginx receives the login request as seen in the logs, but the browser never receives a reply.
The nginx log also reports this file is missing: /usr/local/www/auth/discovery
I don't see any more relevant errors.
pfSense seems to be working properly in all other respects.
Thanks in advance for any help.
Shupi
-
@shupiluliuma said in WebGUI no longer works; login page never displayed:
After adding two more interfaces to an existing pfSense 2.5.2 installation
Hi,
This is perfectly normal behaviour if we are talking about, say, installing a two-port NIC +++ to box.
In this case, the driver names will be revised, shifted, say to what has been igb0, it is possible that igb2 will be...
so the default LAN interface (web gui access) will also be assigned to another interface...
you can easily find this out by shell access and editing the .xml file - things can be put rightnext time before you install a new NIC, pls. edit the .xml!
-
@daddygo Thanks for the pointer, but I think I will need another push. I assume the xml file you referred to is /cf/conf/config.xml.
Currently there is no data in the file that would pin the WebGUI to an interface.
The CLI login page shows the interfaces are properly configured as well as one of the two new ones I added. But when I run 'ifconfig -a" the LAN interface is not displayed and the command hangs and ^C will not kill it. Are there more problems than the obvious here?
Anyway, is there a guide to the config.xml file that will tell me where to put the entry for the GUI's default interface?
Thx
-
@shupiluliuma said in WebGUI no longer works; login page never displayed:
Currently there is no data in the file that would pin the WebGUI to an interface.
that's not what I'm saying
I mean the name of the network interface device driver, as igb, ixl, etc.
these are sorted by FreeBSD according to a certain system (MAC, etc.), if you insert (install) a new PHY later, it may upset the order...
otherwise the LAN interface is the basic WebUI interface, which in the case of a 4-ports Intel I350 NIC, for example, on the first installation, is...
igb0 = WAN
igb1 = LANthe rest are OPT interfaces, but they are not deffiniated at first time (only WAN/LAN), you can do it manually from the "shell" before the first startup or later via WebUI
yes the config.xml is the one to edit in this case, before you switch on the box with the new network interface installed....
(pls. forget the default WebUI definition, it's LAN + Anti-Lockout Rule)like this:
-
Hey DaddyGo. Thanks for more input.
I should have been clearer in my responses.
My original post mentioned that the FW was working properly after the addition of the dual NIC adapter. I knew the MAC's of the interfaces so when the FW booted after the NIC's were added I knew which one was which and made the proper assignments when asked at boot time.
Immediately after the upgrade, the GUI was working; then after some time, it stopped. I suspect I made a change that did that, but lost track of what I had done. I may have set the OPT1 interface to 192.168.1.1 (Default LAN ADDR) which maybe would have locked out the LAN interface from the GUI. Dunno.
Except that the GUI was listening on the LAN interface, accepted the incoming connection, but could not find the file /usr/local/www/auth/discovery causing the connection to time out.
I finally decided to start clean today and installed 2.6 with no problems other than my sorry brain.
I am up and running but have not solved the problem of accessing a video PVR on OPT1. I can ping it from pfsense and from a laptop on the OPT1 subnet, but I cannot ping it from the LAN despite allowing everything from LAN to OPT1 including all types of ICMP.
I used to be a Cisco FW admin, third class, so I know the basics. pfSense may be a bit opaque to me still.
I am good for now unless you want to suggest a couple rules to get access to OPT1 working. No need to waste your time though.
Thank for the XML snippet too.
- Shupi
-
@shupiluliuma said in WebGUI no longer works; login page never displayed:
I cannot ping it from the LAN despite allowing everything from LAN to OPT1 including all types of ICMP
Does the device in OPT1 have the pfSense as its gateway? Does its firewall allow ICMP from outside its subnet?
-
@shupiluliuma said in WebGUI no longer works; login page never displayed:
I am good for now unless you want to suggest a couple rules to get access to OPT1 working. No need to waste your time though.
It is by no means a waste of time, personally I am always happy to have a new member in the team, greetings to you again.Now what you wrote makes sense to me :), at first I thought you'd locked yourself out of the box, which is not easy to do as there are protections for that,... Anti-Lockout Rule on default access interface (like LAN,.. for me f.e.: MGMT), here SSH and WebUI access is guaranteed with this rule.
Any questions feel free to ask, there are many of us here who are happy to help.
To clarify this OPT1 thing a bit, you want to access a device on another physical interface?
I'll show you an example of ATA modem access that has a different interface this is a simple rule (ok I don't use it much "0/0B", but it works when I need it):
BTW2:
you can PING from the firewall itself to any interface, so this is not a relevant test in this case, unless you want to know if the device is alive, and yeah PING between interfaces is another step...
-
Thanks again for your input.
Well, I have looked at so many rules, including yours, without seeing what I might be doing wrong that I decided to have a look at the interface setup. Thar she blows!
The mask on the interface was set to /32 instead of /24. I either missed the setting or messed up the selection and didn't notice.
So I think I am on my way. There is a PVR on that segment which runs on port 9222 and it came right up after installing the appropriate rule.
Many thanks.
Shupi -
@shupiluliuma said in WebGUI no longer works; login page never displayed:
The mask on the interface was set to /32 instead of /24. I either missed the setting or messed up the selection and didn't notice.
nothing serious has happened, you just ran over it, it happens, by default the GUI offers /32 and if you don't watch it well, this could be the problem.... :)
