Email notifications not working - firewall settings?

[Whoaru99]

Cameras of topic are Dahua N44CB33.

Based on Cliff notes and discussion on the forum, I made a firewall rule to block all LAN traffic. Logically that also prevents the cameras from sending motion detection emails. When I turn off the firewall rule (presently showing as Priority 2) email notifications work as expected.

So, to try to fix it, I made another firewall rule (showing as Priority 1) that I thought would allow SMTP on port 465 as it is configured on/in each camera. It is set up to (in theory) allow any LAN traffic on port 465 yet still don't get the email notices and testing with the Test Email button in the camera GUI it says send failed.

(the bottom three rules are defaults and cannot be changed, far as I can tell)

What am I doing wrong?

 

[crw030]

Maybe try 587, AFAIK 465 is deprecated. Maybe with the firewall open your email clients are being redirected to 587 (or another port) which would not work with that firewall rule in place.

 

[Whoaru99]

I'll give that a try.

I'm not too good at reading the firewall logs, but those two cameras appear somewhat "chatty", or trying to be anyway, with IPs I'm not familiar with. Hmmm...

 

[Whoaru99]

Changing to 587 seems like it's working. Keeping fingers crossed.

 

[crw030]

Are you running with 587 AND the firewall rule in place to keep your chatty cameras off the internet? If so that should be a good configuration.

 

[Whoaru99]

Yeah, basically like what is in the picture except replace 465 with 587.

I am going to play around with VLANs too. Thread coming soon on that. Don't think that will change the need for same/similar types of rules though.

About the notifications, I need to double check they're still working by taking a stroll at Noon. Last night's work was seeing that the test emails were coming though as expected.

Normally, by now, I'd have thought a couple nuisance alerts from the camera watching the W side of the house would have shown up...but none yet. Hmmm...

 

[Whoaru99]

The saga continues. Walked right up to one of the cams and no motion detection notification received. Sigh...

 

[crw030]

Who is your email provider? I have had a few issues with GMAIL, I think Google must think my cameras are spamming me with email

 

[Whoaru99]

I'm using a dedicated GMail account to send the notifications to one of my ISP-based accounts.

 

[crw030]

Look into whether this is causing you problems:

Gmail's SMTP server requires SSL on port 465 or STARTTLS on ports 587 or 25.

I also ended up setting my GMAIL to use application logins for the cameras (which requires the headache of enabling two-factor), but it improved the reliability for me. It feels like Google is constantly changing the rules about what is "good enough" from a security standpoint (or possibly its my corporate team setting tighter and tighter rules).

 

[Whoaru99]

I had it set to SSL when working with 465 and changed to TLS when went to 587.

Wish I knew more about logging the network to try to understand what is happening when I push the email testing button in the camera GUI.

 

[alastairstevenson]

I'm using a dedicated GMail account to send the notifications to one of my ISP-based accounts.

So - does the gmail account receive the email and not just forward it?
If you configure the receiver account as the gmail account, does that test OK?

 

[crw030]

Gmail will keep a copy of forwarded emails unless you configure it not to, can you login to that Gmail account and see if you have any of your test messages in the inbox of the account you have setup to forward?

Maybe while you are at it confirm set your forwarding up correctly (link: Automatically forward Gmail messages to another account - Gmail Help) and double check in case you received a confirmation email at the recipient account to "authorize" the forwarding and forgot to click the link.

 

[Whoaru99]

So - does the gmail account receive the email and not just forward it?
If you configure the receiver account as the gmail account, does that test OK?

My opinion is it seems not getting out of my network.

If I make it easy by temporarily lifting the LAN traffic blocking firewall rule it always seems to work.

When I push the email test button in the camera GUI a message pops up indicating email send success or send failure. If it says success it pops up in my email shortly after. If it reports fail then I never see anything in my inbox nor other folders.

I did misspeak previously about the email accounts. This I have set up both outbound and inbound through GMail.

 

[crw030]

Can you TEMPORARILY turn on logs in the Admin tab of the Linksys LRT214 interface (link: Linksys Official Support - Monitoring traffic logs using the web-based setup page)? Then try again and check the outgoing log?

It probably has flash or some other storage with "limited writes" so you won't want it on forever, but it might help while troubleshooting this issue if it indeed shows blocked traffic and so forth.

 

[Whoaru99]

Yeah, I could do that. I did some of that but I didn't see anything that jumped out...probably because I don't know exactly what to look for.

I could mirror one of the camera switch ports and Wireshark it if that would be better?

 

[crw030]

Might be worth Wireshark it to at least confirm the camera is trying to reach a remote host and what that remote host is responding as well as which port the camera is using and so forth.

I would probably Wireshark it with the Firewall rule disabled, and compare to when you turn the rule back on, see if something jumps out as being different. Just beware, Wireshark captures can get really big really quickly, so start it, send the test email, wait few seconds and turn it off.

 

[Whoaru99]

Did Wireshark with and without the firewall rule in place.

When I sent test email with the rule off it showed source (src) 192.168.215.30 port 43906, destination (dst) 108.177.111.108 port 587.

1st IP is the camera, 2nd IP is Google.

I did the test a 2nd time and the odd thing, at least to me, is the src port of the camera on the 2nd test was 43907. All else was same.

Then I did a test with the firewall rule turned on and again the src/dst IPs and dst port 587 were all the same, but the src port this time was 43909.

Is it normal (expected?) the src port would change/increment like that? If so, how would you ever set up a good pass rule for the email notifications?

I also tried an Nmap TCP port scan on the camera IP 192.168.215.30. It didn't come back with any ports like 439xx, only port 80, 554, 5000, and 37777.

 

[alastairstevenson]

Is it normal (expected?) the src port would change/increment like that?

The source port under IP is in most cases just a semi-random high port - in principle it could almost be anything.
The destination port is meaningful though.

I also tried an Nmap TCP port scan on the camera IP 192.168.215.30. It didn't come back with any ports like 439xx,

That's not a 'listening' port, just a source port to initialise the 'conversation'.

Then I did a test with the firewall rule turned on and again the src/dst IPs and dst port 587 were all the same, but the src port this time was 43909.

The key part of this, whilst recognising that the packet content would not be visible as it's encrypted, would be to map out the 'conversation' and in particular how it differed from the successful one.

 

[crw030]

The key part of this, whilst recognising that the packet content would not be visible as it's encrypted, would be to map out the 'conversation' and in particular how it differed from the successful one.

^^ THIS ^^

@alastairstevenson is right, source port is not meaningful, typically a high port number and semi-random. Important part is to see if there is any change in the way the back-and-forth conversation changes with the firewall in place. Did you turn on your firewall logging? I wonder if the packets are simply being dropped, if so I would expect that to appear in the firewall logs.