VLAN(Trusted) to VLAN (Untrusted) mDNS?

I know as similar question has been asked before but there wasn't any definitive conclusion and as it's been over 1-2 yrs thought I'd ask again :face_with_raised_eyebrow:

Scenario
I have my trusted devices, i.e. synology box, server, laptops, in VLAN (Trusted) and my untrusted, i.e. smart bulbs, speakers and Chromecast and PS4, in VLAN (Untrusted).

What do I want to achieve?
Have any device in the VLAN (Trusted), e.g. phone with Netflix, to be able to cast to the device in my VLAN (Untrusted).

As I understand it Avahi is running ps | grep avahi shows it is and this according to my reading supports mDNS but as my each VLAN is on a different subnet Trusted is 10.0.0.x and Untrusted 10.0.x.0 how can I enable casting from Trusted to Untrusted? I assume a simple FW rule won't do it as I believe Chromecast needs devices to be on the same subnet but there must be a workaround?

What are my reasons for doing this?
I don't trust IoT devices on my network and want them is a walled garden away from my main devices but don't want to loose functionality. This has the added advantage of being easier to understand where traffic is going, isolated IoT traffic and a simple way to killswitch all IoT devices in case of emergency.

1 Like

Ok so after experimentation I thought I would post my results for those wishing to try and get IoT devices on a separate VLAN (here is the related post Advice IoT Devices, Dumb AP with separate Router/DHCP). I have successfully got the majority of the IoT devices on untrusted VLAN (wifi) with internet access but no local access. I have tried to get mDNS reflector running so that you can cast (Chromecast) between subnets which works but unfortunately isn't reliable (something to do with chromecast constantly pinging out <1ms and maybe the reflector can't keep up). I ended up with the most untrusted (bulbs, PS4 etc running in the untrusted vlan) but haven't yet with the Chromecast without having to do init scripts to restart things ever second which just seems like it a workaround than a working config so have abandoned this for the moment.

Hope someone finds this helpful.

I guess, this can be done with smcroute.
mdns uses multicast address 224.0.0.251 and port 5353(?).

Some (IoT) devices use "normal" broadcasts to find other devices.
You can use iptables TEE to "forward" those broadcasts between the networks.
Use the subnets broadcast address as gateway.
Also make sure to set a TTL of 1 otherwise you end up in a broadcast loop.
This is also useful for other applications, for example some games.

@shm0 thanks for the pointer I have set a rule to allow 5353 from any to any but I'm not sure about the other elements in your explanation, i.e. smcroute, specifying TTL of 0 and use the subnets broadcast as gateway. Sorry for my naivety I not an expert by any stretch but after years of tinkering I have some knowledge (dangerous I know :wink:). If you could provide me with a bit more detail I will try an implement this as full setup for IoT and write it up for the community.

For the moment, forget about the iptables TEE part. (also fixed typo, I meant TTL of 1)

First I have to read up how mdns works in detail :stuck_out_tongue: :wink:

The "reflector" you used was it avahi?

Okay.
So seems like,
mDNS requests are sent to 224.0.0.251:5353
mDNS responses are sent to 224.0.0.251:5353 too but unicasts responses are also possible.

smcroute config

mgroup from vlan1-interface group 224.0.0.251
mgroup from vlan2-interface group 224.0.0.251
mroute from vlan1-interface group 224.0.0.251 to vlan2-interface
mroute from vlan2-interface group 224.0.0.251 to vlan1-interface

firewall config:
/etc/config/firewall

config rule
	option name 'VLAN1-ZONE-FORWARD-ACCEPT-MDNS'
	option family 'ipv4'
	option proto 'udp'
	option src 'vlan1'                         
	option dest 'vlan2'   
	option dest_ip '224.0.0.251'
	option dest_port '5353'
	option target 'ACCEPT'

config rule
	option name 'VLAN2-ZONE-FORWARD-ACCEPT-MDNS'
	option family 'ipv4'
	option proto 'udp'
	option src 'vlan2'                         
	option dest 'vlan1'   
	option dest_ip '224.0.0.251'
	option dest_port '5353'
	option target 'ACCEPT'

