Emby via reverse proxy and internal network settings

[FunkadelicRelic 10]

Hi All.

 

I'm new to Emby from Plex and I am just going through the initial configuration on my server. I am using the Docker container on Linux which seems to be working well so far.

 

What I am trying to achieve is the ability to access Emby on a DNS name that resolves to my reverse proxy. I have HAProxy listening on my internal network as well as the external network. When I am on my LAN, I hit the internal listener using https://emby.domain.com. This essentially is internal traffic.

 

Is there a way to allow me to sign in using the PIN feature? Not sure if it is possible as the external name will be the same.

 

In Plex I could define internal network CIDR ranges so they could be treated as 'internal'. Does such a feature exist in Emby.

 

Curious to hear how other people might be doing the same.

[CBers 6766]

Welcome @@FunkadelicRelic.

 

There are a couple of threads on the same topic you could have a read of.

 

https://emby.media/community/index.php?/topic/47508-how-to-nginx-reverse-proxy

 

https://emby.media/community/index.php?/topic/48236-setting-up-emby-behind-a-reverse-proxy-nginx/

[FunkadelicRelic 10]

Thanks @@CBers - and thank you for the quick response! Looking forward to putting it through its paces. I love the local user management - something Plex was seriously lacking.

 

I checked out those links, both seem to be more around the reverse proxy configuration. In my case, the RP is already up and running and the question was more around the ability to use PIN login on local networks when hitting the server via the reverse proxy internally. I think it may not be possible as I'll be using the same external name when I open up the WAN reverse proxy listener.

 

Not the end of the world but would be nice if there is a workaround for it.

[CBers 6766]

If you set passwords for all users, you can set up a PIN for the in-network users.

 

Once the Easy Pin option is enabled, you can leave the PIN blank.

[adrianwi 237]

Do your internal clients even need to touch the reverse proxy?  I've just got mine to connect directly to the server, with just the external traffic through the reverse proxy.

 

Big thanks to the author of this one > https://emby.media/c...x-reverse-proxy as it enabled me to harden my reverse proxy and I'm now getting an A+

[FunkadelicRelic 10]

Fair point @@adrianwi - I guess they don't specifically need to hit the proxy, but one nice benefit is all my SSL certs are handled there, so I can do SSL to RP then RP to Emby on HTTP.

[mastrmind11 717]

But why would you need SSL on your internal network?

[FunkadelicRelic 10]

@@mastrmind11 - I guess it comes down to two things really. 1 - because I can, and 2 - because I like to use the same hostname for access both internally and externally without having different configs on my firewall. All of my internal services use SSL for internal and external access, I just feel more comfortable knowing there is some form of encryption going on, just in case somehow someone gets access to my network and decides to pcap.

 

I've done some further testing with the app on my Android TV and it is a pretty horrific experience having to type a long password on the god awful remote control. I think what I would like to do is set each account PIN to nothing so users can freely switch between accounts when connected locally. Any other thoughts? It seems that the server is treated as 'external' because of the DNS name access as opposed to IP.

[mastrmind11 717]

I see.  And that's also an interesting observation about how Emby determines internal vs external access.  If it's just treating everything as external when using a domain name, then I'd imagine it would be a pretty simple fix to change it to IP validation instead.  

[FunkadelicRelic 10]

Thanks @mastrmind11 - are you able to elaborate a bit more though on your thoughts? Where are you thinking I might be able to change to IP validation? Within Emby?

[mwongjay 64]

I force external clients to use a password, not a pin. Local clients can choose to use a pin or not. 

 

My settings for Emby under Advanced related to this:

 

Local https port number: 8920

Public https port number: 443

Cert path: some-cert.pfx

External domain: domain.com

Report https as external address: true

 

Nginx config:

location /emby {
    proxy_pass              https://192.168.20.14:8920;
    proxy_set_header        X-Real-IP               $remote_addr;
    proxy_set_header        X-Forwarded-For         $proxy_add_x_forwarded_for;
    proxy_set_header        Host                    $host;
    proxy_set_header        X-Forwarded-Proto       $remote_addr;
    proxy_set_header        X-Forwarded-Protocol    $scheme;
    proxy_redirect          off;

    proxy_http_version      1.1;
    proxy_set_header        Upgrade                 $http_upgrade;
    proxy_set_header        Connection              "upgrade";
}

Edited September 29, 2017 by mwongjay

[FunkadelicRelic 10]

