MineOS WebUI behind Nginx reverse proxy

Connectivity
1

Sooo, I’ve been sitting here for the past bit trying to setup my WebUI so that I can access it externally from the same subdomain that my MC server runs on, using Nginx to proxy web traffic to the MineOS server, so it doesn’t end up going to one of my other sites.

I’ll try and give a comprehensive overview of my setup, and what I’ve tried so far.

I use Nginx in order to send traffic to correct server on my internal network. Currently it proxies three different sites, Gitlab, Subsonic (music/media), and personal site, each running off of their own VM. I would like to add the MineOS WebUI to this list, so I’ll be able to access my WebUI by just going to ftb.example.com in my browser.

As of right now, I’ve tried creating a vhost for Nginx, that will proxy the data. This is my current configuration, obviously my Nginx host is 192.168.1.50, and the MineOS server is 192.1.168.1.54 (Running the Turnkey version btw). I copied this configuration from my existing Gitlab server, and modified the necessary parameters, the reason why there are some commands commented out is because I tested the config with just the proxy_pass command, as all I really want is to have ftb.example.com go to https://192.168.1.54:8443. Neither works.

So I figured it had something to do with https and/or ports, I changed /etc/mineos.conf to read use_https = false and socket_port = 80. After changing the Nginx config (proxy_pass https://192.168.1.54:8443 --> proxy_pass http://192.168.1.54), it’s still a no go, opening ftb.example.com just redirects straight back to example.com (as it’s listed as the default vhost). Uncommenting all the proxy header commands doesn’t do anything either.

All this leads me to believe I’m either doing something completely stupid, or there’s an issue somewhere in the WebUI (maybe the NodeJS server?). The exact same config file for Nginx works with both Gitlab and Subsonic, so I’ve got no idea why it wouldn’t work for MineOS too.

If you haven’t abandoned ship from the wall of text yet, then thanks! Hopefully the information provided is useful in coming to a solution. Please feel free to let me know if you need any addition information, such as my CloudFlare or PfSense setup, which may also be factors in all this.

Thanks in advance to anyone who is willing/able to help!

2

Alright, so I think I’ve got the first part of this solved, I can now proxy ftb.example.com to my WebUI, all I had to do was remove the /admin/ off of the proxy_pass. I think that’s what it was anyways, as I while I was playing, I removed it and it worked, putting it back broke it again.

However, as I’d like to have the WebUI protected with HTTPS, but not from MineOS (wouldn’t be able to proxy if I did that), I’ve setup Nginx to do a crap ton of redirects (including HTTP --> HTTPS) so that I can use my CloudFlare SSL cert. ftb.example.com cannot have CF enabled, as then MC won’t connect, so I’m using a 301 redirect with Nginx to go to mineos.example.com, which is CF enabled, allowing me to use the SSL cert from them. After all the redirects, the user will eventually end up at https://mineos.example.com. However, this does not present me with the WebUI, and rather the entry for default_server on Nginx. I believe this is because I have mineos.example.com with CF enabled, which could be causing some problems, which I still think could be because NodeJS is the webserver, instead of a traditional server (Apache, Nginx, lighttpd, etc).

I would greatly appreciate it if anyone would be able to help me figure this out! :slight_smile:

3

It seems if you’re doing a “crap ton” of redirects, that maybe it’s more complicated than it needs to be?

server {
  listen 192.168.1.50:80;
  server_name ftb.example.com;

  location / {

  # proxy_pass_header Authorization;
    proxy_pass https://192.168.1.54:8443/admin/;
  # proxy_set_header Host $host;
  # proxy_set_header X-Real-IP $remote_addr;
  # proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
  # proxy_http_version 1.1;
  # proxy_set_header Connection "";
  # proxy_buffering off;
  # client_max_body_size 0;
  # proxy_read_timeout 36000s;
  # proxy_redirect default;

 }
}

It seems that you shouldn’t be listening on 80, if ultimately you want to end up using SSL anyway. In other words, (even though I know this isn’t your most recent config), basically if you’re forwarding it’s not the same thing as nginx seeing it as a normal server host.

Perhaps try with listen 443 ssl from the start. Don’t rely on you/users to type in HTTP and get corrected, just make sure you go straight to the correct protocol HTTPS to start.

Otherwise, there’s always:

if ($scheme = http) {
        return 301 https://$server_name$request_uri;
    }

I’ve similar directives for things like this, too:

proxy_pass https://localhost:8443;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $http_host;
proxy_redirect off;
4

Currently I have this as my nginx config (each server{}` block is in a different file), that way if a user goes to the HTTP version of either subdomain or even the https version of ftb, they get redirected to the HTTPS of mineos. This was just the best way (that I know of) to get a user to the place I want them, I’ll have to look at redirecting based on scheme, though I doubt it will make a difference, as it doesn’t appear that the redirects have anything to do with my not being able to access the interface.

5

I’ll take a look at seeing how to reproduce this. In the meantime, have you ever just tried putting the SSL cert directly in /etc/mineos.conf and not putting it behind nginx at all?

6

Both HTTP and HTTPS work just fine behind Nginx, it’s when I enable the CloudFlare services (CDN/Proxy, DDoS protection, caching, etc) that I can’t access the WebUI. I understand that this may be beyond the scope of support you’re willing to provide, I just figured I might as well try to get assistance with it, as all my other sites work just fine behind CF.

This weekend I’ll look into the causes of the issue, which I believe may be the fact that MineOS uses NodeJS for the WebUI. I’ll setup my own basic NodeJS webserver, and see if that works. However, just to eliminate all possibilities, I can temporarily change the NAT rules in PfSense to direct traffic on port 80 and 443 to the MineOS server (with the SSL cert), and try accessing it through the CF subdomain then.

Thanks for your help so far!

7

So after some initial playing around, I decided to take your advice and try the WebUI without the Nginx proxy. I found that the WebUI will work behind CloudFlare CDN. What I did was just change the entry for port 443 in PfSense to direct to port 8443 on the MineOS server, rather than the proxy server. (meaning that all HTTPS traffic on any subdomain would be directed to the MineOS server. This is the desired result (albeit not on all subdomains). However, after reverting the ports back, I’m left with the root of my domain (example.com) redirecting to example.com/admin/index.html rather than the proper index.html of the site. Cleared cache on browser, tried a different browser, tried a different internet connection all together, still trying to redirect to the WebUI. I can get the actual site content if I specify the URI of the content (eg example.com/index.html gives the proper main page for the site, but example.com won’t). Hopefully this is just a temporary issue while Cloudflare/PfSense/Nginx figures their shit out. (Just checked, mineos.example.com and ftb.example.com still both redirect to the main site’s content, except they access the index.html fine. They’re doing to root domain’s job better than the root domain is!)
UPDATE: This is now working fine, it no longer redirects to where the WebUI would have been. Dunno what the issue was caused by, but I’m glad it’s working again.

So now the question is: Why will the MineOS WebUI work behind CloudFlare, and work behind Nginx, but not both? Who is to blame? Is it me, have I don’t something stupid? I thought I understood how this sort of stuff works, but I guess I don’t understand it that well.

1 Like