Push messages from Doorbell/camera not working. Possible NAT problem

yvesict

Hello there,
i have a Dahua VTO door camera and access system. For security reasons, i put my doorbell and camera's on a different VLAN. This VLAN can access the internet, but not my LAN/other VLANS.

I have the app on my phone and can add the VTO with a P2P QR code without any problems. I can see the image, i can talk and here everything.

Just the push messages to my phone (when someone uses the doorbell) are not working. I tried every setting to enable notifications, tried different phones etc, but push messages don't work.
After some reading. I found that i had to open port 8888
This is the article
But i am not shure how to achieve this. Can anyone tell me what steps i must take to achieve this?
Thx in advance!

Gertjan

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

After some reading. I found that i had to open port 8888
This is the article

Port 8888 hat to be open (NAY) from the outside ?? That's old school.
The web site you've mentioned isn't even clear about it.
I guess the doorbell goes somewhere (aws) using destination port 8888. It constructs a TCP connection, and waits. If the TCP connection goes down, it's rebuild. Live events are transmitted over this 'always on' outgoing connection.

As said in the thread, you could packet capture the doorbell traffic.
Use the destination IP, the destination port 8888 and protocol TCP.
Press the button : there should be packets from the bell to the aws server.

There is one factor your can't really test : the bell sending packets when pressed, is ok. But what does the other side do with the doorbell push event ? Is that service working ? It should really to to phone, using your phone App, that also opened a permanent connection to the same server. if that connection isn't good, or the server on the aws side doesn't work properly, your out of luck.

yvesict

@gertjan Can you tell me how to package capture this? I would use wireshark i suppose. I know the internal IP of my doorbell/camera, but how can i find the destination IP?
Thx for the help!

johnpoz

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

would use wireshark i suppose

You can just packet capture on pfsense directly under the diagnostic menu - you could then sure open up the packet capture in wireshark for better viewing..

yvesict

@johnpoz good tip about the build in package capture. Offcourse i am not shure about the destination IP or the port.
In PFsense interface, i set the VLAN in which my doorbell is

address family: any
protocol: any
host address: blank
Port: blank

ip of doorbell is 192.168.30.26, gateway is 192.168.30.1
When i run this and then press the doorbell, this is the output:

16:37:23.110414 ARP, Request who-has 192.168.30.1 tell 192.168.30.26, length 46
16:37:23.110431 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28
16:37:24.870933 ARP, Request who-has 192.168.30.1 tell 192.168.30.26, length 46
16:37:24.870947 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28
16:37:27.272757 ARP, Request who-has 192.168.30.1 tell 192.168.30.25, length 46
16:37:27.272770 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28
16:37:32.876361 IP 192.168.30.25 > 224.0.0.22: igmp
16:37:32.913294 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 37
16:37:32.913337 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 16
16:37:32.913345 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 17
16:37:32.913579 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452
16:37:32.913700 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452
16:37:32.913821 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452

I don't know how to proceed now. Can anyone help me in the right direction? Thx!

johnpoz

@yvesict well that is just arp and multicast - that isn't going anywhere other than local.. You know the port.. So put that in.. But from that sniff there is nothing going anywhere..

Gertjan

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

16:37:23.110414 ARP, Request who-has 192.168.30.1 tell 192.168.30.26, length 46
16:37:23.110431 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28

Your door bell = 92.168.30.26 want to know who "192.168.30.1" is.
Your door bell was told by it's DHCP client that "192.168.30.1" is the gateway of the network. So the bell wants to know what MAC address is used by "192.168.30.1" ( == a pfSense LAN interface) so it knows now how to get 'out' (to the Internet) if needed.

16:37:24.870933 ARP, Request who-has 192.168.30.1 tell 192.168.30.26, length 46
16:37:24.870947 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28

The same thing again - a second later.

