bahamas10/unifi-proxy

a hack to allow direct connections to unifi protect on a different layer 3 network

unifi-proxy

Very rudimentary tools to interface with Unifi devices over the UDP discovery protocol (port 10001).

This was originally written to allow the mobile Unifi Protect app to connect to a local device over a L3 network. These tools work by mimicking the UDP discovery packet sent by the cloudkey (or similar device) on the same L2 network as the mobile device trying to connect.

The beauty of the discovery protocol is that the mobile device (the client sending out discovery packets) doesn't use the IP address of the host that responds, but instead, uses the IP address that is embedded in the UDP payload. Because of this, no proxy or anything is needed - the mobile app is able to form a "direct" connection to a device on a different L3 network.

How To

To get started, client.js should be run on the same network as the unifi device you would like to copy. For me, this means running this tool on the same network as my cloudkey.

client.js will send out a discovery broadcast packet on the L2 network and print data for each node seen.

$ ./client.js
listening on 0.0.0.0:62083
discovery packet sent

message received from 10.0.2.10:10001
{"type":"Buffer","data":[1,0,0,...]}

message received from 10.0.2.50:10001
... etc ...

Find the device you'd like to be able to mimic. Copy the JSON line that represents the packet received by the device into a file like packet.json. Then, run server.js with the packet file as an argument. This server should be run on the same L2 network where the mobile device searching for local devices is running:

$ ./server.js packet.json
listening on 0.0.0.0:10001

Finally, open the mobile device and you should see your device when scanning for local devices. The server will print lines for each discovery packet it sees:

$ ./server.js packet.json
listening on 0.0.0.0:10001
got message from 10.0.1.211:55185
successfully sent 132 bytes

---

I hope that unifi just supports connecting directly to a device on a different L3 network without this hack needed.

License

MIT License

unifi-proxy's Issues

Android mobile app

This bridge work fine with iOS app, but android requires that packet src ip should be equal to unifi ip.

Workaround for me is to use nemesis ( https://github.com/libnet/nemesis )

//Save raw packet at start
fs.writeFileSync('unifi-server.packet', message);

socket.on('message', function (msg, rinfo) {
// ...
exec("nemesis udp -c 1 -x 10001 -y " + rinfo.port + " -P unifi-server.packet -S <controller ip> -D " + rinfo.address + " "+(rinfo.address.indexOf('172.19.101')==-1 ? '-d ens192' : '')); //-d used in case of multiple network interfaces

This code work fine with both apps via wifi.
It is also possible to connect remotely via vpn (WireGuard for me), but only from android and you should be connected via wifi (e.g. from another smartphone).

Doesn't seem to work

Latest version of the iOS app, Protect 1.18.0.

Have a VM straddling 3 networks, 2 of them relevant:

• VLAN111 which is where Protect is
• VLAN108 which is my WLAN

Created packet.json from my Protect server appropriately.

root@hostname:~/unifi-proxy# ./server.js packet.json
listening on 0.0.0.0:10001
got message from 192.168.108.x:54435 <--iPhone
successfully sent 112 bytes
got message from 192.168.108.x:54435 <--iPhone
successfully sent 112 bytes
got message from 192.168.111.239:10001 <--Protect
successfully sent 112 bytes

But iOS app still shows remotely connected. Thoughts? Happy to debug further.

iOS app says "Device not found"

Hi,

I love this idea, I think it's brilliant, but unfortunately it doesn't seem to work with my app :(

Repro steps:

1. Run client.js directly on the UniFi CloudKey via SSH, created my packet.json successfully.
2. Copy packet.json and server.js on a virtual machine on the same network the iPhone runs on.

It looks like this:

3. Run:

$ ./server.js packet.js

listening on 0.0.0.0:10001
got message from 192.168.1.43:55075    <-- my iPhone
successfully sent 154 bytes
got message from 192.168.1.43:55199
successfully sent 154 bytes
got message from 192.168.1.43:54951
successfully sent 154 bytes
got message from 192.168.1.43:55011
successfully sent 154 bytes
got message from 192.168.1.43:55075
successfully sent 154 bytes
got message from 192.168.1.43:54951
successfully sent 154 bytes

However the phone says "Device not found":

Any ideas what can be wrong?

I think a recent update broke it

I had this running as a service and it worked flawlessly. Now, the iOS devices are suddenly seeing the IP as the IP of the Raspberry Pi that it is running on. Do you have any thoughts about it?

So server.js is running, sending out packets, and the iOS app is seeing the IP of the server rather than of the UNVR from the packet.

I did notice that the packet changed when I ran client.js, but I updated them.

Here is what I get when I run it manually:
got message from 192.168.10.240:49893 successfully sent 146 bytes got message from 192.168.10.240:49893 got message from 192.168.10.240:50816 got message from 192.168.10.240:59979 successfully sent 146 bytes successfully sent 146 bytes successfully sent 146 bytes got message from 192.168.10.240:49893 successfully sent 146 bytes got message from 192.168.10.240:50816 successfully sent 146 bytes got message from 192.168.10.240:59979 successfully sent 146 bytes got message from 192.168.10.240:59979 got message from 192.168.10.240:49893 got message from 192.168.10.240:50816 successfully sent 146 bytes successfully sent 146 bytes successfully sent 146 bytes

Getting two reports from each UNVR

Running client.js gets me two reports from each of my two unvrs. Eg these two are from a single UNVR:

`message received from 192.168.1.16:10001
{"type":"Buffer","data":[1,0,0,141,2,0,10,104,215,154,107,122,68,192,168,1,16,47,0,10,104,215,154,107,122,68,192,168,1,16,1,0,6,104,215,154,107,122,68,48,0,49,54,56,100,55,57,97,54,98,55,97,52,52,48,53,57,55,xxxxxxxxxxxxxxxxxxxxxxxxxxxxx,48,54,54,55,57,57,51,46,105,100,46,117,105,46,100,105,114,101,99,116,11,0,10,65,115,116,114,97,45,85,78,86,82,12,0,4,85,78,86,82,14,0,1,1,13,0,0,3,0,6,50,46,51,46,49,53,10,0,4,0,13,30,158,23,0,1,0,15,0,4,0,0,27,168]}

message received from 192.168.1.16:10001
{"type":"Buffer","data":[1,0,0,124,2,0,10,104,215,154,107,122,68,192,168,1,16,1,0,6,104,215,154,107,122,68,11,0,10,65,115,116,114,97,45,85,78,86,82,12,0,5,85,78,86,82,52,14,0,1,1,13,0,24,54,48,54,56,51,xxxxxxxxxxxxxxxxxxxxxxxxxxxxx,48,48,51,101,57,3,0,33,117,110,105,102,105,45,112,114,111,116,101,99,116,46,97,114,109,54,52,46,118,49,46,50,49,46,50,46,48,46,48,46,48,10,0,4,0,13,30,154,15,0,4,0,0,27,168]}`

I've subbed in some garbage in case there are any security problems with posting these since I don't know what they are :)

Any reasons I'm getting these back with two each?