Jump to content

Cast not working in remote-port-forwarded environment


Jongeman
Go to solution Solved by Jongeman,

Recommended Posts

Jongeman

Hey Emby community.

 

I have diagnosed a problem with my Emby environment, however I can't come up with a swift and elegant solution to it.

 

First, some background:

I'm running Emby in a home server which comes with 2 limitations

1. My IP is dynamic

2. I CANNOT open any ports. This is NOT possible with my ISP

 

(I highlighted this in bold to indicate that this really isn't a solution to my problem, I'm looking for a different solution)

 

To mitigate these problems I have a VPS running in the cloud (with a public IP) for a few euros per month, which handles all incoming traffing through remote port forwarding. This is done using SSH tunnels (background on that here if you're interested: https://www.ssh.com/ssh/tunneling/example.)

 

This actually works really well and is quick enough to stream full HD content, the issue however comes when you start chromecasting content.

 

If you use a chromecast, the IP address is passed along to the chromecast, which is a non-accessible IP. Example:

 

My home IP is 1.2.3.4

The Emby VM has IP: 192.0.0.10 assigned to it.

 

The chromecast will now be passed the IP: 1.2.3.4, which it can't connect to, because the ports on it can't be opened.

 

This also shows in my logs (using a local chromecast):

2019-01-07 16:22:51.255 Info HttpServer: HTTP GET http://192.168.xxx.xxx:8096/emby/Videos/74ba4614749a59664393502333685647/stream.mp4?Static=true&mediaSourceId=74ba4614749a59664393502333685647&deviceId=U0hJRUxE&Tag=4791f2f25d6e3fdbd691f3be6954d613. Host=192.168.xxx.xxx:8096, Connection=keep-alive, Origin=https://mediabrowser.github.io, Accept-Encoding=identity;q=1, *;q=0, User-Agent=Mozilla/5.0 (Linux; Android 8.0; Build/OPR6.170623.010) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.47 Safari/537.36 CrKey/1.36.140076, Range=bytes=0-, chrome-proxy=frfr, Accept=*/*, Accept-Language=en-US, CAST-DEVICE-CAPABILITIES={"bluetooth_supported":true,"display_supported":true,"hi_res_audio_supported":false,"remote_control_input_supported":false,"touch_input_supported":false}

Because of this, the chromecast will simply play nothing (and it won't give out any error either for some reason).

 

The solution I want is for me to be able to select either a domain name or another IP address to pass when chromecasting. For example.

 

http://publicdomain.ext:8096 would work.

http://4.3.2.1:8096 would work

 

How can I achieve this?

 

Thanks in advance.

Edited by Jongeman
Link to comment
Share on other sites

Hi, check the remote address displayed on your emby server dashboard. Is this address correct? Is the local address correct?

Link to comment
Share on other sites

Jongeman

Hi Luke.

 

The remote address displays my public home address. Which cannot be accessed in any way.

The local address is correct and can be accessed (internally).

Link to comment
Share on other sites

Then I would go to the Advanced section and enter your Wan address. Once the address displayed on the server dashboard is correct then please try again. Thanks.

Link to comment
Share on other sites

Do you have control over DNS on your local network? 

 

For whatever the emby server thinks it's external hostname is (eg. emby.yourvps.com, 'real' DNS = 1.2.3.4) create a static DNS entry for:

 

emby.yourvps.com = the host that has the SSH tunnel on it (and make sure the SSH tunnel can accept non-local connections).

 

If your VPS doesn't have an externally resolvable domain, you can probably trick it by entering something in Emby Management -> Advanced -> External Domain (ie. emby.yourvps.com). As long as the DNS entry and the name emby thinks it's called match it should work. 

 

When you go to cast, emby will tell the chromecast to try and connect remotely, the chromecast will do a local DNS lookup and be 'tricked' into connecting to your SSH gateway, not over the internet...

 

If you have a reasonable router you should be able to add a static DNS entry there... 

Link to comment
Share on other sites

Jongeman

Hey jon_ and Luke.

 

I have found the core issue. When someone is logging in, it shows up as a localhost login rather than an external login, which makes it use the LAN IP. I'm not quite sure how to fix this, but it has to do with the SSH tunnel. If I come up with a solution I'll post it here.

Link to comment
Share on other sites

  • 5 weeks later...
  • Solution
Jongeman

Update:

I've got it working in another way. Rather than remote port forwarding to a machine in the cloud I've simply connected to that machine using OpenVPN.

 

This makes the connection go as follows:

Emby service -> Openvpn -> nginx (reverse proxy) -> client.

 

To get this working you need a few things:

1. An open firewall on your machine that is running Emby.

2. A static assigned IP that you get when connecting to OpenVPN. You can do this by adding config:

/etc/openvpn/server.conf

server 10.8.0.0 255.255.255.0
client-config-dir ccd/
/etc/openvpn/ccd/<yourclientname>

ifconfig-push 10.8.0.2 255.255.255.255
ifconfig-push 10.8.0.0 255.255.255.0

3. Once you have this, make sure you start openvpn on the emby machine, and connect to the machine that has OpenVPN server running.

openvpn --config <path_to_your_ovpn> --daemon

4. Now go to the machien running OpenVPN-server and start an NGINX reverse proxy, my config is:

location / {
        proxy_pass              http://10.8.0.x:8096/;
        proxy_set_header        X-Forwarded-Host        $server_name:$server_port;
        proxy_hide_header       Referer;
        proxy_hide_header       Origin;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header        Referer                 '';
        proxy_set_header        Origin                  '';
        add_header              X-Frame-Options         "allow-from https://MYDOMAIN.EXT/";
    }

5. Open the ports on your firewall.

6. Make sure to select the proper port when connecting to your server (either 443, 80 or whatever you configured NGINX on).

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...