10.6.2 - LAN Network option not working #2045

Closed
opened 2025-12-21 20:02:40 +01:00 by backuprepo · 14 comments
Owner

Originally created by @eixel05 on GitHub (Aug 16, 2020).

Using 10.5.5, this works perfectly. I'm using ZeroTier to access my JF remotely (I'm behind CGNAT) and I specified in that option all the devices that are actually in the house. I didn't use IP/Netmask. I manually added the IPs. I do this because my setup of ZT is to bridge. So even if I type the in-house private network instead the one given by ZT, I would still reach it. The IP of the bridging hardware is not added under this option.
.
Whenever I access my JF outside the house using my Mobile Data+ZT, that option applies. I don't see those profiles that are specified not to have remote access.

I upgraded to 10.6.2 (I held until the memory leakage is fixed) and found out that the LAN Network option doesn't work anymore. No matter where I access the server, I still see those Profiles that doesn't have remote access and was able to log-in. It's like the option was defaulted to "left blank" thus the in-house subnet, ZT subnet is all considered Local networks. And no matter what you add, it is ignored.

Originally created by @eixel05 on GitHub (Aug 16, 2020). Using 10.5.5, this works perfectly. I'm using ZeroTier to access my JF remotely (I'm behind CGNAT) and I specified in that option all the devices that are actually in the house. I didn't use IP/Netmask. I manually added the IPs. I do this because my setup of ZT is to bridge. So even if I type the in-house private network instead the one given by ZT, I would still reach it. The IP of the bridging hardware is not added under this option. . Whenever I access my JF outside the house using my Mobile Data+ZT, that option applies. I don't see those profiles that are specified not to have remote access. I upgraded to 10.6.2 (I held until the memory leakage is fixed) and found out that the LAN Network option doesn't work anymore. No matter where I access the server, I still see those Profiles that doesn't have remote access and was able to log-in. It's like the option was defaulted to "left blank" thus the in-house subnet, ZT subnet is all considered Local networks. And no matter what you add, it is ignored.
backuprepo 2025-12-21 20:02:40 +01:00
  • closed this issue
  • added the
    stale
    label
Author
Owner

@thr33face commented on GitHub (Aug 16, 2020):

I'm facing potentially the same issue while trying to enforce the 'internet streaming bitrate limit'
Jellyfin is accessed through a reverse proxy on the same /24 (192.168) and I'd like that IP to be considered public instead of local.

Simplified the setup looks something like this:
[jellyfin | .20] -> [reverse proxy 1 | .60] -> [client 1 | .180]

Since the jellyfin logs show all requests coming from the reverse proxy IP, I assumed that setting 'lan networks' to one of these options would treat .60 as public:

  • setting range or IP from lo interface: 127.0.0.0/8 or 127.0.0.1 or 127.0.0.1/32
  • setting only one IP of home /24: .20 or .20/32

But none of these produce the desired results and the internet streaming limit is never enforced. (i.e.: bitrates higher than the set limit can be by users)

@thr33face commented on GitHub (Aug 16, 2020): I'm facing potentially the same issue while trying to enforce the 'internet streaming bitrate limit' Jellyfin is accessed through a reverse proxy on the same /24 (192.168) and I'd like that IP to be considered public instead of local. Simplified the setup looks something like this: [jellyfin | .20] -> [reverse proxy 1 | .60] -> [client 1 | .180] Since the jellyfin logs show all requests coming from the reverse proxy IP, I assumed that setting 'lan networks' to one of these options would treat .60 as public: - setting range or IP from lo interface: 127.0.0.0/8 or 127.0.0.1 or 127.0.0.1/32 - setting only one IP of home /24: .20 or .20/32 But none of these produce the desired results and the internet streaming limit is never enforced. (i.e.: bitrates higher than the set limit can be by users)
Author
Owner

@BaronGreenback commented on GitHub (Aug 16, 2020):

@thr33face Could you test the following please?

In your LAN definition include the IP in [ ] - eg. 192.168.1.0/24,[192.168.1.60/32]

The [ ] (or ! prefix if/when PR3257 gets accepted) is the equivalent to NOT. So to exclude an address from the LAN just enclose it.
This was introduced in 10.6 as a replacement to the virtual interface detection routine which was causing an issue elsewhere.

