Noob Reverse Proxy vs VPN question

[plexuser5424 0]

I have been researching what it will take to create a more secure server. It seems that most people opt for a reverse proxy with an SSL cert. My main question is could you achieve relatively the same thing (besides of course ssl which is a separate issue) by running an Emby docker through a vpn? In doing so you would be routing all the traffic through the VPN side stepping the need to setup a reverse proxy. As I said in the title, I know nothing so please enlighten me. Thank you in advance!

Edited September 15, 2021 by plexuser5424

[Abobader 3464]

Hello plexuser5424,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[Carlo 4561]

hi, The main problem with using a private VPN is that all clients will need to connect to the VPN before they can get to your server.
Running a VPN client isn't the hardest thing to do on a PC but if you have users using TVs, Chromecasts, Roku, Xbox, etc they may be out of luck unless they have an advanced router that can be setup to handle VPN for the whole LAN.

Putting your server behind a public VPN essentially does nothing for you as you just changed the public IP used to get to your server

[muzicman0 84]

Using Caddy2 as a reverse proxy is so simple, and will even handle getting the ssl cert for you and renew it automatically every 90 days.  I've been using it for well over a year now.  You will need to purchase a domain name though ($12/year through Google).  Then you access through something like https://tv.yourdomain.com.

In my case, my ISP blocks port 80, but not port 443.

With the above said, I also use OpenVPN on my shields for other things, and it is also secure and solid.  So either way you go is good.  Buy Cayars is right, the reverse proxy is universal where the VPN solution may not work on every client device.

[KegTapper 8]

I am also a recent Caddy2 convert. I picked up a cheap domain through namecheap.  Caddy2 has the easiest config IMO.

Also added my arr services and able to manage entire server from work through a strict firewall. 

[muzicman0 84]

If it helps, here is a sample caddy file (change to whatever you need):

{
email   steve@yourdomain.com 
}

stream.yourdomain.com {
    reverse_proxy 10.3.0.122:8096
}

kylo.yourdomain.com {
    reverse_proxy 10.3.0.130:5000
}

I actually have more than 2 subdomains, but left just 2 in so you could see that you can use more than one.  'stream' is my Emby server.  10.3.0.122:8096 is my local IP:port for Emby.  So if I open https://stream.yourdomain.com, it points directly to my server over a secure connection. (this assumes you have Emby set up correctly.)

[Carlo 4561]

How are you guys using caddy2 to add security to Emby?
A simple config like the same above isn't really doing anything security wise and could potentially make using Emby harder depending on how the end users IP is given to Emby.

In Emby do you see the actual IP of the user or only the IP of the proxy?

[KegTapper 8]

I can see the user IP

[muzicman0 84]

a reverse proxy takes a secure connection from the outside and basically proxies it locally on a local LAN unsecured connection.  In Emby, you set the port to 443 for remote connections, and set the cert to be handled by the reverse proxy (going from memory), and it just works.  So what you see in the config file is just telling Caddy what the local address is for the URL specified.

In my case, I use a Dynamic DNS to point to my url to my public IP Address, and Caddy sees that it is coming in on 'stream.xxx.com', and uses the config file to point to the local server and port.  so it converts a public secure connection to a local address and port.

It is super simple, and always says it's secure when I examine the certs in a browser.  I am a network professional, so not a newby to this (although secure connections is not my area of expertise).

EDIT: I should also mention, that I do not port forward 8096, so that I don't accidently end up with an unsecured connection.  I only forward port 443 to the caddy server (which in my case is also the Emby Server, but it doesn't have to be).

Edited September 15, 2021 by muzicman0

[muzicman0 84]

1 hour ago, cayars said:

How are you guys using caddy2 to add security to Emby?
A simple config like the same above isn't really doing anything security wise and could potentially make using Emby harder depending on how the end users IP is given to Emby.

In Emby do you see the actual IP of the user or only the IP of the proxy?

 

Edited September 15, 2021 by muzicman0

[Carlo 4561]

I certainly get that but you could setup SSL right in Emby and eliminate the proxy for secured connections and change the port to anything you want.

What I was getting at or trying to ask about caddy2 is how you use to extend security to Emby.
A simple example would be to only allow access from USA or Canada based on IP.

Banning connections from certain countries.  Banning access from public VPN IPs that people use to hack from, etc.

[muzicman0 84]