/etc/firewall.user
Increase/Set TTL of the multicast packets:

iptables -t mangle -A PREROUTING -i vlan1-interface -d 224.0.0.251 -m ttl --ttl-gt 0 -j TTL --ttl-set 2
iptables -t mangle -A PREROUTING -i vlan2-interface -d 224.0.0.251 -m ttl --ttl-gt 0 -j TTL --ttl-set 2

In theory this should allow mDNS requests/responses to be forwarded/routed between the networks. :thinking:
Additional firewall rules are needed for each service you want to be forwarded between the vlans.
But it seems like 224.0.0.X addresses are not allowed to be forwarded/routed.
According to this post:


So reflector is the way to go here?

Doesn't Chromecast use DLNA?

iptables TEE:
For example, D-Link (don't buy anything from D-Link :smile:) offers an app for mobile phones to access IP cameras.
It uses broadcasts to discover the camera(s) on the network. (255.255.255.255:5978)
Of course, that doesn't work if the camera(s) are on a different VLAN (broadcast domain).
The idea is now, to use iptables TEE to duplicate the broadcast from one interface to another.
Assuming:
VLAN1: 192.168.0.0/24 (Broadcast address 192.168.0.255)
VLAN2: 192.168.1.0/24 (Broadcast address 192.168.1.255)

iptables -t mangle -A INPUT -i vlan1-interface -p udp --dport 5978 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TTL --ttl-set 1
iptables -t mangle -A INPUT -i vlan2-interface -p udp --dport 5978 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TTL --ttl-set 1

iptables -t mangle -A INPUT -i vlan1-interface -p udp --dport 5978 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TEE --gateway 192.168.1.255
iptables -t mangle -A INPUT -i vlan2-interface -p udp --dport 5978 -d 255.255.255.255 -m ttl --ttl-gt 0 -j TEE --gateway 192.168.0.255

I haven't tested this yet but I think it should work. :sweat_smile:

Thank you for the additional detail this should get me up a running, I didn't realise you could specify TTL settings in the iptables rules (learning everyday :grinning:). I was using avahi with the reflector setting turned on which I am assuming provides the same function as smcroute except rather than rely on automatic routing between them this specifically only allows the multicast routing specified? or do I need both?

According to a quick search Chromecast doesn't use DNLA and I found this article which could be useful for someone else so here's the link; https://www.cisco.com/c/en/us/td/docs/wireless/controller/technotes/7-6/chromecastDG76/ChromecastDG76.html (amazing detail on the device).

Seems like Chromecast is discovered as follows:

"Chromecast discovery packets rely on the DIAL protocol operating at UDP port 1900 and send the requests to the address 239.255.255.250. Ensure that no firewall blocks connectivity between the Chromecast device and wireless client."

Also it seems like the Cisco recommendation for the broadcast is this (I'll try this too):

"The group address is an IPv4 multicast group and is recommended to be in the 239.x.x.x-239.255.255.255 range which is scoped for private multicast applications. Do not use the 224.x.x.x, 239.0.0.x, or the 239.128.0.x address ranges for the multicast group address. Addresses in these ranges overlap with the link local MAC addresses and flood all switch ports, even with IGMP snooping enabled."

Thanks again :slight_smile: I'll try out the settings to see if I can get it working.

Did you ever get this working being able to cast content from your phone on the LAN VLAN to the IoT VLAN containing a Google Chromecast for example?

I'm investigating this myself and it looks like the more standard solution to this is to use a mDNS proxy rather than rewriting stuff at the firewall level. (credit to https://www.vivitek.eu/Download/Documents/Enabling_iOS_Mirroring_in_a_Multiple-subnet_Environment.pdf which randomly came up in search results…)

Haven't tried it myself yet, but I found this article which has a nice walkthrough of the setup specific to OpenWrt no less:

https://blog.christophersmart.com/2020/03/30/resolving-mdns-across-vlans-with-avahi-on-openwrt/

1 Like