@BaronGreenback commented on GitHub (Aug 16, 2020): @thr33face Could you test the following please? In your LAN definition include the IP in [ ] - eg. 192.168.1.0/24,[192.168.1.60/32] The [ ] (or ! prefix if/when PR3257 gets accepted) is the equivalent to NOT. So to exclude an address from the LAN just enclose it. This was introduced in 10.6 as a replacement to the virtual interface detection routine which was causing an issue elsewhere.
Author
Owner

@thr33face commented on GitHub (Aug 16, 2020):

@BaronGreenback
Unfortunately this did not work either, even negating the whole subnet does not help.
I also bypassed the reverse proxy, and negated the client IP, that didn't work either.

Log:
[2020-08-16 16:11:05.670 +00:00] [INF] RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.180", IsInLocalNetwork: True

@thr33face commented on GitHub (Aug 16, 2020): @BaronGreenback Unfortunately this did not work either, even negating the whole subnet does not help. I also bypassed the reverse proxy, and negated the client IP, that didn't work either. Log: [2020-08-16 16:11:05.670 +00:00] [INF] RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.180", IsInLocalNetwork: True
Author
Owner

@BaronGreenback commented on GitHub (Aug 16, 2020):

I'll dive into the code and see what's happening.

@BaronGreenback commented on GitHub (Aug 16, 2020): I'll dive into the code and see what's happening.
Author
Owner

@BaronGreenback commented on GitHub (Aug 16, 2020):

Looks like in 10.6.2 it is hard coded, and so is a bug.

It is one of the many network fixes in PR #3257 which i'm currently testing.

@BaronGreenback commented on GitHub (Aug 16, 2020): Looks like in 10.6.2 it is hard coded, and so is a bug. It is one of the many network fixes in PR #3257 which i'm currently testing.
Author
Owner

@thr33face commented on GitHub (Aug 16, 2020):

Thank you for investigating

@thr33face commented on GitHub (Aug 16, 2020): Thank you for investigating
Author
Owner

@BaronGreenback commented on GitHub (Aug 16, 2020):

No problems - would you be up to testing the PR once i've got it running on the new unstable version, to make sure it works?
The PR is massive - so i'm currently doing alpha's before hand to ensure i don't break more than i fix.

@BaronGreenback commented on GitHub (Aug 16, 2020): No problems - would you be up to testing the PR once i've got it running on the new unstable version, to make sure it works? The PR is massive - so i'm currently doing alpha's before hand to ensure i don't break more than i fix.
Author
Owner

@thr33face commented on GitHub (Aug 16, 2020):

Sure, I can help testing to the best of my abilities.
I have a jellyfish instance up and running in a throwaway VM, so doesn't matter if that one breaks in the process.

@thr33face commented on GitHub (Aug 16, 2020): Sure, I can help testing to the best of my abilities. I have a jellyfish instance up and running in a throwaway VM, so doesn't matter if that one breaks in the process.
Author
Owner

@BaronGreenback commented on GitHub (Aug 19, 2020):

Docket image crobibero/jellyfin:3257 is the PR3257.

It's the latest code image - so some interface things may be broken. If you could fire it up and test the networking side, especially with your setup. It has got loads of fixes in it.

@BaronGreenback commented on GitHub (Aug 19, 2020): Docket image crobibero/jellyfin:3257 is the PR3257. It's the latest code image - so some interface things may be broken. If you could fire it up and test the networking side, especially with your setup. It has got loads of fixes in it.
Author
Owner

@thr33face commented on GitHub (Aug 22, 2020):

Have the docker image up and running (the one updated on 2020-08-21T17:14:22) and can observe this behavior:

By excluding the /24 the reverse proxy is correctly limited

LAN Networks: !192.168.10.0/24

