bahamas10/unifi-proxy

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

unifi-proxy's Issues

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

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).

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?