Need direction for multicast proxying in segregated VLAN network

Installing and Using OpenWrt Network and Wireless Configuration
1

A few discovery protocols (most prominently mDSN DNS-SD and UPnP SSDP) that are used by end consumer products are using multicast for transport. Unfortunately when setting up a smart home, you cannot ignore those discovery protocols, because often you have no control how the proprietary products discover their peer nodes.

Also, if you set up a smart home, you will have a non-negligible number of nodes with untrustworthy firmware that you may want to segregate from you trusted nodes, and possibly even from the internet. This leads you to a segmented network using VLANs. There are several ways of doing it. For this post I would like to focus only on a setup like this:

(1) 1x OpenWRT router (not using AP functionality) accessing the VLANs via a trunked interface to a managed switch (e.g. Ubiquity Unify Switch),
(2) with NO interface bridging on the side of OpenWRT, hence IGMP snooping disabled.
(3) Let us also assume that all multicast senders and receivers are on wired ethernet connections, so there is NO need to convert multicast traffic to directed unicast datastreams for better WiFi performance.

The main challenge is getting the multicast discovery datagrams form the sender's subnet to the subnets containing relevant receivers:
(4) these UDP multicast datagrams usually have a TTL of 1, and
(5) we assume that we have no way of influencing that by configuring the sender (e.g. a Logitech Harmony Hub, or a Sony PlayStation).

For sender appliances using mDNS DNS-SD there is a simple solution available: AVAHI with enabled "reflector" (think "proxy") will pick up the multicast packets destined to port 5353 and re-transmits them on the other subnets. This solves the TTL=1 problem elegantly. Unfortunately AVAHI is specifically targeting mDNS and does not work for UPnP SSDP datagrams (UDP port 1900).

Therefore I am looking for a more general solution, possible not involving datagram mangling using firewall rules to increase the TTL by 1.

Looking around I found a number of candidate solutions, but I am not sure which are the right direction:

  • smcroute with pimbd: does not seem not to solve the TTL=1 issue
  • igmpproxy with udpx: solves the problem subscribing to upstream WAN multicast groups and converting the downstream multicast traffic to unicast for better Wifi performance.
  • mcproxy: not sure what exactly it does but it seems to create a unidirectional proxy that re-transmits UDP multicast datagrams from 1 subnet to a configurable set of other subnets
  • omcproxy: see mcproxy

Maybe someone more enlightened than me can shed more light on these? Which of those would work for the use case described above?

Thanks for helping out!
J/C

1 Like
2

Have a look here.

3

Thanks but it does not fit the scenario. They are using bridged interfaces. See assumption (2). Would that work anyway?

4

You can do it without bridges. Adapt the interface names to your setup.

5

Will do. Let see.

6

These discovery protocols typically use link-local multicast (e.g. 224.0.0.0/24 or ffx2::/16) .

What you're asking for may not be possible because receiving devices will likely drop packets destined to link-local multicast groups that do not originate from any directly connected prefixes. IGMP snooping isn't a factor because receiving hosts don't send IGMP join requests for link-local multicast, so there's nothing to snoop. The filtering mechanism will ignore link-local multicast and treat it as if it were a broadcast packet ( send it out every port). Also trying to modify the TTL ( or hop limit ) may also have challenges because the standard defines link-local multicast as non-routable, but that may not be an issue for Linux.

I'm not saying definitively that what you're trying to do isn't possible but you are coloring outside the lines, and you will be at the mercy of all of the devices' networking implementations. It only takes one random device on your network to have a compatibility issue to cause problems. I've seen weird things happen even when it should all be working as it was all standards based stuff. For example, I found a bug in a smart water meter/shutoff device. It works fine with the cloud service until you add DHCP option 121 to the scope, then it starts randomly disconnecting from wifi. The project I was working on had nothing to do with this device other than being on the same network.

Unfortunately, most consumer crap is designed with a whole set of assumptions about a typical home network (i.e. a single L2 segment). The only real requirement from consumers is that it starts working right out of the box on the lowest common denominator network. There isn't much money in accommodating such a small niche of home users that want to lock down their network.

My recommendation is to look into Linux L2 filtering and use a single segment that spans multiple vlans ( bridged on the OpenWRT device). In Linux there are multiple ways of doing this (ebtables, forcing iptables on ethernet frames, or nftables). I'll probably do some more research as I may want to do something similar in the future; let me know if you find anything.

1 Like
7

Do I get you right? Are you saying I should bridge the segments that need to talk UPnP (instead of routing them) and filter between those segments using L2 filters?

1 Like
8

Yes, L2 filtering will allow you to setup security zones, each on a separate vlan.