[2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["127.0.0.1/8"]
[2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.0/24"]
[2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["127.0.0.1/8"]
[2020-08-22 07:09:23.304 +00:00] [INF] [21] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: False

If I allow the /24 but exclude the /32 the reverse proxy is considered local:

LAN Networks: 192.168.10.0/24, !192.168.10.60/32

[2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["192.168.10.0/24", "127.0.0.1/32"]
[2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.60/32"]
[2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["192.168.10.0/24", "127.0.0.1/32"]
[2020-08-22 07:12:51.141 +00:00] [INF] [16] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: True
@thr33face commented on GitHub (Aug 22, 2020): Have the docker image up and running (the one updated on 2020-08-21T17:14:22) and can observe this behavior: By excluding the /24 the reverse proxy is correctly limited **LAN Networks: !192.168.10.0/24** ``` [2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["127.0.0.1/8"] [2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.0/24"] [2020-08-22 07:06:48.330 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["127.0.0.1/8"] ``` ``` [2020-08-22 07:09:23.304 +00:00] [INF] [21] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: False ``` If I allow the /24 but exclude the /32 the reverse proxy is considered local: **LAN Networks: 192.168.10.0/24, !192.168.10.60/32** ``` [2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["192.168.10.0/24", "127.0.0.1/32"] [2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.60/32"] [2020-08-22 07:11:15.432 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["192.168.10.0/24", "127.0.0.1/32"] ``` ``` [2020-08-22 07:12:51.141 +00:00] [INF] [16] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: True ```
Author
Owner

@BaronGreenback commented on GitHub (Aug 22, 2020):

got it - thanks - will get it fixed.

Thanks for the feedback!

@BaronGreenback commented on GitHub (Aug 22, 2020): got it - thanks - will get it fixed. Thanks for the feedback!
Author
Owner

@BaronGreenback commented on GitHub (Aug 22, 2020):

Just asked for the docker image to be updated - so it may take a while.

Could you test it again please? - I altered the logic - and my tests routines say it should work correctly now.

@BaronGreenback commented on GitHub (Aug 22, 2020): Just asked for the docker image to be updated - so it may take a while. Could you test it again please? - I altered the logic - and my tests routines say it should work correctly now.
Author
Owner

@thr33face commented on GitHub (Aug 22, 2020):

Looking good, working as expected now:

LAN Networks: 192.168.10.0/24, !192.168.10.60/32

[2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["192.168.10.0/24", "127.0.0.1/32"]
[2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.60/32"]
[2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["192.168.10.0/24", "127.0.0.1/32"]

Playing via reverse proxy 192.168.10.60/32

[2020-08-22 17:34:28.875 +00:00] [INF] [19] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: False

Directly access server with unrestricted client 192.168.10.180/32

[2020-08-22 17:37:50.796 +00:00] [INF] [27] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.180", IsInLocalNetwork: True
@thr33face commented on GitHub (Aug 22, 2020): Looking good, working as expected now: **LAN Networks: 192.168.10.0/24, !192.168.10.60/32** ``` [2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN addresses : ["192.168.10.0/24", "127.0.0.1/32"] [2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Defined LAN exclusions : ["192.168.10.60/32"] [2020-08-22 17:34:18.634 +00:00] [INF] [1] Emby.Server.Implementations.Networking.NetworkManager: Using LAN addresses: ["192.168.10.0/24", "127.0.0.1/32"] ``` **Playing via reverse proxy 192.168.10.60/32** ``` [2020-08-22 17:34:28.875 +00:00] [INF] [19] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.60", IsInLocalNetwork: False ``` **Directly access server with unrestricted client 192.168.10.180/32** ``` [2020-08-22 17:37:50.796 +00:00] [INF] [27] Jellyfin.Api.Helpers.MediaInfoHelper: RemoteClientBitrateLimit: 6000000, RemoteIp: "192.168.10.180", IsInLocalNetwork: True ```
Author
Owner

@stale[bot] commented on GitHub (Dec 20, 2020):

This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments.
If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label.
This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on Matrix or Social Media.

@stale[bot] commented on GitHub (Dec 20, 2020): This issue has gone 120 days without comment. To avoid abandoned issues, it will be closed in 21 days if there are no new comments. If you're the original submitter of this issue, please comment confirming if this issue still affects you in the latest release or nightlies, or close the issue if it has been fixed. If you're another user also affected by this bug, please comment confirming so. Either action will remove the stale label. This bot exists to prevent issues from becoming stale and forgotten. Jellyfin is always moving forward, and bugs are often fixed as side effects of other changes. We therefore ask that bug report authors remain vigilant about their issues to ensure they are closed if fixed, or re-confirmed - perhaps with fresh logs or reproduction examples - regularly. If you have any questions you can reach us on [Matrix or Social Media](https://docs.jellyfin.org/general/getting-help.html).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: starred/jellyfin#2045
No description provided.