nginx reverse proxy, legacy UI works but Material doesn't

[jsherm101]

I'm using an nginx reverse proxy to route traffic from a nas.mydomain.com subdomain to my FreeNAS admin panel.

The local IP address for the NAS is 192.168.1.5 so I have the reverse proxy passing the subdomain to http://192.168.1.5:80 like so:

Code:

}
		server {
				listen 80;
				server_name nas.domain.com;
				location / {
				proxy_pass			  http://192.168.1.5:80;
				}
}
}

(There's also one for HTTPS on port 443. I used to have some set_header commands but they didn't seem to make a difference so I removed them for now.)



Whenever I try to connect on HTTP or HTTP (my server config is set to http+https) this is the error message I get: "Connecting to NAS... Make sure the NAS system is powered on and connected to the network"

the URL correctly redirects to /ui/sessions/signin, but gets stuck here and the material UI never loads.

However, loading the legacy UI URL (/legacy) on HTTP works. on HTTPS, I get hit with a "CSRF verification failed. Request aborted." error upon login.

Any ideas?

 

[m0nkey_]

Word of warning, you don't want to expose the UI to the Internet. There are likely holes in the UI which could be compromised. It's recommended to keep FreeNAS behind a firewall.

The new UI requires more than just HTTP and HTTPS. There are other components it needs to talk to. Opening these up means even more holes.

You're better off setting up a VPN to remotely manage your FreeNAS server.

 

[jsherm101]

Word of warning, you don't want to expose the UI to the Internet. There are likely holes in the UI which could be compromised. It's recommended to keep FreeNAS behind a firewall.

The new UI requires more than just HTTP and HTTPS. There are other components it needs to talk to. Opening these up means even more holes.

You're better off setting up a VPN to remotely manage your FreeNAS server.

That makes sense. Good point. I will use a VPN instead.

 

[Steve Dowling]

I agree with m0nkey_ on not accessing your FreeNAS UI remotely but I am using nginx internally to add a let's encrypt cert to all of my internal sites and this works for me:

Code:

	location / {
		proxy_pass				  https://10.1.1.2:443/;
		proxy_buffering			 off;
		proxy_set_header			 Upgrade		 $http_upgrade;
		proxy_set_header			 Connection		 "Upgrade";
		proxy_set_header			Host			$host;
		proxy_set_header			X-Real-IP		 $remote_addr;
		proxy_set_header			 X-Forward-For	 $proxy_add_x_forwarded_for;
	}

I realise this isn't really needed on an internal network but I wanted to play with nginx and let's encrypt. I also know that I can add a cert from my FreeNAS CA but this way I don't need to worry about new devices trusting the CA.

 

[glauco]

Thank you Steve, this worked for me!
I'm going to dig into nginx as a reverse proxy to find out exactly which proxy_set_header directive/s did the magic.

 

[Steve Dowling]

I've moved on to using let's encrypt directly on FreeNAS now using @danb35's excellent
guide: https://forums.freenas.org/index.php?resources/lets-encrypt-with-freenas-11-1-and-later.82/

I still only use a VPN to access remotely but I like having a chance to play around with let's encrypt.

 

[glauco]

Ok... well, I'm glad you like danb35's script!
What I meant, though, is your nginx config is also good for reverse-proxying the new Angular-based FreeNAS UI!