Misunderstanding of the multicast firewall added by GrapheneOS

Cypher

Hi!
I ran tcpdump to look at my phones traffic and saw that my Pixel 6a (GOS Build 2025041100) is sending multicast packets directly over the WiFi interface (not over VPN), despite having VPN with "Always-On" and "Block connections without VPN" enabled.

So far I've seen non-VPN multicast packets when opening the YouTube app ( _googlecast._tcp.local. ) and Spotify ( _spotify-social-listening._tcp.local. ).

This kind of leak was fixed at least once in the past: https://github.com/GrapheneOS/os-issue-tracker/issues/3443
But it seems it is a problem again? Unless I am doing something wrong?

Any input welcome! Thanks!

Carlos-Anso

Cypher
All apps and the VPN are set up in the same user profile, work profile or private space?

GrapheneOS

Cypher ryrona This is not part of the multicast packet leaks from apps we already fixed but rather mDNS. It's not a new discovery but rather something we have known about for a while. It's one of 2 issues we discovered ourselves a while ago and implemented changes to fix but have not shipped yet due to lack of resources and compatibility concerns. The main developer working on this had to go away for a while and now due to our lead developer being conscripted into a war needs to focus on preparing for the port. There's little point telling us about either the mDNS or per-interface socket configuration issues we know about already.

ryrona

Can you please also tell which VPN app, and double check you haven't enabled access to local network inside the VPN app settings, and also haven't enabled split tunneling inside the VPN app settings. And can you tell exact steps to reproduce, eg, what to click on in YouTube and Spotify apps for the multicasts to happen?

I can try to reproduce when you have answered.

Cypher

ryrona
I think you can try to reproduce it by installing Wireguard app (even without any active tunnel, or a dummy tunnel to a fake target) and enabling "Always-on VPN" and "Block connections without VPN". Then open Spotify without any other input. Or open YouTube and click on the cast icon.

I tested it exactly like this (no active tunnel) in my previous reply and still saw multicast traffic from my phones WiFi IP.

Cypher

Yes, it's all in the same main user profile.
I use the the regular Wireguard VPN App (from Google Play Store) with "Allowed IPs" set to"0.0.0.0/0, ::/0", which should cover everything? There is an "exclude app" feature but no apps are enabled. (For testing I excluded 1 app, but that app was NOT able to connect outside of the VPN when "Block connections without VPN" was enabled too.)

For Spotify it happens soon after opening the app, no further interaction needed. For YouTube it happens when I open the app and then click the "Cast" button.

tcpdump example of the sudden burst of multicast traffic when I open Spotify:

19:09:27.287825 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40
19:09:27.287864 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40
19:09:27.565605 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40
19:09:27.565639 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40
19:09:28.176076 IP 192.168.0.36 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:09:28.176111 IP 192.168.0.36 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:09:28.176283 IP6 fe80::10e1:a5ff:fe11:6027 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:28.176309 IP6 fe80::10e1:a5ff:fe11:6027 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:28.178423 IP 192.168.0.36.5353 > 224.0.0.251.5353: 1 PTR (QU)? _spotify-social-listening._tcp.local. (54)
19:09:28.178449 IP 192.168.0.36.5353 > 224.0.0.251.5353: 1 PTR (QU)? _spotify-social-listening._tcp.local. (54)
19:09:28.183768 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 1 PTR (QU)? _spotify-social-listening._tcp.local. (54)
19:09:28.183819 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 1 PTR (QU)? _spotify-social-listening._tcp.local. (54)
19:09:28.557561 IP 192.168.0.36 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:09:28.557599 IP 192.168.0.36 > 224.0.0.22: igmp v3 report, 1 group record(s)
19:09:29.100729 IP6 fe80::10e1:a5ff:fe11:6027 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:29.100765 IP6 fe80::10e1:a5ff:fe11:6027 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28
19:09:29.184100 IP 192.168.0.36.5353 > 224.0.0.251.5353: 2 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:29.184132 IP 192.168.0.36.5353 > 224.0.0.251.5353: 2 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:29.187122 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 2 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:29.187148 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 2 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:30.193631 IP 192.168.0.36.5353 > 224.0.0.251.5353: 3 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:30.193676 IP 192.168.0.36.5353 > 224.0.0.251.5353: 3 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:30.193632 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 3 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:30.193891 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 3 PTR (QM)? _spotify-social-listening._tcp.local. (54)
19:09:30.565554 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40
19:09:30.565593 IP 192.168.0.36.57621 > 192.168.0.255.57621: UDP, length 40

Most non-multicast traffic seems to be properly going through VPN (except ARP, DHCP, connectivity checks of course). But for some reason multicast can sidestep the Wireguard VPN.

I tried restarting the Wireguard Tunnel and rebooting my phone completely, but nothing changed at all.

Also, this still happens when NO tunnel is active. Wireguard installed, "Always-on VPN" and "Block connections without VPN" is still toggled on, but the tunnel in the Wireguard app is toggled off. So no traffic can flow at all (apps are endlessly loading, etc...), but when starting Spotify it will still broadcast/multicast into the WiFi.

Cypher

Now it gets weirder. I turned off "Block connections without VPN" (everything else is the same. Wireguard is active, etc...) and started Spotify.
Now I see some more broadcast/multicast targets ADDITIONALLY to the above log:

19:28:21.079733 IP 192.168.0.36.5353 > 224.0.0.251.5353: 1 [3q] PTR (QU)? _DB5EE813._sub._googlecast._tcp.local. PTR (QU)? _CC32E753._sub._googlecast._tcp.local. PTR (QU)? _googlecast._tcp.local. (77)
19:28:21.080284 IP6 fe80::10e1:a5ff:fe11:6027.5353 > ff02::fb.5353: 1 [3q] PTR (QU)? _CC1AD845._sub._googlecast._tcp.local. PTR (QU)? _CC32E753._sub._googlecast._tcp.local. PTR (QU)? _googlecast._tcp.local. (77)
19:28:21.163639 IP 192.168.0.36.5353 > 224.0.0.251.5353: 0 PTR (QM)? _spotify-connect._tcp.local. (45)
19:28:21.163668 IP 192.168.0.36.5353 > 224.0.0.251.5353: 0 PTR (QM)? _spotify-connect._tcp.local. (45)
19:28:23.137795 IP 192.168.0.36.57789 > 239.255.255.250.1900: UDP, length 125
19:28:23.137821 IP 192.168.0.36.57789 > 239.255.255.250.1900: UDP, length 125

THESE kinds of packets do NOT show up whenever I re-enable "Block connections without VPN".
So, that toggle definitely does filter SOME multicast messages, but not all...

ryrona

Cypher Thank you for your instructions. I will try to reproduce as soon as I have some free time, probably in a few days. I have a VPN subscription that supports wireguard configuration files I can try with. This sounds oddly similar to the leaks that have already been fixed, so that's weird.

ryrona

GrapheneOS Oh, okay. I thought it was only some rare corner-case leaks that were left, not common cases of how applications actually use the network. That makes the remaining leaks way more concerning for common use cases where anonymity is expected.

Are there any tickets on the bug tracker about these remaining issues? I couldn't find any when looking. Would be great if they could be created otherwise, for visibility towards the community. I understand you might not have any resources right now for fixing this though, it is a very unfortunate situation. I wished I could help get these remaining leaks fixed, but I have higher priorities elsewhere right now. Maybe in half a year or something.

I will still try to reproduce these findings, and create tickets about it if none exists already, for visibility towards us in the community. And this probably means I need to scan my own setup more closely, so I don't have apps that do multicasts this way in my VPN profile.