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?

EDIT: This is the best I can do against your instructions with no example. There’s a fair bit of your instructions I don’t understand. 443 is forwarded from the router to the mini PC in this diagram. I don’t know how to draw red lines perpendicular from the client PC to the mini PC, but that’s where it’s going from and to. I’m more concerned with traffic coming from the internet and making its way to Jellyfin.

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 am trying to fix the logs so I can see the origin of connections to my services, but I’ve been unsuccessful in getting additional configurations to resolve that.

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.

EDIT: I was leaving out the path on the location, so now that that’s corrected, it saves my changes, but I’m not seeing any progress in the IP address reporting.