It has been annoying a lot of people for a long long time: Ubiquiti's unwillingness to fully support multi-VLAN networks on all of its products. And their constant push towards "the cloud", a nice marketing term for "another persons computer". Ubiquiti has a great set of products. But if you like to stay away from the cloud and don't want to create a ui.com account, some functions are hard to get to work or just don't work at all.
This is especially annoying with the CloudKey Plus, a device that runs the management software for your network AND a NVR (Network Video Recorder) named "UniFi Protect" at the same time. You should always isolate network management from normal users, but in the case of the CloudKey Plus that also limits access to Protect.
Some of the complaints of Ubiquiti users
As alawley posts on the community forums:
"With the UDM-Pro, can I assign the applications their own IP address? For example, can the UDM-Pro/network app be on a different subnet than the Unifi Protect app? I prefer to keep my network devices on a different subnets than my cameras."
In the thread [Feature Request] Direct access to Unifi Protect from different subnet, AlexRoig says:
"The new feature of Offline Access from the mobile apps is great, but in our case we have some separate networks for wireless, protect, computers and several remote sites. It doesn't make us sense that the direct connection works only on the direct subnet having routing enabled between the subnets.
[..]
From the security point of view, it could expose a 'risk' having a phone beaconing the IPs of the protect devices, but I think that can be acceptable or have switch to enable/disable the feature on the NVR Unifi OS."
When someone else mentions the topic is so silent, _Space responds:
"I dont think the lack of reply is due to people having flat networks, I think it is many people just giving up.
As they say at work, no horse is too dead to beat... but this topic has been beaten to death... People BEG for the ability to use protect from a mobile device, no cloud and point to an IP. maybe port forwarding, maybe vpn, maybe just on the local LAN... lots of scenarios.
UI is aware of what people are begging for.
BUT, UI has a plan. they wont tell anyone what it is and the are determined to keep their cloud in the mix."
Let's see what we can accomplish.
My network setup
For this article, my network will be set up as follows:
- EdgeRouter 12
- Multiple UniFi switches
- CloudKey Plus (UCKP)
- G4 Bullet camera
- VLAN4 = 192.168.4.0/24 = management VLAN that contains the camera but also the CloudKey Plus (UCKP). This VLAN is on switch0.4 of my EdgeRouter.
- VLAN5 = 192.168.5.0/24 = LAN, where my laptop and phone are connected. This VLAN is on switch0.5.
Failed attempts to get the Unifi Protect app to connect to the console
The Ubiquiti Protect app scans the local network by sending out a broadcast to 255.255.255.255 on udp port 10001. If there only was a way to relay that message to another VLAN, the app might be able to detect the Protect appliance.
First I looked to see it my EdgeRouter 12 supports forwarding of broadcast packets, but I haven't found a built-in way to do that. In Odi's astoundingly incomplete notes I found an interesting alternative, using iptables' TEE target. The command to run would be:
iptables -t mangle -A INPUT -i switch0.5 -d 255.255.255.255 -j TEE --gateway 192.168.4.255Unfortunately, my EdgeRouter does have the libxt_TEE.so required for this, but lacks the corresponding kernel modules to make this target work.
I then found a post that claims to have a way to use iptables' PREROUTING redirect a packet for 255.255.255.255 to a specific address on another VLAN. According to that page, I should be able to route Ubiquiti's discovery packets to my CloudKey using the following command:
iptables -t nat -A PREROUTING -i switch0.5 -m udp -p udp -d 255.255.255.255 --dport 10001 -j DNAT --to 192.168.4.253
iptables -I FORWARD -m udp -p udp --dport 10001 -j ACCEPTI don't see anything wrong with this, but still it does not work. I'm not sure, but I think the global broadcast address 255.255.255.255 may be explicitly excluded from forwarding by the Linux network stack.
Another suggestion I found, was to install ubnt-bcast-relay which is based on udp-broadcast-relay. By installing this software on your edgerouter, you can easily relay packets from one network to another. This may be a useful method for some people, but personally I don't feel like running third-party software on my router. Also, I'm not sure this will work as the EdgeRouter itself is listening on udp port 10001.
How I connected my app to the Unifi Protect server
I could not find a satisfying software-based solution for this issue. The best option would be for Ubiquiti to just add a text field in which you can type an IP, but they won't. Setting up a temporary Network Bridge between VLAN4 and VLAN5 could help the app to connect to the Protect NVR, and then remove the bridge again. This is a bit risky, because adding the interface you're connected to to a bridge will make you lose your connection.
Instead, I chose to set up a "hardware bridge": a simple network cable. On one of my switches, I picked two unused ports, set one to VLAN4, the other to VLAN5. Disabling Spanning Tree Protocol for the ports is a requirement, or the ports will quickly go into blocking mode. Then I connected a UTP cable between them, letting all traffic flow between VLAN4 and VLAN5. I set up the protect app and 30 seconds later I removed the cable and reversed the settings.
Yay! We got a working app! Or do we....?
We got the app set up, but I doubt we actually got a long lasting solution. At least not if you're trying to get your Unifi Protect to work over a VPN. Even now we can connect cross-VLAN or over a VPN, the app is flaky at best.
The very first time I tried to access my camera's via VPN over a 4G connection, the Protect App began to stutter. And complain about how "Some VPN networks may cause connectivity issues".
Yes, some VPN networks may do that. But I manage my own, and it's set up well. Why does Ubiquiti actively try to scare people away from VPNs?
Right after the message above, the connection is magically lost. And then the UCKP is grayed out and becomes unusable.
Unfortunately for Ubiquiti a few tools let us see right through their bullshit. Using any browser on the phone, we can still connect to the CloudKey just fine. Also, tcpdump shows traffic is just fine. The app sometimes works for a short while, then without any good reason loses connection to the UCKP. And there seems no acceptable method to get it back to work.
Once the UCKP is grayed out, the only way to get it back, is to log off the whole app and re-discover the CloudKey. Not even reconnecting to the original wifi gets it back online if VLAN4 and VLAN5 are not directly linked to each other.
It seems that the app constantly wants to keep re-discovering the UCKP, and if it can't, it will stop functioning.
My suggestion is to stay away from Ubiquiti camera's.
After hours of trying, I'm done with it. I have deleted the UniFi Protect app from my phone. And I'm returning the €190 camera to the webshop. For my office, I'll probably end up with another brand that does respects its customers' wishes.
Alternative solutions for discovery
The following solution could also be interesting:
https://github.com/bahamas10/unifi-proxy - A NodeJS program that relays broadcast messages
I did not test this, but I figured it could be useful.
A dirty solution for discovery
A dirty solution that could help out, is to use socat to tunnel the connection. Then you'd have to change the source ip as well. I just came up with this solution, but have not tested it yet:
On a Linux computer with IP 192.168.4.1 run:
socat -u tcp-listen:50000 udp-sendto:255.255.255.255:10001,broadcast
iptables -t nat -I POSTROUTING -d 255.255.255.255 -j SNAT --to-source 192.168.5.1Then on a Linux computer with IP 192.168.5.1 run:
socat -u udp-recvfrom:10001,fork tcp:192.168.4.1:50000
(3 votes, average: 5.00 out of 5)
Loading...