H,
I have a setup where I have several networks depending on their security. I would like to broadcast mDNS from the less secure networks to more secure ones to make things like Google Cast works but I'm not sure how to do it. Ideally it would be one way.
(I guess it should be possible with umdns or avahi but I have hard time figuring out if it is possible to filter packages during rebroadcast)
Avahi would be the right tool to help you in this case. For your Avahi config, you will want a config like this:
/etc/avahi/avahi-daemon.conf:
[server]
use-ipv4=yes
use-ipv6=yes
check-response-ttl=no
use-iff-running=no
[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes
[reflector]
enable-reflector=yes
reflect-ipv=no
[rlimits]
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3
The enable-reflector=yes is the key setting there. That is what will "reflect" your mDNS broadcasts from one subnet to the other subnets. Your firewall rules are what control which subnets are allowed to broadcast mDNS in the first place (and those will be the ones that Avahi will reflect for you).
You would need to create firewall rules for each of the subnets you wish to allow mDNS broadcasts from. Here are some examples of how I have this set up to allow my IoT subnet to broadcast mDNS:
FW3:
config rule
option name 'Allow-IOT-mDNS'
option family 'ipv4'
list proto 'udp'
option src 'iot'
option src_port '5353'
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
config rule
option name 'Allow-IOT-mDNS6'
option family 'ipv6'
list proto 'udp'
option src 'iot'
option src_port '5353'
list dest_ip 'ff02::fb'
option dest_port '5353'
option target 'ACCEPT'
If you are using nftables instead, you would be looking at some rules like this:
# Allow mDNS
udp sport mdns udp dport mdns ip daddr 224.0.0.251 accept
udp sport mdns udp dport mdns ip6 daddr ff02::fb accept
This is so that the guests can use the Chromecast in LAN?
Correct, but more explicitly, the firewall rules I listed make it so the firewall will not drop the multicast packets that devices send out on port 5353 for mDNS announcement of their services.
Because those packets are not dropped, the avahi service will see them on the interfaces it is listening on (again, port 5353) and when it sees one of these multicast packets it will then forward it to the other interfaces.
However, you still need to allow traffic from the LAN (in your case) to the specific port(s) in the subnet/zone where the Chromecast sits.
In my particular case, my [trusted] LAN is allowed to establish connections to IPs in my guest and IOT zones, but not vice-versa.
Does this make sense?
Yes, it makes sense, but I don't know if it suits what I need. In my case I have two VLANs, the LAN one and the GUEST one. They have no access to each other. Guests would only have to have access to the LAN connected Chromecast and those on LAN would obviously have to have access as well. Those on LAN shouldn't have access to GUEST either.
This solution can ultimately still fit that use-case. You just would modify the option src in the rules I listed above to be your LAN interface and still set up avahi.
Then, whatever ports Chromecast actually requires for remote casting (8008-8009/TCP and 32768-61000/UDP ??) need to be opened (read: allowed) on your LAN interface to your GUEST interface.
Ok, first I need to know which package to install because searching for avahi shows 18 results.
Yup! 
Here's what I have:
root@OpenWrt:~/sqm-autorate# opkg list-installed | grep avahi
avahi-dbus-daemon - 0.8-7
libavahi-dbus-support - 0.8-7
I have already installed and edited the config file:
root@enrutador:~# cat /etc/avahi/avahi-daemon.conf
[server]
#host-name=foo
#domain-name=local
use-ipv4=yes
use-ipv6=yes
check-response-ttl=no
use-iff-running=no
[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes
#publish-dns-servers=192.168.1.1
#publish-resolv-conf-dns-servers=yes
[reflector]
enable-reflector=yes
reflect-ipv=no
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3
root@enrutador:~# cat /etc/config/firewall
config rule
option name 'mDNS-GUEST'
list proto 'udp'
option src_port '5353'
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
option src 'lan'
I still can't connect to the Chromecast from the guest device.
But you are able to see it is being "advertised" via mDNS now, yes?
I have changed the option src 'lan' rule to option src 'guests' and now the Chromecast appears in the device's Youtube app, but I can't connect.
Great! Progress! Did you create rules to allow the TCP and UDP ports as required? You may want to look them up and confirm exactly what you need
I have added proto list 'tcp' and still can't connect. I press the cast button, choose the Chromecast and it stays "connecting" until after a few seconds it looks like it did before starting the process.
I really don't have any experience working with Chromecast as I'm not a Google-stuff user, to be honest. But I think once you can get the actual required ports nailed down, and I do fully expect there would be some UDP ports for the actual video stream data, I think you have the tools here to make it all work.
Perhaps others with Chromecast/YouTubeCast (???) experience can jump in here and offer some tips, too.
Apparently the Chromecast uses ports 8008-8009/TCP, 32768-61000/UDP and 8443/TCP. Would I have to enter those ports as rules in the Firewall?
Sorry for the delay in responding. Since you have a firewall between your 'lan' and 'guest' VLANs, then you have to approach the situation with the understanding that no traffic should be allow to forward from one to the other without you telling it that is okay.
So if those ports are what your Chromecast unit requires in order to receive the data it is going to be Chromecasting (maybe I made up that word?), then you will need to create rules for those ports to allow traffic originating from 'guest' to 'lan'.
I don't know if you have IPv6 in play as well, but regardless you should be able to create these rules pretty easily. The ports/ranges you found can be IPv4 + IPv6 and will be the destination ports. Source port would be 'any'.
Let me know if any of this doesn't make sense and I can provide more detail. You're about to cross the finish line on this one, it seems!
It works! I can send content from a guest to the Chromecast that is connected to LAN! Here are my final configuration files:
root@enrutador:~# cat /etc/config/network
config device
option name 'br-lan'
option type 'bridge'
option igmp_snooping '1'
option ipv6 '0'
list ports 'bat0.100'
list ports 'eth0.1'
option bridge_empty '1'
option stp '1'
config interface 'lan'
option device 'br-lan'
option proto 'static'
option ipaddr '192.168.1.1'
option netmask '255.255.255.0'
option delegate '0'
config device
option type 'bridge'
option name 'br-invitados'
option stp '1'
option igmp_snooping '1'
option ipv6 '0'
list ports 'bat0.101'
list ports 'eth0.2'
option bridge_empty '1'
config interface 'invitados'
option proto 'static'
option device 'br-invitados'
option ipaddr '192.168.2.1'
option netmask '255.255.255.0'
option delegate '0'
root@enrutador:~# cat /etc/avahi/avahi-daemon.conf
[server]
#host-name=foo
#domain-name=local
use-ipv4=yes
use-ipv6=yes
check-response-ttl=no
use-iff-running=no
[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes
#publish-dns-servers=192.168.1.1
#publish-resolv-conf-dns-servers=yes
[reflector]
enable-reflector=yes
reflect-ipv=no
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3
root@enrutador:~# cat /etc/config/firewall
config zone
option name 'invitados'
option output 'ACCEPT'
option forward 'REJECT'
option input 'REJECT'
list network 'invitados'
config forwarding
option src 'invitados'
option dest 'wan'
config rule
option name 'Bloquear servidores DNS externos en invitados'
option dest_port '53 853'
option target 'DROP'
option src 'invitados'
option dest 'wan'
config rule
option name 'DNS y DHCP de invitados'
option src 'invitados'
option dest_port '53 67 68'
option target 'ACCEPT'
config rule
option src_port '5353'
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
option src 'invitados'
list proto 'tcp'
list proto 'udp'
option name 'mDNS-Invitados'
config rule
list proto 'tcp'
option dest_port '8008-8009'
option target 'ACCEPT'
option name 'Chromecast-8008-8009'
option src 'invitados'
option dest 'lan'
list dest_ip '192.168.1.30'
list dest_ip '192.168.1.31'
config rule
list proto 'udp'
option dest_port '32768-61000'
option target 'ACCEPT'
option name 'Chromecast-32768-61000'
option src 'invitados'
option dest 'lan'
list dest_ip '192.168.1.30'
list dest_ip '192.168.1.31'
config rule
list proto 'tcp'
option dest_port '8443'
option target 'ACCEPT'
option name 'Chromecast-8443'
option src 'invitados'
option dest 'lan'
list dest_ip '192.168.1.30'
list dest_ip '192.168.1.31'
Thanks a lot!
UPDATE: I've narrowed down the rules to just 2 for convenience. I don't know if it's correct but they work.
config rule
list dest_ip '224.0.0.251'
option dest_port '5353'
option target 'ACCEPT'
option src 'invitados'
list proto 'tcp'
list proto 'udp'
option name 'mDNS-Invitados'
option family 'ipv4'
config rule
option target 'ACCEPT'
option src 'invitados'
option dest 'lan'
list dest_ip '192.168.1.30'
list dest_ip '192.168.1.31'
option family 'ipv4'
list proto 'tcp'
list proto 'udp'
option dest_port '8008-8009 8443 32768-61000'
option name 'Chromecast para Invitados'
Oh that’s fantastic!! So glad you were able to get it sorted!
And thanks for sharing your final working configs. That will surely help others in the future!
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.