Lan Networks settings causing issues after updating to 4.7.12.0

[cosmotherobot 6]

This may not be Qnap related, but I'm posting it here since that is the OS.    Since updating to 4.7.12.0  any entry at all in Lan Networks results in a 'forbidden' error when accessing from web browser on the local network.   Reverting to 4.7.11.0 resolves the issue.      My entries are 192.168.0.0/255.255.255.0,10.0.5.0/255.255.255.0,100.0.0.0/8

The server log shows this:

2023-05-27 10:00:01.799 Error NetworkManager: Invalid lan networks setting: 192.168.0.0/255.255.255.0

2023-05-27 10:00:11.164 Error NetworkManager: Invalid lan networks setting: 10.0.5.0/255.255.255.0

2023-05-27 10:00:15.489 Error NetworkManager: Invalid lan networks setting: 100.0.0.0/8

 

Edited May 27, 2023 by cosmotherobot

[cosmotherobot 6]

I should have added the reason for 100.0.0.0/8  is so I can access it like a local lan while using Tailscale since that is the address assigned the clients.    The server is not exposed to the internet at all.

[rbjtech 4284]

So 100.0.0.0/8 is not only a huge supernet (16 Million Addresses) - it is also not an RFC 1918 address - so I'm wondering if the recent changed have now banned these from being defined as 'local' - because technically, even though not being routed on the internet, using them in this fashion is not confirming to RFC standards.

Is there any reason you cannot use an RFC 1918 range ?  ie anything from 10.0.0.0/8, 192.16.0.0/12 or 192.168.0.0/16 ?

@softworkzFYI

Edited May 27, 2023 by rbjtech

[cosmotherobot 6]

I was being lazy when assigning 100.0.0.0/8.    Tailscale assigns devices in my network with a CGNAT ip   so I can narrow it down by using 100.64.0.0/10.   Unfortunately that subnet cannot be changed.   But only my specific devices are able to access my internal network and therefore the server.   

But - even if I remove that subnet from the list of Lan Networks and only include the RFC 1918 subnets - it still results with the same error using 4.7.12.0.   So there is still a bug there i believe.

 

Edited May 27, 2023 by cosmotherobot

[rbjtech 4284]

1 minute ago, cosmotherobot said:

I was being lazy when assigning 100.0.0.0/8.    Tailscale assigns devices in my network with a CGNAT ip  so I can narrow it down by using 100.64.0.0/10.     But only my specific devices are able to actually able to access my internal network and therefor the server.  

But - even if I remove that subnet from the list of Lan Networks and only include the RFC 1918 subnets - it still results with the same error using 4.7.12.0.   So there is still a bug there i believe.

 

hmm interesting - I define these myself as my local vlan's and do not see any errors, but I'm on the latest beta.

Did you try /24 as opposed to the subnet ?  - ie 192.168.0.0/24 

If removed entirely (letting emby use its self discovered lan emby is hosted on) - I presume this is ok ?

[cosmotherobot 6]

2 minutes ago, rbjtech said:

hmm interesting - I define these myself as my local vlan's and do not see any errors, but I'm on the latest beta.

Did you try /24 as opposed to the subnet ?  - ie 192.168.0.0/24 

If removed entirely (letting emby use its self discovered lan emby is hosted on) - I presume this is ok ?

It did work when I removed all entries completely.   I'll mess around with different network notations later this afternoon and see what happens.

[softworkz 3338]

Is your package for QNAP based on MONO?

I think there was an error due to an unimplemented API detail on MONO.

@Luke- Did I see right that there was a fix for this just these days?

[Luke 37099]

Can you please attach or pm the Emby server log? Thanks.

[cosmotherobot 6]

 

4 hours ago, rbjtech said:

Did you try /24 as opposed to the subnet ?  - ie 192.168.0.0/24

That was it!  - using CIDR notation instead of the netmask  made it happy under 4.7.12.0.      Attached log with the error in case its useful.

Thanks for everyone's responses

embyserver.txt

[Luke 37099]

