You are using Hubitat's Cloud to connect the two hubs. That rather clearly says the two hubs are not able to communicate directly.
I'd say, yes, true 
It is round tripping through Hubitat? I figured it was just a different protocol.
What protocol is the LAN setting using?
It’s still HTTP unless you select Websocket.
Just on port 80? That makes no sense. Nothing should be blocking that.
I'm working on setting up a syslog server to dig deeper.
Hi,
What is you subnet address?
Try 255.255.0.0, NOT 255.255.255.0.
Just a thought, but since you can connect to them, you probably have this set correct?
RogerThat
Why a class B network?
He posted the above IPs so he needs to use 255.255.0.0 to have the access between the X.X.50.X and X.X.107.X networks if he does not configure a spesific route in the router. That's all.
RogerThat
The routes are working fine. The browser on 50 connects to the hubs on 107. It is the communication between the two hubs on 50 that is the issue.
I may have found the problem but there is a bug in the UDM software that prevents me from changing some settings. This thing should still be in beta IMO.
1 Like
Yup, that was the problem. The IoT network had port isolation enabled.
Everything on 107 could talk to everything on 50 but the two specific ports that the hubs are plugged in could not talk to each other.
To make matters worse I could not edit the port profile. I ended up making a second profile without the isolation enabled and it is now working. I don't know how that got enabled in the first place.
I like Ubiquiti gear but sometimes the company can be maddening. The Dream Machine Pro should still be in beta. It is not ready to be a shipping product.
Don't tell me that! I have a UDM Pro coming next week for the home office. My CG2+ and USG-Pro are headed for the RV once thats up and running.
Dang - that's a big RV! 45 footer?
Thank you for all of your help on this issue. I never knew the UDMP could isolate ports like that. I was just stepping through every config screen looking for a possible solution.
I'm not up to speed on networking as well as I should be. I do more paperwork these days. 
I actually went to a week long training course at Ubituiti but that was over a decade ago and I never used the knowledge as the project was canceled.
In any case I do like the UDMP but it does have some rough edges. Right now I can only run the UI on Chrome on a Win 10 laptop. IE doesn't work. I also can't get it to load in a browser on an iPad Pro. So if you have trouble connecting to 192.168.1.1 try a different browser.
I used the iOS app to do the setup over Bluetooth but it failed after the speed test finished. It gave me a 400 error then a 500 error every time I tried to redo the install. I plugged a laptop directly into a port and couldn't connect (that's when I found IE doesn't work). I generally have multiple browser open due to my day job. IE just happened to be the one on top when I tried. Once I changed to Chrome I was able to connect but got the same 500 error, only this time it said it was resetting the device. The next time through the setup it worked.
The last gotcha I ran into was buying an SFP+ cable. I have a US-16-POE-150W with a 1Gbps SFP port. The 10Gbps SFP+ port on the UDMP does not currently support 1Gbps. You can manually select 1Gbps but it still doesn't work. I expect it will with some future firmware upgrade. Right now I'm just using the regular Ethernet ports for my uplink. If you have an older switch don't even try the SFP for now.
Overall I do like the UDMP but it isn't 100% yet. I just posted the above so you can avoid some of the pitfalls I ran into. I just received a new UAP-nanoHD and it adopted just fine. Now I'm working to provision a UAP-AC-Lite as a wireless uplink so I can have Ethernet in my shop.
It is mostly working. 
I just got the UAP-AC-LITE configured as a mesh device and tested it out by plugging my computer's Ethernet into it. The computer has internet access and all is well. The odd thing is that it shows up as connected to the switch rather than the AP. It does show it is connected to port #15 which is where the NanoHD is plugged in and the Lite is connected to the Nano with a wireless uplink so ultimately the PC is connected to #15 but it is directly connected to the LITE.
It is starting to come together. Now I just need for some more cables to be delivered today and I can start rebuilding my central location. First step will be moving the rest of my IoT devices (AppleTV, Onkyo, Ecobee, Echos, etc.) to the IDIoT network.
The Hubitat hubs are on dedicated ports on the UDMP with static IPs. Once I get the bugs ironed out I'll be segregating the IoT network from my regular net. I don't expect I'll need anything going through the firewall except for an established and related rule.
Feel free to shoot me a message if you have any questions on the UDMP but I suspect you already know more than I do there.
1 Like
Had the feeling that since you could browse from one net to the other, it got blocked the other way. Great that you had it working, as soon as you opened up traffic both ways between the two subnets, with the new firewall rule.
What you could consider, is to open only the ports the HUBs need, so that you do not expose too much to the IoT devices. I guess that was the intention in the first place, right?
Well done, by the way! 
RogerThat
No, it had nothing to do with the firewall or the subnet. Those were fine and browser on one subnet could talk to the hubs on the other subnet just fine. The two physical ports that the hubs were plugged into could not talk to each other.
That’s the plan but it goes one step further. Nothing on the IoT network will be able to initiate a connection to the main VLAN. Something on the main VLAN will have to initiate the connection. Only then will an IoT device be able to communicate. I would only need an open port if I had something like a DNS or NTP server on the main net. At the moment I on have anything lie that.
1 Like
