I have decided to place this topic here as it is Not related to HE specifically but is related to IoT overall.
As you might have seen on my other post I got my first HE yesterday. During the initial setup and when I went all excited to test the new Chromecast feature I realised it would not work in my currently infrastructure. What is worse was that if it did not work on my current infrastructure it would not work on the improved version I had planned.
As you all know IoT devices are not particularly secure, one of the reasons why I wanted to move away from ST into a local setup. Hence I would like to put in place a restrictive access on my network.
Currently my infrastructure is split in two
WiFi mesh Networks working on 2.4 and 5 GHz.
Wired Devices (ST HuB/Hubitat/Philips Hue) that connect to the ISP Router.
This Setup was put in place like this due to Mesh Router only having 1Eth port available per unit.
Note: with this setup Chromecast does not work anymore
The goal was to activate and create a Vlan on the wired router and restrict traffic in and out. Out just to the HUE and Hubitat servers. And do not allow traffic between this Vlan and the other networks. Exception would be to the Chromecast devices.
It will not be possible to move the cast devices into the ISP Router as due to how my ISP works if I enable WiFi on this router I will loose almost 40% bandwidth.
I come across this article on my last 12h of searching for a solution:
So it is clear to me that I cannot use the Cast feature in HE. Bummer.
My question to you guys is: are there any other community apps that also might not work with this infrastructure?
Anyone has a possible workaround?
I already reached to @mike.maxwell but I don't want to take his time from something when the cast feature it is working as intended and it is due mostly to my setup.
The Service Discovery Gateway feature enables multicast Domain Name System (mDNS) to operate across Layer 3 boundaries (different subnets). An mDNS gateway provides transport for service discovery across Layer 3 boundaries by filtering, caching, and redistributing services from one Layer 3 domain (subnet) to another. Prior to implementation of this feature, mDNS was limited in scope to within a subnet because of the use of link-local scoped multicast addresses. This feature enhances Bring Your Own Device (BYOD).
Not sure if this work as Chromecast discoveries have a TTL of 1. This means every time it reaches a hop it reduces 1. When it gets to 0. It will timeout.
But will read about it. Also need to consider the cost of the kit.
I've not tried it personally, but vyatta/VyOS firewalls at least have an mDNS repeater that ought to do the trick. That includes it's various forks, so things like the Ubiquiti line of EdgeRouters can do it, too.
Fundamentally, though... if your difficulty is that you don't want to turn on wifi on your border because the border router can't really handle it, then I'd also tackle that in general.
Personally, due to a quirk of how Rural Broadband totally fails to work in the UK, despite the fact that I'm less than a mile from the edge of the county's largest town, Fixed wireless 4G is all that's available to me. The routers they use have documented (enormous) security holes, and regardless of the ISP you use to terminate it, none of them ship firmware updates. So... I do what I've always thought was sensible to do - stick your own perimiter behind it, and run decent equipment that wasn't necessarily built to the lowest possible profit margin. In my case, they're also sufficiently unreliable enough that I then load-balance between a pair of the connections, and have a <1mbit DSL backup backhaul in case the whole lot fails. Stick a decent firewall behind that, and behind THAT run a decent set of Wireless Access Points. You can do 'em as a mesh if you want, but in my experience, nothing beats a whole ton of cat 6 around the place ;). Given the thickness of the walls here, that's in practice meant 8 access points in and around the house to cover everywhere we need.
Gah. Karma's quick nowadays. Just collided with the downside of so many AP's - log into the management interface to discover 8 firmware updates waiting to be done, plus 5 more for the switches.
Ah well. Time to play 'what can you offline without disturbing the other half?'
If I owned the place I would have for sure Ethernet everywhere. Being a rental that's not a possibility.
My ISP forces me to use the worst than crap router with their own customized firmware. Contractually.
Worst it needs to be the first point after the Fiber module.
If I could ditch it all together I would. It's a piece of Junk.
My Orbi firewall is quite decent and allows me due mDNS through the Vlans configured on it.
I have asked a friend for a switch that why I can place the hub after the Orbi and test this.
I use an Ubuntu VM running AVAHI to access chromecast devices from another VLAN/subnet. The VM has one nic on each network I want it to bridge mDNS access on. Works great for phones, etc.
For HE, it happens that mine is on the same subnet as my chromecasts, so I can't guarantee it works with HE - but it should.
It is a little harder, though, versus a VM as you definitely have to VLAN things since the Pi only has one physical NIC. So you need to make sure your switches, et al, support VLAN - and know how to configure/implement VLANs.
I get the desire for separate subnets, but why not just merge them for now, enjoy what you want and implement outbound restrictions to stop certain devices from accessing the internet.
There are also free options for multicast spanning, via firewalls like pfsense.
I agree, and often argue with my security peers that this is actually the right answer for the vast majority of home users.
However, there are definite security benefits to isolating IoT devices. So if the owner has the capability, interest, or passion to do it - that's great, and it is better from a security standpoint.
Is it 'necessary'? Probably not? Maybe not? Who knows?
Sure, if you are passionate about it and want to do it. It is possible and for some, even fun. But if you are sacrificing functionality for security... it's a decision that the industry hasn't solved. Consumer products are designed to be on the same network with basically no restrictions. Managing that is difficult at best.
I had that discussion earlier this week - but regarding uPNP. uPNP is the devil from a security standpoint... But if you are a household with multiple gaming systems, you have to use it to get full functionality - that's just a fact/reality of how things work today.
So all of the guidance to just 'shut off uPNP' is great for security, but for gaming households simply is not a viable option in many cases.
So what do you do? I venture to say in most households the answer will be - keep it simple, and leave uPNP on so my stuff WORKS.
Long term hopefully 'something better' replaces uPNP - whether it is better written software, or another protocol/offering to keep the same functionality. But until then... Security or functionality is the choice many have to make.
"The industry" has made that decision on behalf of the customers. Customers were never given a choice. It is more costly to develop secure solutions. They don't care about your home security, that's not their job. That's your job as consumer. There is routers and solutions for that.
The issue arise when a solution cannot be implented behind such security.
Sorry Somel. I kind of hijacked your thread with a security discussion. I think he was responding to my off-topic comment on uPNP. That has nothing to do with your original chromecast question/comment.
