Can't get any multicast over Wireguard Server tunnel in asuswrt no matter what

[privacyguy123]

I've posted on all respective Githubs - tried igmpproxy, smcroute and now found pim which doesn't work either.

I want to my devices that tunnel into the router via asuswrt WireGuard Server to be able to control remote control devices in the LAN such as Airplay or Tidal Connect. They don't see any receivers when tunneled in yet can access the router admin panel and AdGuard Home admin panel. 224.0.0.0/4 is added to AllowedIPs in the server.

Here's the kind of output I'm seeing:

Candidate Rendezvous-Point Set ===============================================
RP address       Incoming  Group Prefix        Priority  Holdtime
---------------  --------  ------------------  --------  ---------------------
192.168.50.1     4         224/4               1         65535
169.254.0.1      0         232/8               1         65535
------------------------------------------------------------------------------
Current BSR address: 192.168.50.1

10:25:53.078 Received IGMP v2 Membership Report from 192.168.50.63 to 224.0.0.251
10:25:53.078 accept_group_report(): igmp_src 192.168.50.63 ssm_src 224.0.0.251 group 224.0.0.251 report_type 22
10:25:53.078 accept_group_report(): al_pv=3
10:25:53.078 Change IGMP compatibility mode to v2 for group 224.0.0.251
10:25:53.078 Set delete timer for group: 224.0.0.251
10:25:53.078 Not creating routing entry for LAN scoped group 224.0.0.251
10:25:53.680 Cache miss, src 192.168.50.71, dst 239.255.255.250, iif 1
10:25:53.680 create group entry, group 239.255.255.250
10:25:53.680 create source entry, source 192.168.50.71
10:25:53.680 move_kernel_cache: SG
10:25:54.340 Received IGMP v2 Membership Report from 192.168.50.71 to 239.255.255.250
10:25:54.340 accept_group_report(): igmp_src 192.168.50.71 ssm_src 239.255.255.250 group 239.255.255.250 report_type 22
10:25:54.340 accept_group_report(): al_pv=2
10:25:54.340 Set delete timer for group: 239.255.255.250
10:25:54.340 Adding vif 1 for group 239.255.255.250
10:25:55.184 Received IGMP v3 Membership Report from 192.168.50.100 to 224.0.0.22
10:25:55.184 accept_membership_report(): IGMP v3 report, 32 bytes, from 192.168.50.100 to 224.0.0.22 with 3 group records.
10:25:55.184 accept_group_report(): igmp_src 192.168.50.100 ssm_src 0.0.0.0 group 239.192.0.199 report_type 34
10:25:55.184 Set delete timer for group: 239.192.0.199
10:25:55.184 SM group order from  192.168.50.100 (*,239.192.0.199)
10:25:55.184 create group entry, group 239.192.0.199
10:25:55.184 Adding vif 1 for group 239.192.0.199
10:25:55.184 accept_group_report(): igmp_src 192.168.50.100 ssm_src 0.0.0.0 group 224.0.0.199 report_type 34
10:25:55.184 Set delete timer for group: 224.0.0.199
10:25:55.184 SM group order from  192.168.50.100 (*,224.0.0.199)
10:25:55.184 Not creating routing entry for LAN scoped group 224.0.0.199
10:25:55.184 accept_group_report(): igmp_src 192.168.50.100 ssm_src 0.0.0.0 group 224.0.0.251 report_type 34
10:25:55.184 Set delete timer for group: 224.0.0.251
10:25:55.184 Not creating routing entry for LAN scoped group 224.0.0.251

[troglobit]

Not all multicast is intended to be routed. Use wireshark or tcpdump to inspect the streams' IP TTL value. To route the ttl must be >1.

[privacyguy123]

Not all multicast is intended to be routed. Use wireshark or tcpdump to inspect the streams' IP TTL value. To route the ttl must be >1.

Can't I just force this to be >1 system wide? I've a feeling it's a problem far deeper than that. Like Wireguard or Android compatibility perhaps, but not sure. Could be an ASUS firmware issue also.

Something like this was suggested online:

iptables -t mangle -A PREROUTING -i eth0 -d 239.255.255.250 -j TTL --ttl-inc 2

This also exists in ASUS firmware:

[troglobit]

Measuring and data points are always better than feelings. What did your investigation tell you?

Yea, the iptables truck is one way to increase the TTL on the inbound interface of the router. Provided that's the issue.

[privacyguy123]

Measuring and data points are always better than feelings. What did your investigation tell you?

Yea, the iptables truck is one way to increase the TTL on the inbound interface of the router. Provided that's the issue.

Unfortunately it isn't the issue, as no upnp/multicast/whatevercast devices show up on the tunneled in device after applying any of the settings I've found online, actually ... Looking for guidance.

[troglobit]

Well, you haven't really told me much at all about your setup, so it's quite difficult to help. I assume, beside the obvious TTL, you've checked that the interfaces of your tunnel have the MULTICAST flag set?

[privacyguy123]

I'm on a Asus RT-AX58U (AX3000) with Merlin firmware. Inside the router I have a WireGuard server I can use to tunnel devices in from outside the LAN to access devices in the LAN. This works for example with the router admin panel or AdGuard Home admin panel which is hosted inside the device. It doesn't, however, give me any access to any of the devices in my home that can be remote controlled like casting to Sky box or playing music to a Tidal Connect receiver.

Yes, I've a script on boot adding that flag - when I get back to my PC I can show some screenshots/outputs of you need. I've tried all the very obvious stuff and the workarounds/solutions that people provide online aren't working on my side.

There is a one gentleman who suggests that there is a possibility it's a limitation in Android perhaps and if so then my device will never see the Airplay or Tidal Connect receivers through the VPN tunnel no matter what setting i change. Another speaks about "VXLAN" being needed because "L2 traffic" (needed for these remote apps) doesn't travel over "L3" which is what WireGuard uses but unfortunately this is all way over my head.