Can't login to GUI
-
There is a GUI security feature that will lock the gui out under some attack conditions. It self locks for a specific time
-
@JonathanLee said in Can't login to GUI:
There is a GUI security feature that will lock the gui out under some attack conditions. It self locks for a specific time
Really? And where is it configured and how do I know it was invoked?
I did run multiple pings from other countries, so it could be treated as an attack, I guess.
-
If you fail to login 3 times from the same source IP it will get locked out by sshguard. When that happens you won't be able to connect at all. You won't see the login screen. What you're seeing is not that.
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#login-protection
-
@stephenw10 I learned that the hard way :)
-
@stephenw10 said in Can't login to GUI:
If you fail to login 3 times from the same source IP it will get locked out by sshguard. When that happens you won't be able to connect at all. You won't see the login screen. What you're seeing is not that.
https://docs.netgate.com/pfsense/en/latest/config/advanced-admin.html#login-protection
Does it expose any GUI level option?
thx it's great!
-
@chudak said in Can't login to GUI:
Does it expose any GUI level option?
Not sure what you're asking there?
There are tuning options for it in the GUI. You can whitelist IPs to prevent them being blocked.
-
@stephenw10 said in Can't login to GUI:
@chudak said in Can't login to GUI:
Does it expose any GUI level option?
Not sure what you're asking there?
There are tuning options for it in the GUI. You can whitelist IPs to prevent them being blocked.
Where please?
-
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.
