I think I’ve figured it out. Apparently now Docker also adds an 192.168. range on top of 172. ranges for its bridge networks:

https://docs.docker.com/engine/network/#automatic-subnet-allocation

Copy that example to your /etc/docker/daemon.json on all your docker machines, without the 192.168 line, and restart docker, and the 192.168.65. addresses will go away.

(Don’t forget to remove the trailing comma on the last address line.)

Mind you, this won’t solve anything, just remove some potential conflicts with your LAN. You will still see clients appearing to come from bogus addresses, except they’ll be in 172. ranges now.

Well I’ll be damned, there’s a 192.168. tucked away at the end of the 172. ranges:

https://docs.docker.com/engine/network/#automatic-subnet-allocation

{
  "default-address-pools": [
    { "base": "172.17.0.0/16", "size": 16 },
    { "base": "172.18.0.0/16", "size": 16 },
    { "base": "172.19.0.0/16", "size": 16 },
    { "base": "172.20.0.0/14", "size": 16 },
    { "base": "172.24.0.0/14", "size": 16 },
    { "base": "172.28.0.0/14", "size": 16 },
    { "base": "192.168.0.0/16", "size": 20 }
  ]
}

seems to have identified this as some NAT setting built in to Docker

TBH I also thought about it being the default range used by Docker for its bridge networks, but I was under the impression it uses 172. ranges by default. The official example on their site says it uses 172.30.0.0/16 and 172.31.0.0/16. Also I have an unmodified docker running on one of my machines and it allocated 172.18.0.0/16 for a bridge network.

You can try to docker network create a bridge network and see what range it gets, you’ll see if it gets a 172. or a 168..

BTW I hope you’re looking at the docker on the reverse proxy machine, not on the jellyfin machine.

Is it?! I always thought that Docker uses 172.16.0.0/16 by default for its networks. Did that get changed at some point?

Just to understand better:

• When you say “when accessed from outside my home network”, what kind of access is that? Port forward? VPN?
• Is 192.168.1.1 your router?
• What’s your LAN netmask?
• NPM listens on 192.168.10.201 ports and Jellyfin/Komga on 192.168.10.202 ports?
• 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?

If all of the above is correct I would look at the network interfaces that are up on the mini-PC and the NAS, as well as inside the containers of the proxy and of Jellyfin, and see if there isn’t a 192.168.65.1 up on there somewhere for whatever reason.

You can also try making a manual request (wget, curl, nc) from the proxy container to Jellyfin and see what it shows up as.

May also want to see what’s the DNS situation in your LAN and on those machines. You mentioned “names” being used, how are those defined and resolved?

Last but not least are the containers you mentioned using docker bridge networks or ipvlan?

What is “the API”?

Good question. When you have multiple implementations of an API, the API (the authoritative version) is what gives the reference spec that all other apps must follow.

If the authoritative version will be fully implemented only by the closed backend and in the closed apps, it will cripple the FOSS backend and apps.

This is a common tactic used by companies that want to sideline the FOSS options and slowly make them irrelevant.

Yes, today all apps talk to both Bitwarden and Vaultwarden the same way. Be on the lookout in case that changes.

If there are two version of Bitwarden backend (closed and FOSS), and the closed one changes its API, and the closed Bitwarden apps also switch to the closed API, then what value does the FOSS API have anymore?

Both backend and frontend revolve around the API, and Bitwarden owns that not Vaultwarden.

If Bitwarden decides to modify the API so that only their closed-source backend has the full spec, and only gives that spec to their own apps, everything else (Vaultwarden and 3rd-party apps) will fall behind or become unusable.

To counter that, Vaultwarden and the 3rd-party apps need to declare their own API and prepare to fly solo completely independently from Bitwarden.

Such a move would force Bitwarden to show their true colors. If they really mean to stay true to the open version they will keep cooperating and keeping their API in sync with the Vaultwarden API.

The current FOSS backend used to be the center of the ecosystem. Going forward that may change. If it stops being that center and it becomes merely a token offering so Bitwarden can claim “we’re still doing FOSS” then it will become pointless.

Simply forking the backend is meaningless without the work to also drag along the entire ecosystem, or establish a new one. Forking a project takes time, effort, vision, persistence, determination.

Everybody can still fork/rename/publish the FOSS version

Yeah, but there’s no guarantee the FOSS version will be the same as the closed one.

Vaultwarden (and all the client apps) depend on Bitwarden for the API spec. If Bitwarden introduces closed features in the API that Vaultwarden can’t/won’t implement, but the client apps do, it will split the spec. They can also introduce API license keys, which would render Vaultwarden mostly irrelevant.

The only way for Vaultwarden to remain relevant going forward is to own it and split ways from Bitwarden. This would in turn mean that the FOSS client apps have to decide which to support. But I think the ecosystem is going to fragment eventually anyway, so the sooner every app decides which way they want to go, the better.

I just wish Syncthing didn’t have such a convoluted port usage, and also that its Android usage didn’t revolve around an unofficial app.

So I’ll stick to apps that do sync over SSH (using FolderSync atm).

Yeah but if you want to use something different, or may need to use different web servers or proxies from time to time, it’s better to have the cert renewal stuff separated.

Also, for any provider that’s off the beaten path you have to build caddy yourself to include the right plugin and that’s just meh.

Caddy’s fine if you only use one provider and only Caddy all the time but other than that no.

That’s the tricky part about self-hosting and it doesn’t get addressed enough. There are virtually zero apps designed with user privacy in mind.

What kind of library scan did you do? “Scan for new and updated files”, “Search for missing metadata” or “Replace all metadata”? The release notes don’t mention what exactly they mean by “full library scan”.

Was probably introduced or re-introduced recently.

Has anybody upgraded from 10.11.11 directly to 12.2?

Yeah if you put it behind a reverse proxy you have lots of options. Basic auth would be the most straightforward but you can also do mTLS with a custom self-generated CA fairly easily. Then there’s OAuth but the setup is usually more involved than either of the above.

Whatever you use you gotta have HTTPS working, that’s very important to keep it secured.

But there’s no absolute truth so the best you can do is try to come to compromises and offer processes to arrive at them fairly. All democracies out there have differences in a lot of factors. You can place some safeguards so the idiots or the evil people can’t take over easily but eventually if enough people want something (even if misguided) it’s gonna happen.

Call slavery ‘freedom’ and then tell the slaves "you’re free!

Be fair now. I’m not talking about outright twisting of words. I’m talking about concrete processes for considering competing points of view before making something into a law.

And you need to strike a balance because if you make such processes very rigid and inaccessible then you may not be subject to new bad ideas but you also won’t be able to shift to new good ideas. Speaking of slavery, it was once upon a time habitual in many societies, but it was the ability to shift our points of view that changed that. Same goes for a lot of other antiquated ideas.

I’m using a similar stack, Radicale on backend, DAVx5, and Calengoo as app.

Calengoo is not open source but you can buy it directly from the developer without Google integration. It’s the only calendar app I’ve found that also does tasks properly, in that if I dismiss a task without explicitly marking it completed the notification will come back. It looks a bit strange out of the box but it has multiple themes and it’s super configurable.

The one thing I don’t like is that it uses a direct connection to CalDAV to mark tasks completed, instead of going through DAVx5 (not sure if it’s a limitation in the Android chain or what).