Chromecast across two subnets

Hello Forum,

I've set up a 5Ghz Wifi for auxiliary devices like Amazon Echos and Google Chromecasts (2nd Generation and an Audiocast).

The interface (192.168.4.*) has access to the wan for Internet only and is excluded to access lan via Firewall forwarding rules ("aux-zone").

The Amazon Echos work correctly, Chromecast can show images from the Internt, but streaming and casting from Devices in the lan (192.168.2.*) is not possible, as the Chromecast can not be found.

After a lot of unsuccessful trial and setting um iptable rules like discussed [in this post] ( https://blog.g3rt.nl/allow-google-chromecast-host-firewall-iptables.html), I finally created a Forwarding Rule to allow any traffic from any host via any protocol in the "aux-zone" to any host via any protocol in the lan zone, but even that did not help.

Could anyone of you get Chromecasts to work in different subnets and if so, how is your approach and your solution?

Thanks a lot for you help

sklerotraficon

Is there any particular reason you are making your life more difficult than it needs to be by doing it this way?

Even if you get it working I would be very cautious about how much CPU you will be consuming as it could slow down the Internet side depending on your load.

The reason is, to have devices, that do not necessarily need to be in the lan zone to be in a separate subnet.

As per CPU load, I do not think, that a little streaming of images / videos will pretty much bother the router's CPU (it's a Linksys WRT1900ACS).

Anyways, how do you guys handle Chromecasts or quasi or real IoT devices in your networks?

Thanks still for hints and suggestions...

This really makes no sense, you're going to be casting from LAN devices to them so they belong in the same zone. Discovery is probably done through UPnP multicast/unicast.

Exactly, these devices are specifically designed to be discoverable by LAN devices automagically so the only reason I could think of for putting them in their own subnet is if you specifically are trying to block that functionality (so random users on the LAN cannot cast to your devices).

I share my connection with a friend across the street and even I don't bother with that hassle.

I took a different approach...

Oh, suspense is killing me, can't wait for season 2.

Just in case you wanted to do it for the sake of doing it, igmpproxy or smcroute might be what you should be looking at.

One reason to do this is security. A botnet of chromecasts or whatever that can't reach your main lan seems like not a bad idea.

You might get similar security by creating a brouter using ebtables and keeping them on the same subnet but different port with your ebtables rules controlling your traffic

EDIT: to elaborate a bit

So, the first thing to do here is probably go ahead and put these devices on the same network, and then wireshark the interaction. Check what is needed to have devices establish a link etc.

Then, you physically move the devices to a different port on the router, and you bridge between the main LAN port and the AUX port. Set up ebtables on the bridge, and have explicit rules allowing just the "legit" traffic needed for the function of the devices. If your various devices do get infected/owned by someone else, they can really only pass "legit" traffic to your regular LAN through the ebtables.

Note, to make this work you may well want to enable bridge-nf-call-iptables and similar sysctls as detailed here: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt

then you can do iptables type filtering within the bridge.

I ran my network this way for a while, and it worked for the most part. Essentially, what I had was an IoT VLAN into which all chromecast, roku and similar devices were placed.

I'll say up front that while the end result allowed clients in LAN to cast to devices in IoT, certain things like chromecast audio groups wouldn't work reliably, and occasionally, the list of available chromecasts would come and go. Ultimately, I decided to go with what "just works", by tossing everything back into the LAN. I may return to this setup at some point because I'm stubborn, and it did teach me quite a bit about multicast and these clever devices.

Allowing clients on my main LAN to speak to the IoT VLAN required a handful of things:
avahi-daemon to allow SSDP between IoT and LAN
LEDE Firewall to allow communication between IoT and LAN and vice-versa
iptables to mangle TTL for multicast as it crossed IoT to LAN

My Firewall zones were set up as follows:
LAN -> WAN, IoT Accept for Input, Output and Forward
IoT -> WAN Accept for Input, Output and Forward

Traffic Rules were configured so that devices in IoT can fetch DNS and DHCP from the router itself:
IoT -> Router: DHCP
IoT -> Router: DNS
IoT -> ANY:5353
IoT -> LAN:1900
IoT -> LAN:5556-5558
IoT -> LAN/224.0.0.0/4

But wait, there's more! Because Chromecast blasts with a TTL of 1, it’ll die when it crosses a subnet. To get around this, I had a custom IPTABLES rule to keep that TTL up:

iptables -A PREROUTING -t mangle -p udp —dport 1900 -j TTL-inc 1

I also have a handful of other iptables rules that replicate those above:
iptables -A INPUT -t filter -i br-lan -p udp —sport 5353 -J ACCEPT

Finally, I configured avahi-daemon:

[server]
host-name=myrouter-gw
domain-name=myrouter.net
use-ipv4=yes
use-ipv6=no
check-response-ttl=no
use-iff-running=no
enable-dbus=yes
allow-interfaces=br-lan, br-IoT

[wide-area]
enable-wide-area=no

[publish]
publish-addresses=yes
publish-hinfo=yes
publish-workstation=no
publish-domain=yes
publish-dns-servers=192.168.0.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

Here are a bunch of posts by people smarter than me that helped me get to this point:

I can understand that you want to keep some devices on a separated network, that's fine. But then you have to manually open holes between those networks, because you do not really want them completely separated. It seems to me that this only makes things more complicated, and creates a false sense of security.

I may return to this setup at some point because I'm stubborn, and it did teach me quite a bit about multicast and these clever devices.

Sorry to resurrect this, but did you ever return to this to get it working? Would love to hear how you got it working if you did, in fact, manage it. I've got it 90% there: my Chromecasts are in 192.168.1.1/24. I'm trying to cast to them from 192.168.3.1/24. Occasionally, I can see them from 192.168.3.1/24, but they drop-off pretty quickly and I can rarely connect to them across the subnets.

I'll refrain from posting my set-up for now, just in case this topic is well-and-truly buried, but happy to share if there's anybody out there.

I did and have it working pretty well. The chromecast groups are still an issue across subnets, but things work for the most part. If your targets are appearing and then disappearing, you should check to see whether the avahi daemon is working. You'll also need to ensure the ttl value is modified as above.

thanks. I've ended up throwing everything in the lan firewall zone, and that seems to have done the trick. Will keep an eye on it over the next week, but I think it's working nicely.

If you're feeling stubborn, my firewall ruleset for the iot zone looks like this:

config zone
option name 'iot'
option input 'ACCEPT'
option output 'ACCEPT'
option network 'iot'
option forward 'ACCEPT'

config forwarding
option dest 'wan'
option src 'iot'

config forwarding
option dest 'iot'
option src 'lan'

config rule
option target 'ACCEPT'
option src 'iot'
option name 'iot-5353'
option dest '*'
option dest_port '5353'

config rule
option target 'ACCEPT'
option name 'iot-1900'
option src 'iot'
option dest 'lan'
option dest_port '1900'

config rule
option target 'ACCEPT'
option src 'iot'
option dest 'lan'
option name 'iot-5556-5558'
option dest_port '5556-5558'

config rule
option target 'ACCEPT'
option src 'iot'
option dest 'lan'
option name 'iot-multi'
option dest_ip '224.0.0.0/4'

Ah great, thanks! I'm definitely stubborn, so will give it a whirl. At first glance, looks like I was missing the final rule:

config rule
option target 'ACCEPT'
option src 'iot'
option dest 'lan'
option name 'iot-multi'
option dest_ip '224.0.0.0/4'

Thanks!