ampersandrew

I mean…I’m on both of those, but I know I can use Bluesky as a linear feed like Mastodon, and as long as that still works with no algorithm, it solves my Twitter problem. I think the cycle of software innovation is that you have the first proprietary tool that solves a problem, like MS Office or 3DSMax, and then the most important parts of those programs are solved in open source software after a lag, like LibreOffice or Blender. Discord would always be replaced in time.

It’s been years, and there’s only now a handful of programs that offer some of Discord’s best features. If we had open source alternatives back then, I certainly would have entertained them.

It looks like it’s a community plugin that’s not there out of the box, but it is for sure one more tool I have in my tool belt to solve this. Thanks for the tip!

I have an OPNsense firewall, but I didn’t know it could do that. I was just following guides for the easy route for most of this stuff.

Thanks, there’s a lot to read through in there, so I’ll see what, if anything, I can apply from it.

Still the same problem, I’m afraid. I also experimented with putting some of this stuff in the Custom Locations section of NPM’s proxy host settings, since that’s how it looks in Jellyfin’s nginx guide. The only feedback that I got at any point that my changes in NPM were doing anything at all was when my mobile app failed to connect to my server because of how I’d mucked around in there; I did delete those changes before adding your suggestions, of course.

Thanks!

@lemmyvore@feddit.nl , I already made the JSON file changes, but seeing as this hasn’t changed in Jellyfin reporting after doing so, I think we can point to this as being authoritative for how it appears in Jellyfin logs. But I do have it listed as a known proxy, and I added that X-Forwarded-For header to NPM, so I’m not sure what else I’m missing. With a /24 subnet, this IP address is probably safe though, right?

Alright, I did all of the above. I added the proxy_set_header line to Custom Nginx Configuration for the Jellyfin proxy host by hitting the gear in the upper right of the edit window.

The daemon.json file wasn’t on my mini PC (where NPM lives), so I made a new one with those contents sans the 192.168 line. It was already present on my NAS (where Jellyfin lives), but only with a few other lines that weren’t our default-address-pools. I appreciate your previous instructions not assuming that I know the structure of a JSON file, but I do work with them a lot for my day job, so I was comfortable appending to that file on the NAS (though I did have to re-learn some vim basics to do it).

Anyway, after making those daemon.json file changes, I rebooted the whole machine in both places, not just Docker. That should be enough to make any IP addresses refresh themselves, right? But Jellyfin logs still show access coming from 192.168.65.1. I do find it strange that a container would be using an IP address like this one without reporting it somewhere, but in the Inspect tab of Docker Desktop on the mini PC, it just shows that 172.17.0.X address (2 for IPAddress, 1 for Gateway).

The common-sense assumption is that you will adjust your Docker daemon settings so that you prevent overlap with your LAN. (Also, I expect lots of tutorials aren’t that high quality to begin with.)

I would say a high quality tutorial doesn’t assume that I know anything about Docker, and most of them didn’t (which is good, because I don’t), but they also didn’t seem to expect me to want better logging out of my hosted services. Thanks, the /16 subnetting makes sense. I’ll try to edit that json file later today. But we seemingly don’t expect this to fix the problem by itself, so other than telling Jellyfin to expect a proxy at the new reported IP address, what should I expect for next steps?

Yep, you’ll have to fix that by telling your proxy to put the client IP in a header that the target app can recognize and use.

I thought that’s what I was trying to do by adjusting both NPM proxy host settings as well as informing Jellyfin where to expect proxy headers from.

But, also, it’s a good idea to have Docker network ranges that don’t overlap your LAN. That would make me uncomfortable too.

Does it overlap my LAN? Is 192.168.65.X not distinguishable from my defined subnets with a 24-bit mask, now that I know where they’re coming from?

And to be honest, you’ve talked past my understanding with a lot of that paragraph, so I’ll have to comb through it later tonight when I have more time. Keep in mind that all of my Docker network settings are default, so it’s a setting I’ve never dabbled with. From what I can tell from the settings it defined on its own, these containers created a 172.17.0.X address, and somehow the proxy responds with (“announces”?) a 192.168.65.1 address. Are you saying that I need to define for it an unused address that’s on my existing 10 VLAN? Somehow all of the tutorials I’ve found in the past months to set up services behind a reverse proxy never mentioned any of these gotchas with Docker and networks.

I can take a look after work, but won’t that just change the proxy’s IP listed in my logs instead of properly forwarding along the source IP address?

