HA is on my primary home network 192.168.100.x
I set up a separate IOT network on 192.168.200.x
I can manually add TP-Link/Kasa devices in the TP-Link integration by specifying the 192.168.200.x IP address explicitly.
But is there any way to get discovery to work on 192.168.200.x from my HA server on 192.168.1.x?
Are there any ports and IP addresses I need to forward?
Note: Currently I allow all traffic: Primary network → IOT network
BUT block all NEW traffic: IOT network → Primary network
Hi puterboy,
Segmented networks are not officially supported within HA.
HA is designed and expects a flat subnet to work as intended.
This is because every segmented network is different for IP’s and number of segments and firewalls and sharing rules and about 650495849085 other things.
This does not mean you can’t use them or that they can’t be made to work, it means that to get them working you are the support structure on your own subnet(s) and if you are asking for support, you should disclose to the volunteer helping you that this is in use as it often changes the correct answers.
Please keep this in mind when you are trying to do this kind of thing.
@Sir_Goodenough I disagree, from my experience it works with no trouble at all. Two things are being mixed up here, if the network is set up the right way to allow HA to see devoices on the other vlans, then it works fine. HA doesn’t have to know anything about different vlans.
@puterboy hope the below helps - let me explain:
I have a separate IOT vlan, an internal vlan, and a quest vlan. All of my sensors are on the IOT vlan and they have no trouble communicating with HA which I have on the internal vlan - at all. It works smooth as glass.
You are part of the way there with the firewall rules which are fine and good secure practice. I =have mine set up such that everything is blocked from any vlan to any other vlan, and then I added routing rules to allow certain kinds of traffic just like you did. That is exactly the reason why you would have static IP addresses for every one of your devices.
What you are missing is mDNS. That is a network protocol used for devices to discover each other. Normally, mDNS messages cannot go across vlans even if you have the correct firewall rules set up, opening the path for HA to reach each device. All that is needed is to get mDNS traffic to travel from across vlans by setting up what is called an mDNS reflector, which essentially reflects mDNS message in one vlan to another vlan. The messages reflected are called bonjour services. I will explain below.
For example I originally had Chromecasts set up in my internal vlan, but it bothered me that people on my guest vlan could not cast to them. If I put the chromecasts on the guest vlan then devices on the internal vlan could not cast to them then either of course! This bothered me for a long time until I discovered that a bonjour service named
_googlecast._tcp.local
is an mDNS message that should be reflected across vlans. Forutnately my router has this capability but there are other ways of setting up mDNS as well. So, I just set up a Bonjour Service naming it “Chromecast” and gave it the value _googlecast._tcp.local. When I set the router to reflect this from the internal vlan to the guest vlan then it anyolne on either vlan can cast to the chromecast devices with no issue whatsoever!
Note, the internal vlan and guest vlan are accessed through completely different SSID’s, it still works with no issue.
Ok, so you need to read on upon how to get mDNS reflection set up in your network. And I did some digging, these are typical Bounjour srvices used by mDNS:
Bounjour Services
_afpovertcp._tcp.local - Apple Filing Protocol over TCP/IP
_airplay._tcp.local - Apple AirPlay receiver
_airport._tcp.local - Apple AirPort wireless networking
_apt._tcp.local - Advanced Packaging Tool repository
_daap._tcp.local - Digital Audio Access Protocol (iTunes sharing)
_dacp._tcp.local - Digital Audio Control Protocol (iTunes remote)
_distcc._tcp.local - Distributed Compiler
_dns-sd._udp.local - DNS Service Discovery
_dpap._tcp.local - Digital Photo Access Protocol (Photo sharing)
_ftp._tcp.local - File Transfer Protocol
_homekit._tcp.local - Apple HomeKit
_http._tcp.local - Hypertext Transfer Protocol
_https._tcp.local - HTTP Secure
_ica-networking._tcp.local - ICA Network Computing
_ipp._tcp.local - Internet Printing Protocol
_ipps._tcp.local - Internet Printing Protocol over HTTPS
_ldap._tcp.local - Lightweight Directory Access Protocol
_nfs._tcp.local - Network File System
_nfs._udp.local - Network File System over UDP
_ntp._udp.local - Network Time Protocol
_netbios-ns._udp.local - NetBIOS Name Service
_pdl-datastream._tcp.local - Printer Page Description Language Data Stream
_printer._tcp.local - Printer
_raop._tcp.local - Remote Audio Output Protocol (AirTunes)
_rdp._tcp.local - Remote Desktop Protocol
_rfb._tcp.local - Remote Framebuffer (VNC)
_rtsp._tcp.local - Real Time Streaming Protocol
_sftp-ssh._tcp.local - Secure File Transfer over SSH
_smb._tcp.local - Server Message Block (Windows file sharing)
_ssh._tcp.local - Secure Shell
_telnet._tcp.local - Telnet remote login service
_tftp._udp.local - Trivial File Transfer Protocol
_timbuktu._tcp.local - Timbuktu Service
_touch-able._tcp.local - Apple iPod Touch service (iTunes Wi-Fi Sync)
_udisks-ssh._tcp.local - Secure SHell Disk service
_webdav._tcp.local - Web-based Distributed Authoring and Versioning
_webdavs._tcp.local - Secure WebDAV
_workstation._tcp.local - Workstation (generic host name)
Belkin - specific
_wemo._tcp.local - Specifically for Wemo smart devices, this custom mDNS service type helps in easily identifying Wemo devices on the local network for seamless integration and control within smart home setups.
Leviton - specific
_leviton._tcp.local (if custom) - Some smart home device manufacturers create custom mDNS service types specifically for their devices. Leviton might use a custom service type like this for more specific device discovery and management, although the exact service name might vary.
_hap._tcp.local - For devices that are compatible with Apple’s HomeKit, this service would be advertised. It allows for the seamless integration and management of devices via Apple’s home automation framework.
Yolink - specific
_iot-device._tcp.local - A generic service type that could be used for IoT devices to announce their availability.
TP-Link - specific
_plug._tcp.local or similar - For smart plugs and other smart home devices to advertise their control interfaces.
Shelly - specific
_shelly._tcp.local - Some Shelly devices may advertise a custom service type specifically for Shelly devices, which makes it easier to discover and identify Shelly devices on the network.
Chromecast specific:
_googlecast._tcp.local - as described in the example above.
Kasa specific:
I have none set up and cannot find any bonjour service specifically related to Kasa, however I can see my Kasa devices that are on the IOT vlan - from the internal to IOT vlan with no issues, FYI Ihave these bonour services set up reflected from my internal vlan to the guest vlan (wehich is probably more than I need):
_afpovertcp._tcp.local, _ftp._tcp.local, _sftp-ssh._tcp.local,_ipp._tcp.local, _pdl-datastream._tcp.local, _printer._tcp.local, _http._tcp.local, _http_alt._tcp.local, _ipp-tls._tcp.local, _fax-ipp._tcp.local, _riousbprint._tcp.local, _ica-networking._tcp.local, _ica-networking2._tcp.local, _ptp._tcp.local, _canon-bjnp1._tcp.local, _ipps._tcp.local,_smb._tcp.local, _smbdirect._tcp.local, _ipp._tcp.local, _pdl-datastream._tcp.local, _scanner._tcp.local, _http._tcp.local, _http_alt._tcp.local, _ipp-tls._tcp.local, _fax-ipp._tcp.local, _riousbprint._tcp.local, _ica-networking._tcp.local, _ica-networking2._tcp.local, _ptp._tcp.local, _canon-bjnp1._tcp.local, _ipps._tcp.local, _ssh._tcp.local,_googlecast._tcp.local, _nest-device._tcp.local, _wemo._tcp.local, _leviton._tcp.local, _hap._tcp.local, _iot-device._tcp.local, _shelly._tcp.local, _matter._tcp.local
Note, my HA is on this* subnet and I have over 60 devices on this** different subnet and it works seamlessly.
Oh, one more thing - if you have any matter devices, then also use the bonjour service called:
_matter._tcp.local
The above is actually for both TCP and UDP for Matter, and Matter tries to use IPv6 but if you have that turned off no issue it then defaults back to IPv4.
The only issue I have had in the past across vlans (other than chromecast which I recently figured out as described above) and is still an issue were my matter devices only (I only have two of them right now), which had to be on the same vlan as HA or else they could not work - but that is before I discovered _matter._tcp.local. I’m going to give it a shot with _matter._tcp.local added to my mDNS reflector as that should allow matter device discovery across vlans, and then I can move those devices onto the IOT vlan and try it. I’ll try to remember to report back.
(I have over 60 devices on a separate vlan than HA and it works with no issue. It’s your network that has to be configured to have mDNS reflection across vlans, nothing to do with HA.)
Hope that helps -
KruseLuds is onto the right path.
Firewall openings are not enough, because some protocols, and especially discovery protocols, are not meant to be routed.
Routing mDNS is a start, but there are other routing protocols too, but general ones and product specific ones.
You need to research each device model to see what protocol it uses and then hope your network gear is able to be setup for that routing.
@KruseLuds Did you read my post?
I have a split LAN. I never said you can’t do it or that you can’t make it work well in many cases.
I am explaining that it is officially unsupported so if they do this, in the future they need to completely understand it and support it themselves, and let the person helping them here if they ask for help know it is a split LAN.
These are facts, and there is no opinions expressed to disagree with.
I apologize @Sir_Goodenough, I misinterpreted your statement then… as I have no formal networking training other than a huge amount of reading, along with experimentation and painful trial and error)… I have therefore, 2 questions…
What kind of change would be made in the future by HA to disallow this network configuration (I thought that HA is purposely network configuration agnostic)?
@WallyR & @Sir_Goodenough, what other services do not cross vlans other than mDNS protocol Bonjour Services (e.g., I guess ABC protocol XYZ Services - I guess require an “ABC reflector” then, or - ?)?
I have not looked into the different protocols and I do not have knowledge about overlap either.
This is also not a complete list, just some of the ones I remember at the moment.
SSDP, LLDP and ZeroConf are general protocols.
CDP is a Cisco propietary protocol.
Thanks so MUCH for the really helpful explanation.
I am using dd-wrt as the firmware on my router & APs.
I enabled mdns Resolver and mdns Reflector and included br0 and br1 in the interfaces for the Reflector where: br0 is my default network where HA runs and br1 is my IoT VLAN.
I also needed to open my firewall to allow 5353
iptables -I INPUT --p udp --dport 5353 -j ACCEPT
I was able to discover my chromecast devices on br1 by creating the services file /tmp/avahi/services/_googlecast._tcp.service and running avahi-browse -r _googlecast._tcp.
But I was not able to get it to work for my tp-link devices.
I tried creating a services file _plug._tcp.service of form:
<?xml version="1.0" standalone='no'?>
<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
<name replace-wildcards="yes">%h</name>
<service>
<type>_plug._tcp</type>
<port>9999</port>
</service>
</service-group>
and running: avahi-browse -r _plug._tcp but it hung without returning any results.
I also tried with port=5222 (control port) and port=1900 (UPnP)
Any suggestions on what I might be doing wrong?
NOTE in googling, I found that kasa devices typically use UPnP rather than mDNS. If this is true, is there any way to get UPnP to work across VLANs?
Interesting. I never had an issue with any of my (2!) Kasa devices across lans, they still are seen in HA which is a different subnet. I do have upnp turned on but no other special setting for that as far as I can tell. Regarding your firewalls, the IP addresses for the Kasa devices are allowed through?
Yes - I can ping the Kasa plugs and I can “manually” add them in the TP-Link HA integration by entering their fixed static addresses, just can’t auto-discover them in the HA integration or avahi-browse them from the command line.
But I can avahi-browse my chromecast devices on the same network (using a version of _googlecast._tcp.service that I found on the Internet), so the mDNS reflector itself is presumably working.
nmap -sT shows that port 9999 (tcp) on the plugs is open and reachable from my default network (br0).
_plug._tcp.service (pasted above) is wrong?Also, just want to confirm that “auto-discovery” in the TP-Link HA integration is working for you.
Just an update…
I have mDNS working properly.
However TP-Link/Kasa discovery uses broadcast to 255.255.255.255 on ports 9999 and 20002 – but broadcasts don’t naturally go across subnets.
(Also its broadcast and not multicast so that ‘smcroute’ won’t work.
I have been trying all different rules for INPUT, FORWARD, and nat chains to try to get the broadcast to forward across subnets but to no avail 