Unable to access WebUI on "old" interface

[abite]

I was messing with HTTPS trying to get the WebUI access from outside of my network. Well, that didn't work and it locked me out basically, so I was able to use shell to revert it to HTTP. Now, I can't access the WebUI from the local ip of 192.169.0.33 but I can access it from publicip:81 (HTTP port I set). Now the weird part is when I log into the 9.3 UI I receive this error:

Code:

CSRF verification failed. Request aborted.

You are seeing this message because this site requires a CSRF cookie when submitting forms. This cookie is required for security reasons, to ensure that your browser is not being hijacked by third parties.

If you have configured your browser to disable cookies, please re-enable them, at least for this site, or for 'same-origin' requests.

But when I click "Try the new UI!" or whatever it says I can log in and manipulate things in there just fine...

Also, if I go to localip:81 I get the login screen, but the password doesn't seem to want to work on either the old or new ui?

So my question is this...

1. How can I revert back so I can just access it from the local ip and not worry about the remote UI for now.

 

[Jailer]

FreeNAS is not intended to have the web UI exposed to the internet. Use a VPN if you must administer it remotely.

 

[abite]

Well why is there an option to do so and instructions on the official FreeNAS documentation?

 

[melloa]

Also, if I go to localip:81 I get the login screen, but the password doesn't seem to want to work on either the old or new ui?

Sorry, set my FN 11 to port 81 and still can login. Maybe someone knows how to reset from the shell.

 

[melloa]

Well why is there an option to do so and instructions on the official FreeNAS documentation?

To open the GUI to the internet? Can you point me to it please?

 

[abite]

Maybe someone knows how to reset from the shell

My hopes as well haha

 

[abite]

https://doc.freenas.org/9.3/freenas_system.html#general

Isn't that what the whole first section is about? Setting up HTTP or HTTPS for the WebGUI?

 

[melloa]

https://doc.freenas.org/9.3/freenas_system.html#general

Isn't that what the whole first section is about? Setting up HTTP or HTTPS for the WebGUI?

Gonna look at that later (trying to find how to change the port from the shell ;) ). Look at: /etc/local/nginx/nginx.conf. It will have the port you've setup there. You can change back to 80 to test and restart nginx. Don't reboot the server as it will revert back to whatever is in the middleware database. Access the gui, change to 80 there and will survive a reboot.

By the way ... I just did that on my test fn11 and worked, but can't assume any responsibility for anything going wrong with your server ;)

 

[abite]

I can't access that UI though, When I go to local ip I get a "can't be reached" when I use the localip:81 I get the login screen but incorrect password, and when I go to publicip:81 on the old UI I receive this...

http://imgur.com/a/yWLVG

 

[abite]

Ok so what just happened... As a last resort I restarted the FreeNAS machine. I can now access the webui and login, but everything is gone. Volumes, Shares, Jails, Plugins all gone from the WebUI... How would this have possibly happened from networking?

Update: After importing the volume the jails are back, but plugins are gone along with any settings changes I had made such as shares and such.

 

[melloa]

I can't access that UI though, When I go to local ip I get a "can't be reached" when I use the localip:81 I get the login screen but incorrect password, and when I go to publicip:81 on the old UI I receive this...

http://imgur.com/a/yWLVG

Well ... You can reset to Factory Defaults from the console, but first save your config - if you have setup volumes, shares, users, etc. ssh to the box or drop to the shell from the console and copy it to your volume. It will be /data/freenas-v1.db. After reboot import your volume and restore the saved config.

Edit: Disregard as you've fixed...

 

[Ericloewe]

https does nothing to protect your server from the internet's many dangers. It only serves to:

• Authenticate your server
• Ensure that the connection is not being intercepted or tampered with

It's probably overkill in most local networks, but it's there mostly for bigger networks where there's more interest in locking things down very tightly.