Thanks @@mwongjay - I think I figured out my issue. I selected the option to 'forwardfor' in the HAProxy frontends for both the WAN and LAN listener and it seems to be working as expected now. I think this is due to the client IP address showing as the reverse proxy address when its passes to the Emby server when the forwardfor option wasn't selected. Now the Emby server gets the proper client address.

 

I'll keep my eyes on it - when that option wasn't set, I wasn't being asked for a password at all when coming in from external! Far from ideal.

 

Thanks everyone for helping so far.

[dcrdev 251]

I have a similar set-up to the one you're looking to have.

 

I'm not using nginx, but Apache instead (just easier because I'm also serving other web content) - the way I'm handling the transition between internal/external is by running my own DNS server. All clients that use DHCP are automatically routed through this DNS server and it enables me to resolve my domain to an internal IP when connected to my network. 

 

The DNS server utilises Google DNS upstream and then has entries for my domain which are assigned a higher priority. The local DNS server might not be necessary if your router supports NAT loopback - mine does, but I've also got CloudFlare over the top of this set up.

 

One observation from this set up is that by default even when you instruct your clients to connect via the reverse proxy, they don't internally. Emby seems to be detecting that you're on the same subnet and if you look at the transcoding logs, files are actually getting served from http://yourdomain.com:8096/emby/*. Even when you have Emby set up to use a domain, the SSL port set to 443 and the report https as external address options ticked.

 

^ To be clear - the web interface still gets served via the proxy, but media i.e. images, audio and video do not; atleast internally anyway. 

 

Now this doesn't cause any issues - it all works fine, but given my OCD-like tendencies I couldn't let this slide. What I ended up doing was utilising the mod_substitute module with some regex to replace the domain within the response bodies. Now everything, both external and internal is served through the proxy.

Edited September 29, 2017 by dcrdev

[FunkadelicRelic 10]

Thanks @@dcrdev - in my case, I think this is correct? I have the below:

 

Internal DNS: A record for emby.domain.com at IP address 10.x.x.x (Internal IP for HAProxy listener)

External DNS: A record for emby.domain.com at CloudFlare public IP (External IP for HAProxy listener)

 

HAProxy Backend for 10.x.x.x Emby Server on port 8096.

HAProxy Frontend for Internal Network with SSL Termination poiting to Emby server backend.

HAProxy Frontend for External Network with SSL Terminiation pointing to Emby server backend.

 

When I connect to emby.domain.com internally - the forwardfor option seems to work and I am not prompted for a password (I use the Easy PIN).

When I connect to emby.domain.com externally - the forwardfor option seems to correctly determine I am coming from outside and my users DO get prompted for a password.

 

So far so good.

 

Now if I look at the transcode logs from an internal client, I see this line:

 

http://emby.domain.com:8096/emby/videos/someguid/hls1/main/0.ts?

 

Even though I'm accessing the Emby server via https://emby.domain.com.

 

In my mind, that might be a typo in the log as my firewall does not allow that traffic. You've got me thinking now though. I think I'll need to look into this further.

[dcrdev 251]

Thanks @@dcrdev - in my case, I think this is correct? I have the below:

 

Internal DNS: A record for emby.domain.com at IP address 10.x.x.x (Internal IP for HAProxy listener)

External DNS: A record for emby.domain.com at CloudFlare public IP (External IP for HAProxy listener)

 

HAProxy Backend for 10.x.x.x Emby Server on port 8096.

HAProxy Frontend for Internal Network with SSL Termination poiting to Emby server backend.

HAProxy Frontend for External Network with SSL Terminiation pointing to Emby server backend.

 

When I connect to emby.domain.com internally - the forwardfor option seems to work and I am not prompted for a password (I use the Easy PIN).

When I connect to emby.domain.com externally - the forwardfor option seems to correctly determine I am coming from outside and my users DO get prompted for a password.

 

So far so good.

 

Now if I look at the transcode logs from an internal client, I see this line:

 

http://emby.domain.com:8096/emby/videos/someguid/hls1/main/0.ts?

 

Even though I'm accessing the Emby server via https://emby.domain.com.

 

In my mind, that might be a typo in the log as my firewall does not allow that traffic. You've got me thinking now though. I think I'll need to look into this further.

 

My firewall also operates on a whitelist only model, but I did note that Emby dlna requires you open 8096 for the broadcast message; so I did allow that port. Are you sure you maybe didn't do the same?

[FunkadelicRelic 10]

No, and I don't have uPnP enabled on Emby or my firewall either.

 

What is also odd is that if I play a file from an external device (my phone on 4G) then it also lists the file as coming from http://emby.domain.com:8096/emby/videos/someguid/hls1/main/0.ts?

 

