SOLVED: IPv6 is disabled on the OS but Jellyfin thinks that's not the case

[kt7brwahvw]


[2024-08-21 01:40:13.133 +00:00] [WRN] [19] Jellyfin.Networking.Manager.NetworkManager: IPv6 is disabled in Jellyfin, but enabled in the OS. This may affect how the interface is selected.



I see these messages in my log, I've told Jellyfin to disable IPv6. Jellyfin is running in a docker image with --net=host (docker inspect output):


            "Networks": {
                "host": {
                    "IPAMConfig": null,
                    "Links": null,
                    "Aliases": null,
                    "NetworkID": "755a10c5d668b5b556950d09432e1a54bb0ae7b0b3050c6cf2ca6b31f908f9f8",
                    "EndpointID": "df49755aa3773b1704ed1210b5b602eb15c1ac636a616f44ac37c97c1885d23b",
                    "Gateway": "",
                    "IPAddress": "",
                    "IPPrefixLen": 0,
                    "IPv6Gateway": "",
                    "GlobalIPv6Address": "",
                    "GlobalIPv6PrefixLen": 0,
                    "MacAddress": "",
                    "DriverOpts": null
                }
            }



And I've confirmed on my host machine that runs the docker that there is no IPv6 interface:


docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:7e:ca:aa:8c  txqueuelen 0  (Ethernet)
        RX packets 719  bytes 153740 (153.7 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1087  bytes 931818 (931.8 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.195  netmask 255.255.255.0  broadcast 192.168.1.255
        ether 00:e0:4c:24:bd:66  txqueuelen 1000  (Ethernet)
        RX packets 14672457  bytes 6797505246 (6.7 GB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 14213104  bytes 6816726758 (6.8 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 433679  bytes 289539298 (289.5 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 433679  bytes 289539298 (289.5 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vpn: flags=81<UP,POINTOPOINT,RUNNING>  mtu 1420
        inet 103.54.3.22  netmask 255.255.255.255  destination 10.5.0.2
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 1000  (UNSPEC)
        RX packets 12665070  bytes 6118818108 (6.1 GB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11696589  bytes 2677073572 (2.6 GB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 54:f2:9f:3c:82:23  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0



I'm at a loss because I did see an IPv6 address connect to the machine successfully, so I really don't know what's going on:


[2024-08-20 21:53:53.911 +00:00] [WRN] [52] Emby.Server.Implementations.HttpServer.WebSocketConnection: WS "<Client IPv6 Address>" error receiving data: "The remote party closed the WebSocket connection without completing the close handshake."



My reverse proxy even terminates the SSL connection and sends things over via IPv4. Too much to paste here for my nginx config, but you'll have to trust me :)

[TheDreadPirate]

The client IP (which I censored in your post, btw) is included as a header when using a reverse proxy. This line is probably in your Nginx config.

Code:

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

I'm assuming Nginx is running on the same host as Jellyfin. In which case Jellyfin is already reading the X-Forwarded-For header without having to configure the "known proxies" setting. And the code that prints that warning message doesn't appear to distinguish between a forwarded and real address. So, yes, Jellyfin itself is using IPv4 to and from the proxy. And since there is no IPv6 address the proxy is also sending out via IPv4. But most ISPs will use one or more technologies to allow IPv4 and IPv6 devices to talk to each other.

Look up "Toredo Tunnels" and "6to4".

This message can be safely ignored as long as it isn't causing any actual problems. Which is why the log level is WRN and not ERR.

[kt7brwahvw]

Thanks for your reply. The nginx reverse proxy is not on the same machine, it is a different machine. The architecture is router ->nginx machine -> jellyfin machine. Thanks for those links to review, much appreciated, looks like that 6to4 is what's going on. I'll mark this as solved but I hate seeing those warnings