16:37:27.272757 ARP, Request who-has 192.168.30.1 tell 192.168.30.25, length 46
16:37:27.272770 ARP, Reply 192.168.30.1 is-at 00:08:a2:0d:eb:40, length 28

And again.... 3 seconds later.
This bell has altzheimer or what ? Memory issues ? The wifi connection breaks every second ? As this would explain why it's rambling over and over again with ARP like this ??

At :

16:37:32.913294 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 37
16:37:32.913337 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 16
16:37:32.913345 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 17
16:37:32.913579 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452
16:37:32.913700 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452
16:37:32.913821 IP 192.168.30.26.20001 > 224.0.2.14.30000: UDP, length 1452

the bell starts to use a broadcast address "224.0.2.14" using port 3000 - protocol UDP.

So, some local device, connected to the same network, that uses an application that listens for this broadcast address - port 3000 - protocol UDP, should accepts these packets and 'do' something with them. This app will know what the payload (= the data send over = 37 16 17 1452 1452 1452 bytes) means.

This broadcast traffic never leaves the network. Where network is the LAN segment in which your bell is connected. If the device is an VLANX and your phone is on LAN or VLANY, then, yes, all is well, you'll never receive the braodcast from the bell. Your device should be in the same network.

pfSense (the packet capturing) sees the broadcast. The question is now : the device, like a phone (you didn't tell us what , should also 'see' these broadcasts. Your Wifi AP should pass them to this device. The app should be installed on the phone. Etc.

Btw : dono if it is possible for pfSsense to relay the bell broadcast traffic to another LAN type network where your phone is.
It might be possible that the bell presumes the typical 'home' network is what we find in 99 % of all homes on this planet : a WAN and a (just one !) LAN. All home devices are on the same "LAN". There are no 'VLANs" or multiple LANs or other sophisticated things that pfSense offers.
So, normally, no need to NAT or whatever. Just plug and play.

johnpoz

@gertjan Well sure it might be a local notification - but there really should be an external notification. Most of those door camera/doorbell things let you know when your say at office and someone rings your bell.

Local notification would be really limited and not of much use to be honest.

Where is port 8888 being used - there was no traffic on that port, etc.

yvesict

@johnpoz @Gertjan
thx for the update. I will try to explain some more
My doorbell (dahua VTO) is connected to my app through P2P (the app from that bell scans a qr-code and a P2P-connection is set up between the app and the doorbell.
In this app on my iphone i can see the bell, i can talk through it and so on. I have made sure that all notifications are on on my phone.
The phone doesn't need to be in the same LAN. What i am trying to achieve, like @johnpoz says is a notification from the app when your say at office and someone rings your bell.

When i put my iphone in the same VLAN, it also doesn't work.
When i read the comments from you guys, it doesn't even leave my network and i don't understand this part.

Gertjan

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

My doorbell (dahua VTO) is connected to my app through P2P

This : https://www.dahuasecurity.com/asset/upload/download/DHI-VTO2111D-WP_datasheet_20171206.pdf ?
Something else ?

Sure thing is : the bell should 'go outside' - contact 'home' (where it was created - where you registered it).
Your phone, the App, should also contact 'home' - and when using the same identification, the connection is made bewteen your bell and your phone.
Advantage : no NAT or other rocket science needed. TeamViewer works exactly the same way. It works out of the box.
Disadvantage : with this method you invite Chinese servers right in your bell, and your phone ... (and I ask forgiveness to China right now ^^ ).

Or : something else need to be done.

Let's activate the RTFM method.
Where is it ?

yvesict

@gertjan it's VTO3211D-P1. I got this from the firm i ordered:
user manual
quick start guide

Gertjan

@yvesict

The word 'router' only occurs twice in the Quick Start Guide :
The second one is important :

3. Construct a Safe Network Environment
In order to better ensure the safety of device and reduce potential cyber risks, we recommend:
 Disable the port mapping function of the router to avoid direct access to the intranet
devices from external network
.....

edit : <wrong : !!>
This means : no (pfSense) router setup is needed. This means NAT can't be an issue as it isn't needed.

It also means that the bell connect to outside 'Dashua' services (IP's on the Internet) like any other device. (This means that all info like video passes trough them ...)
</wrong : !!>

The PC/Phone/pad connection examples, are wired or wifi, presume that you are LOCAL to your device.
That is great for a security point of view.

This also means : when you not @home : the phone / pad app doesn't work - as you're not connected locally.

Btw :
I also use the Dashua gDMSS Plus app on my iPhone, as I have an Dashua DVR with 8 cameras.
I still can use app even when I'm not on site. This is because I have to enable VPN access to home before I can sue the App.
This means, for me, that push 'notifications' are not possible (mails notifs still works).
When I want to use the app, I have to fire up my VPN-to-home first.

You could of course :
Get a dyndns service for your IPv4 WAN IP.
Open the correct port and protocol. This means NATting !!!!!
Now, with the app, fill in your domain name like "yourhome.dyndns.org"

Again : DO not do this. never exposes cameras of whatever to the public, even if you think the password is safe.

end edit.

The bell's IP gateway DNS and network has to be set up according the interface on pfSense.
The Quick Guide didn't tell about DHCP ..... so maybe there isn't a DHCP client.
Double check your static IP settings again.
IP : 192.168.30.26
Mask/network /24
DNS 192.168.30.1
Gateway 192.168.30.1

Also, check firewall rules on this "pfSense interface 192.168.30.1" : place a global pass all rule first. When things start to work, you can specify more strict rules. Don't block DNS !
Keep in mind that the device could have a contract with Google : it might insist on using 8.8.8.8 or others.

Show us your "192.168.30.1" rules.
Undo all NAT related stuff : as "Quick" said it isn't needed.

yvesict

@gertjan
This is my firewall config for VLAN 30

but even when i change to this:

Still nothing is happening. I believe the lasts picture is just an allow everything from and to everything.

johnpoz

@yvesict tell you right now your first 2 rules there are wrong order.

Rules are evaluated top down, first rule to trigger wins.. So trying to use pfsense for dns - your first rule there blocks that, your 2nd rule that says hey you can access 53 on vlan net?? never evaluated.

You mean address there most likely. Pfsense has zero to do with devices talking to each other on the same network.. So allowing vlan30 net to talk to vlan30 net would never come into play..

yvesict

@johnpoz you are absolutely right. My mistake. But when i put the allow everything rule first and disable the rest for testing purposes, then this should work or not?

Gertjan

@yvesict

Yep, this :

allows everything from your network to go to everywhere.

You could duplicate this pass rule, put it on top, and add as a Source "192.168.1.30".

Like this :

I have no device on LAN 192.168.1.30, so the rule counters will stay at 0/0 as this first rule never matches any traffic.

Then, if 192.168.1.30 (the doorbell) is sending something to somewhere, the counters, these :

will get incremented.

yvesict

@gertjan Not completely sure what i can learn from this? Isn't the fact that i put my doorbell IP there and counters get incremented, because it is sending ARP requests and so on? The fact that it can't get outside local network doesn't seem to change.

johnpoz

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

ARP requests and so on?

Arp would not trigger the firewall rule.

yvesict

@johnpoz But when i package capture everything on VLAN30 i don't see any new info.

johnpoz

@yvesict said in Push messages from Doorbell/camera not working. Possible NAT problem:

VLAN30 i don't see any new info.

Well then pfsense isn't seeing anything on vlan 30.. So again, traffic between devices on the same vlan have nothing to do with pfsense. Only traffic sent to pfsense to get off the network would pfsense do anything with. Be it allows it or blocks it.

Yes arp would be seen by pfsense since it is a broadcast, but it wouldn't trigger a rule because its not actually sent to pfsense, and its not trying to have pfsense send it anywhere.