Simpleton guide for remote access?

Don’t like what Plex is doing… Afraid Emby will go down same path… Have an Unraid tower… Am a newb… can port forward.

Oh wow Jellyfin, looks kewl. Seems to have a good community.

Then I lookup how to get remote access and I start to get a little scared. The main places I have looked at so far are here:
jellyfin.org/docs/general/networking/index.(html)
letsencrypt.(org)
reddit.(com)/r/jellyfin/comments/efiy9z/help_setting_up_remote_access/
httpd.apache.(org)/docs/2.4/howto/reverse_proxy.(html)
also saw Duck DNS which I think I need cause my IP can change

I believe what this guy is doing is unsafe: https://www.youtube.com/watch?v=jaUwFq-sBVI

Anyone know of a good guide? I basically want to be able to get remote access in safe manner for me and my family.

Sorry if it sounds cavalier. I spent an hour looking around and just got more questions at this point so I figure I would throw a hail mary to the forums. Thanks in advance of anyone has ideas.

You’re right, there’s a lot of information floating around, mostly written by people who’ve been involved with IT for a long time, so can become quite confusing for the newcomer.

First thing… You’ll need either an internet connection with a static IP address (possibly also with a registered domain pointing to your IP address), or the services of a Dynamic DNS service (such as DuckDNS, NoIP, DynU, Afraid and many others). Your client(s) will need this information in order to know where to connect to your server. I won’t go into any further detail with these as all of the DDNS providers are user-friendly and offer their own detailed guides which even a politician should be able to follow.

Let’s assume for the moment that you’ve created an account with NoIP and have gotten yourself the hostname of “zmanfarlee.noip.com…”