This couldn't be true as I only allow 443 from external to my HAProxy instance. Nothing else will get through.

 

Strange... Are you seeing the same with an external client? Once you did the re-writing in the RP, do log files now log the correct address?

[dcrdev 251]

I don't think I ever experienced it with an external client, no.

 

Yes it is showing the correct path in the logs, but the logs are ofcourse also getting rewritten.

 

There's a sure way to tell where content is being served from though - just open up your browser's debugger and look at the requests being made. If your firewall doesn't allow traffic from that port, then It's probably safe to assume it's going through your proxy.  In my case it wasn't, but I do allow traffic from that port.

[FunkadelicRelic 10]

I think I might be OK. If I hit F12 in Chrome I see the following details when playing a movie from internal network:

 

Requesting url without automatic networking: https://emby.domain.com/Sessions/Playing

plugin.js?v=3.2.32.0:1 Setting new text track index to: -1

plugin.js?v=3.2.32.0:1 currentTrack id: textTrack2

plugin.js?v=3.2.32.0:1 expectedId: textTrack-1--currentTrack.Id:textTrack2

plugin.js?v=3.2.32.0:1 Setting track 0 mode to: 0

2apiclient.js?v=3.2.32.0:1 Requesting url without automatic networking: https://emby.domain.com/Sessions/Playing/Progress

 

Every reference in the logs there seems to indicate the correct SSL page is providing the content.

 

Is anyone from Emby able to provide input as to why the log file for transcodes reports the wrong hostname? It would be good to understand why that is happening.

[pir8radio 1292]

 

I think I might be OK. If I hit F12 in Chrome I see the following details when playing a movie from internal network:

 

Requesting url without automatic networking: https://emby.domain.com/Sessions/Playing

plugin.js?v=3.2.32.0:1 Setting new text track index to: -1

plugin.js?v=3.2.32.0:1 currentTrack id: textTrack2

plugin.js?v=3.2.32.0:1 expectedId: textTrack-1--currentTrack.Id:textTrack2

plugin.js?v=3.2.32.0:1 Setting track 0 mode to: 0

2apiclient.js?v=3.2.32.0:1 Requesting url without automatic networking: https://emby.domain.com/Sessions/Playing/Progress

 

Every reference in the logs there seems to indicate the correct SSL page is providing the content.

 

Is anyone from Emby able to provide input as to why the log file for transcodes reports the wrong hostname? It would be good to understand why that is happening.

 

 

Look at your emby dashboard, that is where the transcode log pieces together items to produce that url.   If im understanding what you are saying correctly.    By that log i would suspect your HAProxy is connecting to your emby server using http and port 8096?    or go to  yourdomain.com/emby/system/info/public/   and see the address there, that is probably the same address in the logs?   I would say its normal.

[FunkadelicRelic 10]

Thanks for your input both. It kind of brings me back round to my initial point. Are those two addresses on the dashboard primarily cosmetic or are they used for something more, such as determining if a client is internal or external?

 

My clients never communicate directly to either of those addresses, which are listed as:

 

LAN - http://10.x.x.x:8096

WAN - http://emby.domain.com:8096

 

My HAProxy is configured with the backend for Emby specified as http://10.x.x.x:8096 - clients connect via Https://emby.domain.com irrespective of whether they are internal or external and get SSL terminated and redirected. None of my devices have the ability to get to Emby directly as I limit access on my firewall.

 

Everything seems to be working well (and I just purchased Premiere, so looking forward to playing with the other apps!) so I just wanted to know a bit more about the inner workings of the app so I don't inadvertently open myself up to the world with no authentication.

 

Again, thanks so much so far.

 

Sent from my Pixel using Tapatalk

[pir8radio 1292]

Thanks for your input both. It kind of brings me back round to my initial point. Are those two addresses on the dashboard primarily cosmetic or are they used for something more, such as determining if a client is internal or external?

 

My clients never communicate directly to either of those addresses, which are listed as:

 

LAN - http://10.x.x.x:8096

WAN - http://emby.domain.com:8096

 

My HAProxy is configured with the backend for Emby specified as http://10.x.x.x:8096 - clients connect via Https://emby.domain.com irrespective of whether they are internal or external and get SSL terminated and redirected. None of my devices have the ability to get to Emby directly as I limit access on my firewall.

 

Everything seems to be working well (and I just purchased Premiere, so looking forward to playing with the other apps!) so I just wanted to know a bit more about the inner workings of the app so I don't inadvertently open myself up to the world with no authentication.

 

