2026-08-04, 12:10 AM
I ran into an interesting (to me, anyway) issue with my new Jellyfin server hosted in a ProxMox LXC. I could access the web server on port 8096 if I entered the server's IP address, but it would fail if I use the hostname. My DNS server (pihole) is properly providing the IPv4 and IPv6 addresses, reverse lookups all look good -- but access via hostname resulted in "Server unavailable" messages.
I dug into the logs a bit and noticed that the access requests were being rejected because of "RejectDueToRemoteAccessDisabled" which seemed odd since the LAN Networkds block on the network configuration page says "if left blank, all RFC1918 are considered local". Hmmm -- hey, RFC1918 applies to IPv4 addresses... what about IPv6? Well, RFC4193 addresses the notion of Unique Local Addresses for IPv6 similarly to RFC1918, but my IPv6 network uses addresses served up by my router's DHCPv6 (or SLAAC, I forget which) and those addresses are actually public addresses. Jellyfin properly rejects access even though they are in the same /64 netblock as the Jellyfin server itself.
The solution was to explicitly call out both the IPv4 network with it's mask and the IPv6 netblock with it's mask, separated by a comma.
Hope this solves a head scratcher for someone else. I guess I could suggest that the notion of "local LAN" be redefined as the netblocks (both iPv4 and IPv6) where the server resides, but that probably just shifts this to a different set of problems not so easily solved as this one!
I dug into the logs a bit and noticed that the access requests were being rejected because of "RejectDueToRemoteAccessDisabled" which seemed odd since the LAN Networkds block on the network configuration page says "if left blank, all RFC1918 are considered local". Hmmm -- hey, RFC1918 applies to IPv4 addresses... what about IPv6? Well, RFC4193 addresses the notion of Unique Local Addresses for IPv6 similarly to RFC1918, but my IPv6 network uses addresses served up by my router's DHCPv6 (or SLAAC, I forget which) and those addresses are actually public addresses. Jellyfin properly rejects access even though they are in the same /64 netblock as the Jellyfin server itself.
The solution was to explicitly call out both the IPv4 network with it's mask and the IPv6 netblock with it's mask, separated by a comma.
Hope this solves a head scratcher for someone else. I guess I could suggest that the notion of "local LAN" be redefined as the netblocks (both iPv4 and IPv6) where the server resides, but that probably just shifts this to a different set of problems not so easily solved as this one!