How to proxy to LMS server without serving it publicly?

Since there’s been some recent weirdness with the native Spotify integration, I went looking for alternatives and first tried Mopidy (didn’t work) and then came across this excellent post about using Logitech Media Server with Spotify, and I now have this up and running in an iFrame card, which is outstanding. But… I can’t seem to secure it. My use case is:

  • HA core runs on a Mac Mini which also hosts nginx, AdGuard and LMS
  • certbot and nginx handle certificates and a proxy_pass to http: for HA
  • an iFrame for LMS has to run as https since that’s how HA is accessed, but LMS runs without SSL, so that custom port also has an nginx proxy_pass as below

LMS is accessible in an iFrame only as long as I open the custom port on the router. Which makes this publicly accessible:
https://sitename.duckdns.org:{custom_port}
LMS has basic password authentication in the settings, but I turned it on and it does nothing. I tried a bunch of different combinations of server names and nothing would display LMS without the external port open (except a browser on the mini itself).

Frankly this all makes sense now that i think about how nginx is supposed to work, but I’m left wondering how to secure LMS. If everything is running on the same machine on the same LAN, is there a way to tell nginx to proxy internally so only the iFrame has access to the LMS server and not the entire internet?
Relevant server block from nginx.conf at the moment:

    server {
        server_name sitename.duckdns.org;
        listen [::]:xxxxx ssl default_server ipv6only=off;
        root /Users/username/.homeassistant/www;
        ssl_certificate /etc/letsencrypt/live/sitename.duckdns.org/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/sitename.duckdns.org/privkey.pem;
        ssl_dhparam /usr/local/etc/ssl/certs/ssl_dhparams.pem;
        add_header Strict-Transport-Security "max-age=31536000; includeSubdomains";
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;

        location / {
            proxy_pass http://127.0.0.1:9000;
            proxy_set_header Host $host;
            proxy_redirect http:// https://;
            proxy_http_version 1.1;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header Upgrade $http_upgrade;
            proxy_set_header Connection $connection_upgrade;
            proxy_read_timeout 300s;
            proxy_connect_timeout 75s;
        }
    }

Use the lms addon, which works over SSL via ingress.

I would love that, but I’m running core so no add-ons are possible. I found that at one point and couldn’t find a custom component version of it.

No, LMS is written in perl, you won’t find a python version :slight_smile:

But are you really wanting to access lms from outside your lan?

If I don’t forward the port then even clients inside the LAN won’t connect- only the Mini itself (which runs headless anyway). I suppose NGINX only operates on data coming in from outside, but then I don’t know why opening the ports works for internal clients because with AdGuard rewriting my domain name to the server IP, I’m not using hairpin NAT. I can verify that this is the case because my HA instance works fine inside the LAN with external access shut off.

Are you using a domain name to access your LMS server?

I don’t get it. You are only wanting to access LMS in your own LAN. So why not run HA on http (not https) on your LAN, and the LMS iFrame will work no trouble.

Yes, w/ duckdns

I am running HA as http: which works fine internally. NGINX serves it outside the LAN securely using https. Using separate internal & external URLs is a minor problem in the long run but I got used to a universal URL until I wanted to run LMS.

Don’t know if this helps How to deal with non-SSL Panel iframe pages inside SSL Hass.io environment? - #51 by Remko

Well yes, that explains my problem with opening ports- I needed to fix the location directive in NGINX. Thanks for the suggestion Nick.

Unfortunately, as I warned those folks in that string, they’re serving things to the internet that aren’t contained in the HA environment, thus not password protected, and thus anyone (if they could find the URL) could, for example, go to
https://myHAname.duckdns.org/node-red
and mess with my system. If it’s just your Christmas lights, who cares. If it’s your 300,000 BTU garage heater, maybe no.

I guess we’re learning why the admins have http: locked out on secured systems.

While I’m at it- for anyone that finds this that still wants to serve their LMS to https:- yes, I was able to access it in an iFrame, but because of something about local file structure access I just got “No Player”

Node-red though was wide open for anyone to screw with.