Caddy has those options, I just don't use them.  As far as using your own cert, that works, and that is how I used to do it, but since Caddy handles all the cert work in the background, and I don't have to remember expiration dates, etc, it was an easy change.  After I used it at home for a while, I actually started using it at my office even though I had a valid cert for another year.  

EDIT: Here is the documentation for filtering requests in Caddy.  

Edited September 15, 2021 by muzicman0

[ebr 16184]

4 minutes ago, muzicman0 said:

Caddy has those options, I just don't use them.  As far as using your own cert, that works, and that is how I used to do it, but since Caddy handle all the cert work in the background, and I don't have to remember expiration dates, etc, it was an easy change.  After I used it at home for a while, I actually started using it at my office even though I had a valid cert for another year.  

I think this is the key. It isn't more secure than the manual cert method - it's just a lot easier for a non network professional.

[muzicman0 84]

@cayars I think I mis-understood what you were asking before.  In the Emby activity logs, I see the remote IP address, not the proxy address.  I am out of town now, and verified that the IP address I am seeing is the remote public IP.

[Carlo 4561]

That's perfect.  We've seen in the past when people misconfigure a reverse proxy the Emby server only gets the proxy address and not the remote address.  That then can cause issues with remote bitrate limits and things like that.

PS Being able to auto renew certs and apply them for multiple domains or sub domains is a really nice feature and for many people could be the difference of getting SSL working on not.

2 hours ago, muzicman0 said:

I actually have more than 2 subdomains, but left just 2 in so you could see that you can use more than one.  'stream' is my Emby server.  10.3.0.122:8096 is my local IP:port for Emby.  So if I open https://stream.yourdomain.com, it points directly to my server over a secure connection. (this assumes you have Emby set up correctly.)

With the above URL if you were setting this up in an app instead of using a browser you would use port 443?

[muzicman0 84]

5 minutes ago, cayars said:

With the above URL if you were setting this up in an app instead of using a browser you would use port 443?

yes, although, I typically just use the pin method (IE: go to the specified URL and enter the numbers).  But I have set it up manually before, and you would enter the URL, then change the port to 443.

If you don't set the ssl cert setting to handled by reverse proxy, then Emby advertises on the wrong port (8920 by default iirc), so you have to use URL & port to get it working.  took me a bit to figure that one out (the forum helped me there).  But now it works seamlessly.

Edited September 15, 2021 by muzicman0

[KegTapper 8]

15 hours ago, ebr said:

I think this is the key. It isn't more secure than the manual cert method - it's just a lot easier for a non network professional.

It is really easy IMO. I followed this guide https://www.reddit.com/r/jellyfin/comments/icyymp/caddy_v2_windows_reverse_proxy_guide_updated_aug/ and was up and running in no time. 

[adrianwi 279]

NGINX Proxy Manager is a nice solution for this too.

[muzicman0 84]

1 hour ago, adrianwi said:

NGINX Proxy Manager is a nice solution for this too.

I like that it has a web interface to show info. I dislike that it is a docker image...do they have a native app for Windows or linux?

[adrianwi 279]

Don't know!  I'm running it on a Raspberry Pi with Home Assistant OS

[brabs 0]

has anybody setup caddy on a Mac, I've downloaded caddy from GitHub but unsure of hoe to get it running, we need an idiots guide that explains everything for Macs

[muzicman0 84]

I have not.  Did you try Google?

[brabs 0]

All guides Seem to be for windows or Linux

[pwhodges 2012]

On 15/09/2021 at 22:56, cayars said:

That's perfect.  We've seen in the past when people misconfigure a reverse proxy the Emby server only gets the proxy address and not the remote address.  That then can cause issues with remote bitrate limits and things like that.

PS Being able to auto renew certs and apply them for multiple domains or sub domains is a really nice feature and for many people could be the difference of getting SSL working on not.

The thing with Caddy is that its defaults are all sensible; there is no need to be looking at configurations like the big nginx files so often discussed here.  It just works (which is easier for the professionals as well as other users!).  But special requirements like manipulating headers, blocking IP ranges, etc are also catered for if you want to go that way.

The reason I use Caddy rather than SSL directly in Emby is (a) the automation, but (b) because I'm already running it for multiple sites, and in preference to setting up extra port forwarding I simply specify different site names in Caddy, proxying the Emby one to my Emby server - for me it was actually less work.

Paul