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

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.

Gertjan

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

on VLAN30

Remember : While testing, your Phone must be on "VLAN30" also.

yvesict

@gertjan even with phone on VLAN 30, no push messages...

Gertjan

@yvesict

I propose a last resort test :
Double check that your daily config backup of pfSense is ok.

Now, as usuall : reset pfSense to default.
Accept de fault settings, never aver add a setting, like a DNS server (not needed) - just a WAn and a (one) VAN - stay away from VLANs. Nothing fancy - just the "out of the box" settings.
One exception : you are allowed to change the GUI password.

Now, phone an the LAN. The 192.168.1.1/24 LAN
Doorbell on the 192.1681.1/24 LAN.
Nothing else has to been do on pfSense - as per Doorbell Quick instructions guide.

Btw : Now you have created a pfSense like as any other router/firewall you got from your ISP ... it is and behaves as all the other firewalls on planet earth.

Right now, you could inter change your ISP router with pfSense, and have a working LAN network.

If a device doesn't work right now out of the box, you know it is the device.
Can't make it work => don't waste your time - waste-bin it.

Btw : setting pfSense to default isn't fool proof.
Just count those who set up their LAN like this :

and then complain "the DHCP server doesn't work"...... (no pool available).
Or they assign a gateway to the LAN settings ..... (same image)..

Rainbowergy

Since your devices are isolated for security reasons, it could be blocking the communication needed for those alerts. You might need to tweak your firewall settings or NAT rules. If the issue persists, it could be worth exploring how systems like Vivint security system handle network segmentation while still delivering reliable push notifications.