Again, thanks so much so far.

 

Sent from my Pixel using Tapatalk

 

I'm only familiar with nginx and a little bit Apache as a reverse proxy, but you should be passing the client ip through the headers. Just make sure that when you login through your RP (using a client from a remote network like your cell with wifi off) the emby log shows your external client IP and not the ip of your HAproxy  then i think you will be fine.      If you use chrome and F12 your emby page, go to network, find ENDPOINT and go to preview you will see what the emby server thinks of your connection, should similar to the below image.   In this example I am connecting from a chrome browser in my home to my server that is in a datacenter that sits behind two reverse proxies.   I'm not entirely sure how emby determines or uses these two values, but IsInNetwork is TRUE when I'm accessing emby from the local server network so you shouldn't see true there when accessing your server remotely.  IsInNetwork should be FALSE when running through your RP remotely.

 

[FunkadelicRelic 10]

I definitely think something isn't quite right. Might be the configuration in the reverse proxy. My logs all still indicate a http connection on port 8096. To add to this, the app on Android TV fails to play most content, it just hangs at a black loading screen. Same with my Roku. Web app and Android app seem to work though.

 

I'm running a pretty stock HAProxy configuration, with exception to the 'forwardfor' option that I enabled to get users prompted for a password on the outside. Does anyone know of any more settings or options I should be enabling on the reverse proxy?

[pir8radio 1292]

I definitely think something isn't quite right. Might be the configuration in the reverse proxy. My logs all still indicate a http connection on port 8096. To add to this, the app on Android TV fails to play most content, it just hangs at a black loading screen. Same with my Roku. Web app and Android app seem to work though.

 

I'm running a pretty stock HAProxy configuration, with exception to the 'forwardfor' option that I enabled to get users prompted for a password on the outside. Does anyone know of any more settings or options I should be enabling on the reverse proxy?

 

Post your HAproxy config (if its text based) strip out your private info.   Maybe some HAProxy users can help, possible nginx users can spot some similarities to your config.

[FunkadelicRelic 10]

Below is my HAProxy config. I have a bunch of other services running through this but I have deleted the relevant lines. Also replaced my current WAN address with [ExternalIP] - left the internal in there.

# Automaticaly generated, dont edit manually.
# Generated on: 2017-09-29 15:16
global
	maxconn			10000
	stats socket 	/tmp/haproxy.socket level admin
	uid				80
	gid				80
	nbproc			1
	chroot			/tmp/haproxy_chroot
	daemon
	tune.ssl.default-dh-param	2048
	server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
	bind 127.0.0.1:2200 name localstats
	mode http
	stats enable
	stats admin if TRUE
	stats uri /haproxy/haproxy_stats.php?haproxystats=1
	timeout client 5000
	timeout connect 5000
	timeout server 5000

# Frontend on internal interface
frontend FE-MGMT-443
	bind			10.8.20.254:443 name 10.8.20.254:443 ssl  crt /var/etc/haproxy/FE-MGMT-443.pem crt /var/etc/haproxy/FE-MGMT-443  
	mode			http
	log				global
	option			http-keep-alive
	option			forwardfor
	acl https ssl_fc
	http-request set-header		X-Forwarded-Proto http if !https
	http-request set-header		X-Forwarded-Proto https if https
	timeout client		30000
	acl			Emby	hdr_beg(host) -i emby.domain.com
	use_backend Emby_http_ipvANY  if  Emby 

# Frontend on external WAN interface
frontend FE-WAN-443
	bind			[ExternalIP]:443 name [ExternalIP]:443 ssl  crt /var/etc/haproxy/FE-WAN-443.pem crt /var/etc/haproxy/FE-WAN-443  
	mode			http
	log				global
	option			http-keep-alive
	option			forwardfor
	acl https ssl_fc
	http-request set-header		X-Forwarded-Proto http if !https
	http-request set-header		X-Forwarded-Proto https if https
	timeout client		30000
	acl			Emby	hdr_beg(host) -i emby.domain.com
	use_backend Emby_http_ipvANY  if  Emby 

backend Emby_http_ipvANY
	mode				http
	log					global
	timeout connect		30000
	timeout server		30000
	retries				3
	server				Emby 10.8.50.224:8096 check inter 10000

[FunkadelicRelic 10]

OK - more weirdness. I had posted another thread in the Android TV section about my client not playing a bunch of media.

 

However, if I connect directly to the Emby server, bypassing the Reverse Proxy, everything works perfectly.

 

There must be an issue with my HAProxy configuration. Anyone have any thoughts, pulling my hair out here