The answer was the same on both machines. A 172.17.0.X network was created as a bridge.

Sorry, Linux is the host OS. It’s Debian.

My containers are run in Docker on the metal, not in a VM. My network settings are defaults, which ends up being bridge mode. And yes, my router forwards 443 to NPM listening on 443. It all works except that it’s losing the origin IP address in the logs.

I’m not trying to be rude. I genuinely don’t see the path between that map and the solution to this problem. Do you need it for your benefit to assist me?

I honestly don’t think I have to. I’ve only got two machines, and I don’t think it’s going to expand any farther than that. And I’m not sure how that helps me with this problem.

It appears to be, but I didn’t know that until today. And beyond that, I’ve been trying every permutation of both that IP and the IP of the server on my network in my Jellyfin proxy settings, and it still hasn’t helped to surface the origin IP address.

Yeah, that appears to be the case from a link someone else linked here, but I was unable to trace that from anywhere I could find in my containers before.

I’ve got a document labeling everything, but I’ve kept my circle small and only expanded out as I conquered the last challenge. The reason I haven’t installed a third service yet is because I don’t have the IPs properly reported yet. I know exactly which machine, IP address, and port each service can be found at.

I know you said you don’t know anything about the GUI equivalent, so I’m mostly responding to this comment to publicly post how far I’ve gotten off of your tips. There is a “Custom Locations” tab for my proxy host in NPM, but even after attempting to follow this guide I found, I can’t get my custom locations to persist after hitting the Save button.

When you say “when accessed from outside my home network”, what kind of access is that? Port forward? VPN?

Accessing via 443 forwarding to my reverse proxy from the internet. My dad will hit my Jellyfin server from his house, and I can hit that server from mobile networks when I’m not on wi-fi.

Is 192.168.1.1 your router?

Yes. It’s also .10.1 on the 10 VLAN.

What’s your LAN netmask?

255.255.255.0 on both VLANs

NPM listens on 192.168.10.201 ports and Jellyfin/Komga on 192.168.10.202 ports?

Correct.

A connection from the outside comes through the router, gets forwarded to 192.168.10.201:443, the proxy sends it to 192.168.10.202:8096, and it shows up in the Jellyfin logs as coming from 192.168.65.1?

Correct. Jellyfin is actually listening on a different, auto generated, arbitrary port that I just stuck with, but other than that, you got it.

I did check every IP address I could find anywhere on my network and couldn’t find the 192.168.65.X anywhere, but @anamethatisnt@sopuli.xyz here in this thread seems to have identified this as some NAT setting built in to Docker. Running on default settings for network, because I had no idea why I would want to modify any of those settings, they are running as bridge networks.

I’m not quite sure where this goes. It’s Nginx Proxy Manager (in case that affects your answer compared to vanilla nginx), and I’m using Docker Desktop for much the same reason: I’m doing as much configuration via GUI as possible. Is this a Docker configuration or an Nginx Proxy Manager configuration? There is a “Custom Nginx Configuration” screen for my Proxy Host; does it go there? In a nested location block?

My wife spent about $130 for a year subscription to a service that she figured would always have her favorite show on it, because they own that show. Then like 10 seasons of it left for an exclusivity deal on another service. This was a contributing factor to pushing me into self hosting. Some of it is saving money, but some of it is also making sure you actually got what you paid for.

Yeah, it’s on my to-do list for my domain registrar, but the above was in relation to OPNsense configuration, which I found a solution for.

It does sound exactly like this. However, I’m concerned about following these instructions when my external IP isn’t static. I still have yet to set up DDNS (I believe is the term, for automatically updating my domain’s DNS servers with whatever new IP address my ISP gave me), but this looks like it’s entirely IP driven.

Yes, that’s exactly what I’ve done. You still haven’t shown me why it’s unsafe. If you can’t, that’s fine. At some threshold or another, nothing is secure. The one thing I know for sure is that that first page, that says it doesn’t recommend exposing a port, does not say what you said it does.

Probably the number one recommendation I see in self hosting communities is to not open ports directly (other than for a reverse proxy). It seems like a common recommendation no matter the service. To be clear: I am a beginner. I know very little about this, but I’ve spent months learning. I can’t say you’re wrong, but I don’t think you’ve made a convincing argument for me to actually understand why Jellyfin is unsafe to expose to the internet compared to any other service.

It says exposing a port directly to the internet is not recommended; do you know of any project that would recommend directly exposing a port? What is meaningfully different here?