Pick a port, any port, but don’t use 8096 (for security reasons - because Jellyfin defaults to this port, miscreants out there will be hunting this port down through the 'net in an effort to find a vulnerable installation). Let’s assume you chose port 1337.

On your router, forward the following ports;
Incoming port 80 -> Jellyfin server port 80 (required for Let’s Encrypt)
Incoming port 443 -> Jellyfin server port 443 (required for Let’s Encrypt)
Incoming port 1337 -> Jellyfin server port 1337 (required for actual Jellyfin connections)

On the Jellyfin server, install Caddy Web Server - this will act as a reverse proxy for Jellyfin and will manage the automatic acquisition of SSL certificates from Let’s Encrypt.

Create a Caddyfile with the following entries (refer to the instructions on the Caddy web site to determine where this file should be depending on your operating system, and edit it to suit your requirements with regard to hostname and port number);

zmanfarlee.noip.com:80 {
  respond ":-P" 403
}

zmanfarlee.noip.com:443 {
  respond ":-P" 403
}

zmanfarlee.noip.com:1337 {
  reverse_proxy 127.0.0.1:8096
}

The “:-P” is the plain text which will get sent to casual visitors trying to find a regular web server on your IP, along with a 403 (“Forbidden”) response code. If someone connects (using HTTPS) to port 1337, their connection will be forwarded to Jellyfin itself, and happiness will ensue.

Once you’ve saved your Caddyfile configuration file, start or re-start the Caddy service (method is dependent on your operating system), and within 30-60 seconds you’ll have a functioning security certificate. To confirm this, use a device from outside of your network (as 99% of residential-grade routers don’t support hairpin loop-back), to browse to https://zmanfarlee.noip.com:1337 (or whichever hostname/port combination you’ve used) - you should receive the familiar Jellyfin log-in page.

You’re now set - Caddy will automatically refresh your SSL certificate with Let’s Encrypt periodically to keep it current, and you don’t need to do any more fiddling to keep your connection from the outside world functioning.

6 Likes

I will try this! Thank you!!!

I love forums.

1 Like

So, I have to ask, with a good firewall, running in docker on a synology nas, reverse proxied and certified, whats the risk I get ransomwared, or whatever else the bots try and do?

Nothing is ever 100% bulletproof unless you write all of your software from scratch and know precisely what you’re doing. In this world where borrowed and re-used libraries form the majority of the infrastructure (including big-$$$ name-brand hardware {cough-Cisco-cough}), there’s always a level of uncertainty.

The SSL encryption will only go so far as preventing in-transit snooping, so the MPAA’s branch of the NSA (or vice-versa) will have less of a chance to extort money from you. In terms of actual security, SSL means absolutely nothing.

As far as I know, there’s no published vulnerability in Jellyfin, so we should be relatively safe. Most of the web functionality is hard-coded, and that which isn’t is restricted to styling and HTML. Given the relatively small (in the greater scheme of things) footprint of Jellyfin, we should also be relatively safe from targetted hacking - though there’ll be no shortage of “noobs” installing Jellyfin, there’ll be even more installing Plex and (to a lesser extent) Emby, so the latter will be where the miscreants will be pointing their attention (more potential targets = more potential pay-offs).

Because I’m paid handsomely to protect corporate customers’ data, I’ve also extended the protection on my own network to make it more secure than it otherwise would be - but most people will lack the knowledge and/or equipment to do this.

Specifically with regard to Jellyfin, I’ve done the following;

  • Nominated the Jellyfin port as something other than 8096 or 8920 - security through obscurity isn’t ideal, but it adds another layer to the defences (a closed-but-unlocked door is far less appealing than a wide-open door).
  • Made Jellyfin ports 80 and 443 available to the entire world because Let’s Encrypt requires it (but those ports are used for absolutely nothing other than responding with a terse HTTP “Forbidden” response as detailed in my original response).
  • Made the actual Jellyfin port only available to IP addresses from within my own country (not a perfect solution, but the only option available short of using VPNs for mobile clients).

I use a dedicated box (very old Intel Core Quad computer) running pfSense as my network gateway which makes this functionality easy. Ubiquiti’s EdgeRouter series can also (if you know what you’re doing) handle GeoIP restrictions. Residential-grade routers are unfortunately completely useless in this regard.

If your router’s capable of it and you know how to implement it, do a periodic scrape (I do it once a week) of http://www.ipdeny.com/ipblocks/data/aggregated/<cctld>-aggregated.zone (where “<cctld>” is your country’s identifier) and use that list for allowing TCP connections to Jellyfin’s port, whilst blocking all others.

1 Like

“Because I’m paid handsomely to protect corporate customers’ data”

Man you are living the dream, that’s the career im working towards, or a variant of it.

Anyways thanks, the firewall in my nas does block all connections outside of canada (though im working through how to stop it blocking tvdb and other scrapers)

Nah, I was “living the dream” about a decade and a half ago - recently divorced and no shortage of women available to me for “casual acquaintance.” These days I’m a cynical old man who spends far too much time surrounded by computers :man_shrugging:

Scrapers shouldn’t be looking into your network, so you shouldn’t need to do anything to allow them to function. Note that my recommendation for geo-blocking should only be applied to inbound connections - you still need all outbound functionality for scraping, browsing, etc.

If on the other hand you’ve blocked outbound connections to specific netblocks (such as the cess-pool of malice known as Amazon), I can understand your predicament - it’ll be a tedious process to identify which pinholes you need to open.

Yeah its strange, it can only block incoming connections and my rules are just

“allow these application ports”
“allow canada”
“deny everything else”

Edit: Seems to be the deny all rule after, no Idea how to fine tune it

It could be a DNS anomaly (check nslookup from your container) or a bad route (check traceroute from your container).

Also check how your container resolves DNS - most Linux installations these days seem to have a preference for a local DNS forwarder (identified when you see that your container’s network is set to use 127.0.0.53:53 as a resolver), which doesn’t always work as well as it should.

It seems the firewall prevents any ip not from the regions ive set from downloading data, changing the rule to only block china allows it, so when jellyfin requests to download an image, firewall kills it.

A solution I found was to allow the docker bridge ip, no idea how to find that in this damn ui though.

HAHA, success, allowing the bridge ip range fixed my issue.

If I can bother you one last time, how do Ip ranges work? It said it was “172.17.0.0/16” I would have assumed that meant it could go up to 172.17.1.6, but its actually “172.31.255.255”, how does that work?

Well there’re two paradigms which point to the same thing. In the Microsoft world, they specify netmasks - whilst in most of the remainder of the IT world, they use CIDRs (Classless Inter-Domain Routing, which took over from class-based grouping which was prevalent in the early days of the 'net).

A netmask of all "1"s in binary (255.255.255.255) isolates just a single address - it tells the underlying device to only allow whichever IP address is given.

A CIDR works in the same way, but specifies how many bits should be ignored. In the case of the above, that would be a /32 (32 "1"s), equating to a single IP address.

x.x.x.x/24 = 255.255.255.0 = 256 IP addresses.
x.x.x.x/16 = 255.255.0.0 = 65536 IP addresses.
x.x.x.x/8 = 255.0.0.0 = 16777216 IP addresses.

Specifying 172.17.1.6/32 (or 172.17.1.6 netmask 255.255.255.255) will cover only IP address 172.17.1.6.
Specifying 172.17.1.x/24 (or 172.17.1.x netmask 255.255.255.0) will cover 172.17.1.0 to 172.17.1.255
Specifying 172.17.x.x/16 (or 172.17.x.x netmask 255.255.0.0) will cover 172.17.0.0 to 172.17.255.255.
Specifying 172.x.x.x/8 (or 172.x.x.x netmask 255.0.0.0) will cover 172.0.0.0 to 172.255.255.255.

You can use this subnet calculator to experiment with different values and see how they work, and keep it handy for when you need to calculate non-standard netmasks (for example, 172.17.1.6/29 = 172.17.1.6 netmask 255.255.255.248 = 172.17.1.0 to 172.17.1.7).

I have to note that in your given example going up to 172.31.255.255, it seems you’ve specified a /12 block rather than a /16 one.

Contrary to what Fred Flintstone (err, I mean Mike Pompeo) would have you believe, my experience over the past decade has shown that there’re very few if any malicious incursions from mainland China. There’s no shortage of hijacked/infected machines doing portscans, but actually targetted and relentless attacks come from the likes of Amazon, CloudFlare, DigitalOcean and OVH (as well as lesser hosting/“cloud” providers), with Microsoft and Google getting ever-worse as time passes.

Thanks for the explanation, and the china thing was just me setting it to block a country I know tvdb was not hosted in.

Thanks for your help. I am getting close I think but when I try to get Caddy running (installing on Unraid) I get this: listen tcp 0.0.0.0:80: bind: address already in use.

I am not sure how to clear that up. Looking all over the net and I think I am getting closer but FYI thats where I am at.

It sounds like there’s already a web server running on port 80 of that machine.

Are you intentionally running a web server on it, or is that something which was provided as a matter of course with your operating system?

Looks weird… Maybe I am configuring the docker wrong because it didn’t show port 80 being used until I tried to install caddy… So the issue with Caddy is likely how I have configured it…

Deeper I go into the rabbit hole. Wish em luck lol

Oh man I am toast… Looks like the dream has died.

thanks for this info. I’ve gotten pretty far. But i am getting this error in caddy. I am pretty sure that i have the ports forwarded correctly

2020/10/01 18:50:29.457 ERROR tls.obtain will retry {"error": "[myexternal dnsname] Obtain: [richardson.hopto.org] creating new order: request to https://acme-v02.api.letsencrypt.org/acme/new-order failed after 1 attempts: HTTP 429 urn:ietf:params:acme:error:rateLimited - Error creating new order :: too many failed authorizations recently: see https://letsencrypt.org/docs/rate-limits/ (ca=https://acme-v02.api.letsencrypt.org/directory)", "attempt": 1, "retrying_in": 60, "elapsed": 0.4467346, "max_duration": 2592000}

image

thanks for posting this. i finally got it working. turns out I had to restart my google fiber router before the port forwards worked. Caddy was throwing all kinds errors. Go figure, a router restart fixed my issue.

{
email   mynotrealemail@email.org
}

mynotreal.website.org:80 {
  respond ":-P 80 Not Found" 403
}

mynotreal.website.org:443 {
  respond ":-P 443 Not Found" 403
}

mynotreal.website.org:1973 {
	encode gzip
		log {
			output file C:\caddy\logs\jelly_access.log {
				roll true				# Rotate logs, enabled by default
				roll_size_mb 5			# Set max size 5 MB
				roll_gzip true			# Whether to compress rolled files
				roll_local_time true	# Use localhost time
				roll_keep 2				# Keep at most 2 log files
				roll_keep_days 14		# Keep log files for 14 days 
			}
		}

    reverse_proxy localhost:8096 
}

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.