Can't login to GUI
-
In Sys > Adv > Admin. As shown in that linked doc.
-
@chudak said in Can't login to GUI:
The system is back to normal without me doing anything today !!!
So you didn't do anything to fix it? Did you ever find a cause?
I just ran into what seems like the same thing, on one router. GUI log in succeeds ("... /index.php: Successful login for user 'admin' from...") but I can't get past the login page. I can log in via SSH.
I do not see anything useful in system.log or nginx.log, just normal logins and GET/POST. No failed login attempts that I see.
Edit: 24.03
Edit: trying direct URLs (/firewall_rules.php) still shows the login page -
Hmm. From multiple browsers and/or client devices?
-
@stephenw10 said in Can't login to GUI:
Hmm. From multiple browsers and/or client devices?
Well I tried it from a private window in Firefox, and also deleted site/URL cookies in the main window. It does work from Chrome though on my PC. Not sure how that is possible...
Also it works in Firefox if I use a FQDN name, like https://router-building.example.net, or IP address, instead of https://router-building, which I've used for 10+ years.
Edit: closing Firefox doesn't help.
-
Hmm, I've seen that if you have multiple firewalls resolving to the same IP. Like one behind the other with port forwards. You can only log into one at a time.
Not exactly what you describe though....
-
@stephenw10 No port forwarding in use here. There are two nested routers (office and building) but with unique IPs.
Given it is URL dependent, it smells like a cookie problem but a private window or deleting cookies should fix that. I have never seen a different browser work differently than a new private window.
Could there be something on the web server end that doesn't release for a while, yet survives a webconfigurator restart? (OP said it fixed itself overnight...)
-
Yup it sure does feel like a cookie issue...
-
Just for the record, today a Firefox private window lets me log in with the "short name" but the regular browser window still does not. So it changed behavior somewhat.
-
@SteveITS said in Can't login to GUI:
Just for the record, today a Firefox private window lets me log in with the "short name" but the regular browser window still does not. So it changed behavior somewhat.
Have you tried killing all associated states?
-
@chudak said in Can't login to GUI:
Have you tried killing all associated states?
My browser was closed overnight so nothing should be retained that long. I can connect fine, it's just that a successful login (since it doesn't fail) leaves me on the login page. A purposefully failed login shows the expected error message.
The only cookie is the PHPSESSID cookie and deleting that doesn't help.
Obviously it's not a problem if I can log in with the IP or longer name, just weird. I suppose I could try restarting the router, but would need to do that late some night.
-
FWIW, restarting the router didn't help.
-
I'll start over :
When you use http://192.168.1.1/ you have access.
When you use http://pfsense.something.tld/ you see an error.Check this :
nslookup pfsense.something.tlddid you get back 192168.1.1 ?
Also an IPv6 ?You were using certificates ? Auto signed ? Known CA signed ?
Is/ was this certificate using HSTS ?What browser ? Browser DNS settings ? Browser extension ?
When trying to access, run this in a console or SSH :
tail -f /var/log/system.log /var/log/nginx.log -
@Gertjan said in Can't login to GUI:
When you use http://192.168.1.1/ you have access.
When you use http://pfsense.something.tld/ you see an error.Not quite.
I can log in using the IP.
I can log in using router-building.something.tld.I cannot log in using just "router-building"...no error but I can't get past the login page.
DNS is fine since I have the router backgrounds color coded.
pfSense self-signed cert.
There's no IPv6 returned for either name.
Firefox. As noted above other browsers work and (after waiting overnight that day) a Firefox private window now works.
Logging shows only the expected GET and POST requests, and "php-fpm[29026]: /index.php: Successful login for user 'admin' from: x.x.x.x (Local Database)" even though I stay on the login page.
It's weird because it's both relatively new and easily worked around. We replaced this router maybe a year ago so it's not like it's a new install. And I first noticed it last week meaning it's new since Dec. 12 which is the last config I saved.
And just to clarify it's specific to this router, notably not our office's router.
-
@SteveITS said in Can't login to GUI:
I cannot log in using just "router-building"...no error but I can't get past the login page.
When I fire up a bowser and type just this + enter :
it will shows this :
I presume the browser correctly, presumes that I wanted to search for the term 'pfsense' as 'pfsense' by itself is an invalid URL.
Btw : while typing pfsense, my browser will auto complete to form a possible correct URL :
Using just this :
@SteveITS said in Can't login to GUI:
"router-building"
can't be right as "router-building" isn't listed like "router-building" in the certificate used by pfSense.
"router-building", like my "pfsense" is an invalid URL.Anyway, I'm still a bit puzzled why you would see a login pfSense page - so DNS resolving went fine - but you can't login.
Check with browser dev tools to see what it is posting to the server ?Did you have a look at the /var/log/nginx.log (web server log).
Ask it to show more details here (log settings page) :
-
@Gertjan said in Can't login to GUI:
can't be right as "router-building" isn't listed like "router-building" in the certificate used by pfSense.
"router-building", like my "pfsense" is an invalid URL.Windows will resolve partial hostnames even if "dig" will not. It appends the configured default domain to the query. If you enter "https://pfsense" instead, your browser shouldn't search for that as a search string.
The cert fails validation but as a self-signed cert it fails for any other hostname anyway.
Errors are logged already, there just aren't any.
To be clear I don't really think this is a pfSense issue, but I have no idea what could be causing it. It was fine for a decade or more and then stopped working. The PHPSESSID cookie value does change between logins, but that happens using other hostnames also.
I guess I'll let it sit a while and use other hostnames, maybe it will fix itself like it broke itself.
-
@SteveITS said in Can't login to GUI:
Windows will resolve partial hostnames even if "dig" will not.
Yeah, right (
)
When you do a nslookup and you type in "facebook.com"
it will do an initial DNS request like like www.facebook.your-local-domain.tld. first (you can see this one it in the DNS pfSense logs).
It took me a while (years actually) before I got it : asking for "facebook.com" is wrong
A host name 'must' end with a dot, so when I ask for "facebook.com." (you saw the ending dot ?) the local domain part will not be added. nslookup can correct us ^^@SteveITS said in Can't login to GUI:
The cert fails validation but as a self-signed cert it fails for any other hostname anyway.
Well, h#ll no, you are the boss, not your bowser.
The Johnpoz story (he has some good posts about this subject) goes like this : when you create a certificate for your pfsense on your pfSEnse, you have to create your own CA first.
Then you make your cert (thrown in all the good host names while doing so !!) in it, and have it signed by your pfSense created CA.
And yes, your browser doesn't know, so doesn't trust, your pfSense cert, as it doesn't know the signing CA.
With one click you can change that ! ( this is the boss action )
You can export the CA from pfSense and import it into your PC, into the PC cert store.
And from now on, your browser will trust your self signed certificate.( START : or go the official way : rent a domain name. Use it for your internal pfsense network use. Get a certificate for, this domain name, with the help of Lets-encrypt) and use this certificate for your pfSense GUI, and why not, all your other GUI based other LAN devices.
No more certificate errors errors - everything automated.
True, this is not free, neither very KIS, but as I have to host a captive portal as a hotel, and http site can't be used anymore, I had to have a trusted https server anyway (the captive portal web server) so I had to get my hand on a trusted certificate anyway END ) -
@Gertjan said in Can't login to GUI:
The Johnpoz story
He posted his 'story' just a couple of minutes ago : https://forum.netgate.com/topic/195900/ssl-certifications-not-trusted-on-my-system/41?_=1736352508256
-
FWIW upgrading to 24.11 didn't change this behavior. Private window still works. It remains a mystery.