18 hours ago, cosmotherobot said:

 

That was it!  - using CIDR notation instead of the netmask  made it happy under 4.7.12.0.      Attached log with the error in case its useful.

Thanks for everyone's responses

embyserver.txt 46.48 kB · 0 downloads

Thanks. To be honest I hadn't seen anyone use it this way before, but we should be able to get that supported again.

 

[stankunas.justas 0]

I have just faced similar issue.. I am running Emby on Synology NAS, but as standard Docker container. after updating from 4.7.11.0 > 4.7.13.0 i started receiving "forbidden" as well..

I had LAN networks defined via CIDR notation since the beginning (192.168.X.0/24, 192.168.Y.0/24). but after this update I had to add additional one "172.27.0.0/24" which is docker bridge network. 

 

[rbjtech 4284]

1 hour ago, stankunas.justas said:

I have just faced similar issue.. I am running Emby on Synology NAS, but as standard Docker container. after updating from 4.7.11.0 > 4.7.13.0 i started receiving "forbidden" as well..

I had LAN networks defined via CIDR notation since the beginning (192.168.X.0/24, 192.168.Y.0/24). but after this update I had to add additional one "172.27.0.0/24" which is docker bridge network. 

 

I believe the 172 subnet classification emby uses is incorrect as I've seen this before - otherwise it would class this as a local network. (RFC1918)

The 172 range should be within 172.16.0.0 - 172.31.255.255  (ie 172.16.0.0/12) - which your bridge network obviously falls into  ...

Edited June 20, 2023 by rbjtech

[softworkz 3338]

6 minutes ago, rbjtech said:

I believe the 172 subnet classification emby uses is incorrect as I've seen this before - otherwise it would class this as a local network. (RFC1918)

The 172 range should be within 172.16.0.0 - 172.31.255.255  (ie 172.16.0.0/12) - which your bridge network obviously falls into  ...

This is "private address space" - but it's rarely really your own "local network". The "local network" classification is bogus anyway and will be completely dropped for 4.8.

172.16.x.x is often used in hotels, airports, mobile network access point links, etc., that's why we dropped it in 4.7.13. We didn't drop 192.168.x. x with the stable update in order not to cause too much trouble for existing installations. It's more likely that those networks are really a "local network", but not guaranteed either. We just made the cut in the middle based on the share of cases.

[stankunas.justas 0]

Well until it is configurable I don't think it is a problem at all. only problem I can see is that without this tread I couldn't figure out what is happening. I managed to to add 1 + 1 and relate this to the update. but that's it..  in standard logs output for docker container (stdout/sderr) there was not error or info lines for blocked access because "you are not in allowed list" or something like that. unless I don't know where to look actually (especially when UI is down because of 403) - could you please add additional logging for this? 

[rbjtech 4284]

44 minutes ago, softworkz said:

This is "private address space" - but it's rarely really your own "local network". The "local network" classification is bogus anyway and will be completely dropped for 4.8.

172.16.x.x is often used in hotels, airports, mobile network access point links, etc., that's why we dropped it in 4.7.13. We didn't drop 192.168.x. x with the stable update in order not to cause too much trouble for existing installations. It's more likely that those networks are really a "local network", but not guaranteed either. We just made the cut in the middle based on the share of cases.

ok - thanks for the details - but why does emby not state this ?

The text below just needs to be corrected to say ....subnets 10.0.0.0/8, 192.168.0.0/16 (remove the etc - there are no other networks (excl 172) that are part of RFC1918..)

It should also says that 172.16.0.0/12 is not considered a local network in this context and thus will be subject to external bandwidth restrictions.   It's primary use here is for VPN's - that you want treated the same as a WAN connection.   That is, afterall, the real reason for adding these options ?

 

Edited June 20, 2023 by rbjtech

[softworkz 3338]

10 minutes ago, rbjtech said:

ok - thanks for the details - but why does emby not state this ?

It has been wrong before. 10.x.x.x weren't considered local. As for the 'why' I can't answer where its gotten stuck. I had forwarded the matter when the change was made.