Weird issue with DLNA PIM and Truenas

RouterOS Forwarding Protocols
1

I have setup a gre tunnel over ipsec to connect two router:

                                                    Internet
MINIDLNA server <---> 10.0.0.0/24 Router1 <---> (Gre Tunnel Over Ipsec) <--->  Router2 (10.0.10.0/24) <---> DLNA client

I have then setup PIM-SM to forward multicast traffic from a testing MINIDLNA server and I managed to have the traffic successifully forwarded from R1 subnet to R2 subnet.

But as soon i tried to multicast the traffic of the real MINIDLNA server (a container in host mode installed on Truenas / Kubernetes) I quickly realized the traffic was not being forwarded.

I really don’t understand the problem, that seems related to the way truenas / kubernetes handle multicast traffic.

Everything works in R1 subnet
In R2 subnet clients can see only the DLNASERVER not inside a container of truenas.
The MINIDLNA server inside truenas kubernetes can be accessed only from R1 clients.

I tried to inspect the traffic with wireshark… but i don’t really understand what is wrong.

Is there soemeone with previous experience with truenas / kubernetes / pim / multicast routing that can help me ?

I’m using routeros 6.49 longterm.

Thanks

2

I realise this is an old thread, but in case this helps anyone trying to do something similar, the ‘usual’ reason that multicast packets aren’t received (when everything is configured correctly) is due to the TTL that is set in the IP header being less than the number of hops between the sender and receiver. In other words the multicast packet expires in transit.

Specifically, I’ve observed that minidlna sets a TTL of 1 (in SSDP NOTIFY messages), and some clients also use a TTL of 1 (in SSDP M-SEARCH messages). Using a TTL of 1 stops the SSDP packet being forwarded outside the local segment. AFAIK minidlna doesn’t have a configuration option to allow you to increase the TTL. A popular way of circumventing this issue is to use a firewall rule to mangle the TTL and increase it to a larger value.

FYI It is worth mentioning that I’ve seen other options described to overcome the TTL issue, such as using EoIP to effectively bridge the local segment to a different location.