My IoT devices which i have added to HA are on different subnet and two separated firewall zones.
HA has total access to IoT network but IoT network cannot reach HA network in terms of firewall rules/configuration. Now, what ports and protocols should i allow in my firewall from IoT to HA to not to interrupt any data polling from devices or WebHooks or RPCs or CoIOT or anything else which i may not even know about?
I have been reading documentation but i cannot find definitive guide what need to be allowed to passtrought of data which will not interupt anything. Is there a definitive list of ports which HA uses?
HA generally polls device so device in many case need no access to HA. Just ability to respond.
Camera(polling is not the term here. Retrieve?)
Switch
Sensor
Pollled devices
Voice assistants get audio from your local lan address in HA settings so they need access to that
Addons like music assistant may connect with HA but I would presume it’s not in IOT
Just heads up about client server paradigm. HA is a server. devices are clients.
Usually it’s a client that initiates a connection to the server. The fact HA does it differently doesn’t mean it’s the only supported way.
For instance, devices communicating with mqtt require opposite fw rules.
Strange you are asking for ports considering HA as comm initializing device. outbound port can be anything, isn’t it?
I originally put my HA Voice PEs in my IoT network (which existed long before I started with HA). They couldn’t reach the HA network, which I expected. I added a firewall rule to route those devices (by IP) to the HA network…no need for allowing ports, protocols, etc.
Just sharing how I did it. YMMV depending on your network setup & experience, router fimware, etc…
I’ve since moved the Voice PEs into the HA network. Easier, less hassle IMHO.
No, because your issues are not ports, but protocols.
You need to learn about all the different protocols and how to move them between the networks.
Many of them can not be routed with standard TCP/IP routing, which, among others, goes for the many different needed discovery protocols, both open and proprietary ones.
That means you need to know what each of your devices use of protocols.
And when you have learnt that, then you probably need to do it all over with IPv6, because your learning was probably limited to IPv4.
IPv6 is not however IPv4 with just more addresses. It is way different and it is required for Matter and will be more and more prevailing in the future.
Devices that connect through a cloud service / hub and the HA integration also logs in to that cloud service (e.g., YoLink, Ring),
These devices MUST be on the same LAN as HA:
Devices with only local connectivity (no cloud service): DNLA media serves, HP Printers, Routers, etc
Devices that use the HomeKit Device Integration (requires Bonjour protocol on same network)
Example: Ecobee thermostats used to work via cloud API on a separate VLAN, but since Ecobee removed API access, they now need to be on the same VLAN as your HA server. Benefit: works during internet outages.
No there is not. Because every person’s install is different.
Use esphome? Need esphome stuff.
Ha by itself is web services, but what port you present that on is up to you. Could be 80,443, 8123,some random ephemeral over 9000?
People always forget ports are just numbers. I can put any protocol on any port if I really want to. You need to KNOW what you’re deploying what features they require and open those. And possibly help the protocol along like Wally said (mdns, etc) so there no list because they have no idea what you’re installing.
To segment successfully with HA YOU REALLLLLLY need to understand your network protocols and how they work. I run a well secured and maintained flat network. Imho for me… The amount of work to segment mine would be a nightmare to setup and maintain, I’d miss stuff and it’d be worse than had I not segmented it from a security perspective in the first place.
@4k3or3et, just focusing on this from my side: Whether you can get mDNS to work across VLANs will depend on your network hardware and additional software to support it. It’s not just a matter of opening a port. mDNS was really designed for flat networks, even if you can get it to work otherwise.
aware. I figure it is better to show than tell.
I thought after taking a trip down the hole trying to setup mdns and seeing the issues it would be easier to explain why all this is a bad idea and not as easy as ALLOW PORT IN rule
