Hardcoded port config in EmbyServer service configuration

[stwarr 1]

The service config file (EmbyServer.sc) hardcodes the default ports that synology/Emby is expected to use (http:8096 / https:8920), but these values have no connection to the ports that are actually assigned in the Emby Dashboard/Network UI page.  Consequently, synology/DSM reverse proxy always reports that ports 8096/8920 are unavailable, regardless of the actual Emby configuration.

/var/packages/EmbyServer/target/EmbyServer.sc contents:

[EmbyServer]
title="Emby Server"
desc="Emby Web UI"
port_forward="yes"
src.ports="8096,8920/tcp"
dst.ports="8096,8920/tcp"

 

[Luke 43375]

Hi, the UI doesn’t let you change it though, right?

[stwarr 1]

Hey Luke,

The UI presents the fields - 'Public HTTP port number' and 'Public HTTPS port number'.  It allows the user to enter new values (ie. these fields are editable), and the UI won't allow the fields to be blank.  However, after a bit more poking around, it looks like these only control the 'external' port passed to the automatic UPnP mapping (even though I have that feature disabled).  AFAICT, changing those values has no functional purpose otherwise.

What I can confirm from inspecting the host sockets is that with 'Secure connection mode' setting as either 'Disabled' or 'Handled by reverse proxy', the package never activates port 8920 - only HTTP is ever enabled.  I haven't tried loading a certificate (emby intentionally doesn't have access to sensitive paths on my NAS, including certificate locations).

The usecase I have is that I'd like to use the reverse proxy on the NAS (which is more secure than my router) to forward inbound HTTPS traffic on port 8920 to local HTTP on 8096, and to activate HSTS (something my router can't do). The only thing preventing me doing this is the EmbyService.sc file, which seems to be telling the Synology nginx reverse proxy that the emby package is using port 8920, even though it isn't.  Of course I can work around this by hacking the file (presumably until the next upgrades breaks it) or by mapping a different port and have my router NAT present 8920 to the outside world, but would be nice to have a properly working setup  .
 

FYI - the trigger here is that I'm seeing much more scanning/probing of my router ports than I have in the past, and I'm in the process of locking everything down.

 

 

[Luke 43375]

You can set the public facing router ports in network settings but the local port numbers are not configurable in our synology package. If they’re not configurable then it shouldn’t be a problem that they’re hardcoded in the manifest.

[stwarr 1]

It’s hardcoding a value that it’s not using, and therefore preventing the correct reverse proxy setup on the NAS.

[Luke 43375]

Right OK. I think what we need to do is take away the configuration from the Emby Server UI and just have the port numbers be passed in by the Synology service configuraiton.

[stwarr 1]

If UPnP is disabled, the UI fields definitely appear to serve no useful purpose. 

As to the synology service configuration - is Emby picking this up and adjusting its port numbers based on this (ie. is it intended as a user configuration point?) or is it just a declaration to DSM of what resources the Emby package requires to run?  If the latter, then I think it should only contain port 8096 and not 8920.

[Luke 43375]

1 hour ago, stwarr said:

If UPnP is disabled, the UI fields definitely appear to serve no useful purpose. 

 

No because you could still configure manually in your router via port forwarding. The server needs to be aware of it's remote address so that it can report it to Emby apps. So when upnp is enabled, that's the only function that the remote port values have.

[stwarr 1]

Quote

No because you could still configure manually in your router via port forwarding. The server needs to be aware of it's remote address so that it can report it to Emby apps

But surely, with UPnP disabled and with manually configured port forwarding/remote proxies etc, any port Emby that is told about is purely advisory and has no canonical meaning? You are simply assuming that the user has a particular default setup.

For example, I have external port 8096 forwarded across my router to port 8095 on my Synology. The Synology reverse proxy applies HSTS to this (ie. ensures that all WAN connections are automatically upgraded to https), then forwards as regular http to Emby running at localhost/8096. From a network perspective, this config works really well and aligns with various other applications i run on my NAS. Initially I tried to run the LAN traffic between my router and NAS on port 8920 (ie. the Emby/https default port), but even though the Emby app isn’t actually binding to that port, the Synology service profile says that it uses that port, and the reverse proxy refuses to let me use it, with is why I ended up with arbitrary 8095.

But now inside the UI, Emby insists that the public (ie. WAN) http/https ports must be populated and must be different. AFAICT, these values only serve the purpose of displaying a connection address at the top of the admin page. Because of the UI logic, with my setup, I am guaranteed that the displayed WAN access address will always be incorrect.

[Luke 43375]

Emby will bind to port 8920 if you configure ssl inside Emby server. 

i see what you’re saying but if we don’t list the port in the manifest then the server will be denied permission to use it when a user tries to configure it.