HA and your other IP Devices communicate via HTTP(s) , PING Don’t
Your RING DoorBell, is most likely a Cloud-depended Device ( Device>Cloud>HA - HA>Cloud>Device )
1 Like
Yes you are right the Ring is cloud based and needed me to log in hence was more straight forward.
Why can’t your IOT stuff use the same network?
2 Reason, My more important stuffs on one IP address and IOT stuffs on another. There are quite alot of items herein easier management.
I am not sure if its firewall rules or bridging issues as i have configured all of them sufficiently i guess, whilst i am connected on my phone/ipad on the main network i can also access other devices from other network controlled by their apps which have been setup using a different network. If i configure in my firewall to drop them ie. cannot talk to each other then the access is denied so yes i think i have my firewall part taken care.
Please avoid cross posts if possible. It makes it easier for folks to understand the whole conversation and the solution if the issue if it’s resolved…
“controlled by their apps” , if you mean the device/brand-apps on your phone, then yes indeed, they either work/talk “locally” or through the cloud, and depending upon whether your phone is connected to a wifi/ip-network or connected to phone-net(3G-5G)
So the reason you “Apps” work is again most likely due to the fact
PHONE-APP>CLOUD>DEVICE-DEVICE>CLOUD>PHONE-APP
Sound familiar as your DoorBell ?
" to drop them " what does that actually means ? , i’ve never seen a feature described like this in I.E a Router/FireWall
If it’s what i think it is(you mean) , then yeah Right !, obviously
btw, you still haven’t specified which Router you run,nor showed any “settings” but only described "
Main IP ? , other IP’s ?
How does the iot-VLAN Communicate With the other(Main-Lan / VLANs) and visaversa ?
If I understand correctly from your other post, your HA Green only has one interface and its on network 192.168.1.0/24 (you call it “main”), but your router has 2 interfaces with one interface on 192.168.1.0/24 (main) and the other interface on 10.0.10.0/24. From this post it looks like the router has a third interface on 10.1.1.1/24.
In this setup, the general problem is that “Discovery” uses link-local multicast which by definition is not routable, so the router is not forwarding multicasts originating from IOT devices on 10.0.10.0/24 to 192.168.1.0/24 (and vice-versa). Having said that, some routers have “Multicast-Forwarders” which actually will forward these multicasts. Routers that have this capability call it by different names, such as proxy forwarder, Avahi, etc. If your router has this kind of capability, then it will help a lot, but it is not necessarily a guarantee that it will work. Some have success with this, others don’t, so in general it is not a “best practice”.
1 Like
Not how. Why?
See how complicated this all gets. This is why VLANs are officially
Not that they can’t be made to work, it’s that you have to have intimate knowledge of your VLAN to make it work.
I suggest not glossing over
It is by far the most likely point of failure. Something cannot talk to something. Maybe ipv6, maybe some protocol is blocked, who knows.
Not to mention involvements of Routes/Proxy/DNS/Allow-List(HA), it’s a long “check-list”
I am using a mikrotik router, and to “drop” them in my firewall meant any access from one network to another is denied. So if i put it to work they cannot talk to each other, and by default all Vlans and Lan can talk to one another. Its not by cloud, even when i disable my phone ie. airplane mode and only on my wifi to my network it will connect and all other Vlans gets accessed.
Mikrotik bridging is simple. When you lump all the desired ports, aggregation ports, Lan, Vlan under a bridge, it meant they are one cluster one network, very simple and they will route to each other.
why? i just like to keep them separate
Interesting, i guess that you are used to reading Manuals, and are familiar with that Brands various HW-Routers and it’s capabilities , And howto configure their SW
Apparently their “Default Behavior” doesn’t seems to work, cording to your claims
Have you updated the Router-OS to latest stable-version ?
( As im sure you have Configured HA to “accept” your VLAN 
erm HA to accept Vlans, theres no option there for me to do this. All my other switches are enabled with mDNS for IOT devices auto discoveries. My Mik router has been enabled with PIM for all interfaces. In fact even before enabling PIM all multicast traffic can be seen across all interfaces in the router.
The latest discovery detected my iphone whilst being connected on my IOT network
Sorry for being “unclear” , i was referring to “Allow”
Which Integration ?, Mobile-App ?
BTW. You haven’t either informed us whether you have SSL/Remote-Access enabled in HA, On the other hand it sounds like you know what you are doing, so i guess you you thinks this is irrelevant for us to know.
configure HA to accept Vlan, how do you do this? Theres nothing in the HA Green thats showing this despite activating advance mode. And no i have not done any SSL/Remote access enabled in HA, do you need to activate? i will only want access locally. Any need to access it externally will be done through my VPN in my router. Already tested, mobile mode no wifi vpn activated can access HA Green server, VPN off access not possible.
Integration as in iphone to HA all stats and info now seen in HA. Its auto
Forget about “Vlans”, HA don’t know that “Word” and it doesn’t care about the “Word”, it’s a Network Device( Server )
Sorry never heard of that Integration
And with this, Also Configured Somehow, my last words are final.
I have No idea how to guide you “through”
PIM is used for forwarding “routable” multicast between routers. To be clear, the types of multicasts being used for Discovery (for example mDNS/DNS-SD) use an IP address in the range of 224.0.0.0 and 224.0.0.255 and these are called link-local multicast and they are not to be forwarded from one subnet to another (i.e. they are confined to the local link (LAN/VLAN)).
Nevertheless, as I mentioned earlier, there are some schemes implemented in routers that do forward mDNS link-local multicasts. I’ve been glancing through some Mikrotik Forums, and there are no out-of-the-box solutions for forwarding link local multicasts. However there are a couple of “hacks” some people have been attempting to implement in order to overcome this, so you may want to google around for things like “mikrotek mDNS-repeater”, “mDNS-reflector”, and here is a link on a container that looks sorta interesting. But again, these types of solutions do not always solve the problem.
2 Likes