Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trusted network detection doesn't work for ipv6 #1754

Open
acsawdey opened this issue Apr 22, 2024 · 6 comments
Open

trusted network detection doesn't work for ipv6 #1754

acsawdey opened this issue Apr 22, 2024 · 6 comments

Comments

@acsawdey
Copy link

Recently my ISP got full support working for ipv6, so naturally I enabled it in my router and local network and things broke.

This is owntone 28.9 running on a RPi4 with Debian 11.9 bullseye.

With the default trusted_networks setting of { "localhost", "192.168", "fd" } I see a number of things fail coming from a Mac that is using ipv6 address on the local net:

[2024-04-22 09:36:14] [ LOG] httpd: Web interface request to '/' denied: No password set in the config
Going to :3689 on my owntone server got a "403 Forbidden" response.

dacp: Unauthorized request '/ctrl-int/1/getproperty?properties=dmcp.volume' from '2001:48f8:7049:1ad2:93a1:f52e:4179:66d1' (is peer trusted in your config?)
Continuous spamming of these messages with a few different addresses, all of which are on my local network.

It looks like you don't look for a :fe80: prefix for link-local addresses, maybe that should be added. However these dacp requests are not coming from :fe80: but rather from my unique ipv6 prefix :2001:48f8:7049:1ad2: so I'm not quite sure how to fix that. Adding "any" to trusted_networks does fix it though, so this is likely where the solution lies.

Adding :fe80: by default should be ok since you are already doing essentially the same thing by adding "192.168" in there. I suppose you can probably figure out the local network prefix with getifaddrs() and see if the incoming request address matches.

@ejurgensen
Copy link
Member

I'm not sure about ipv6, but for ipv4 link-local-addresses are not source addresses in intra-lan communication, so adding them wouldn't do anything. I did try to google research what the ipv6-version of 192.168 is, and as I remember there wasn't necessarily an answer, but fd seemed like the best option. Otherwise, like you say, it would be necessary to check the subnet with something like getifaddrs().

@ejurgensen
Copy link
Member

This StackExchange says that fc and fd are "Unique local address": https://superuser.com/questions/917903/what-is-the-ipv6-equivalent-of-192-168-xxx-xxx

Do you not have such addresses in your local network?

@acsawdey
Copy link
Author

acsawdey commented May 1, 2024

I do have link local addresses, sure. The problem is that they don’t necessarily get used when talking to owntone. I don’t know that there is a way to make that happen. And it’s the source address for the incoming request that’s being examined to see if it is local.

@ejurgensen
Copy link
Member

My question wasn't about link-local

@acsawdey
Copy link
Author

acsawdey commented May 1, 2024

What I’m saying is what that second answer at that link says .. it is local if it is the same /64 as your IPv6 address. The problem is you can’t force other systems to use a particular address for themselves and if they’re doing IPv6 they likely just use the globally unique address because that’s kind of the point of IPv6.

@stefangehn
Copy link

FWIW I also had problems with adding my local ipv6 subnet(s) to the allowlist in owntone and eventually went with disabling ipv6 in owntone which my devices all seem to handle fine so far (airplay + browsers on different platforms).

In my case I receive a dynamically assigned subnet from my provider but trying to add a wildcard entry for the fixed part of it didn't work (would probably need to add debug output for the matching to find out why).

I'm not entirely sure how to even securely handle this in owntone. It probably would need to adapt based on the ip addresses (and its mask) on one of the interfaces of the machine it is running on instead of using a fixed list of allowed address prefixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants