Amcrest Forum

I have four new Amcrest 841B cameras, hooked to my home LAN. I use VPN when away from home, so no need to place them on the internet outside of my VPN.

I've set up the four Amcrest + four Insteon (Foscam equivalents) on Static IP addresses (all in a contiguous IP grouping) on my LAN, and have disabled all external services on the cameras. P2P is OFF, Cloud is OFF, etc. Multicast is OFF. SNMP is OFF. Everything except email alerts and NTP is OFF.

In my Router, I've disabled services (ports) for the group of Camera IPs on my LAN excluding ports 123 (NTP), 465 (SNMP), and 587(SNMP)...as that is the ONLY traffic the cameras should be trying to pass thru the Gateway to the internet. (So for the Camera IP group, they are allowed to pass ports 123, 465, and 587. That way they can set the time via NTP, and send email alerts via Google gmail.) Otherwise, my expectation is that no other ports need to forward ANY traffic, so all other ports are blocked in Router for the Camera LAN IP group. This took four rules to accomplish. Block from 1-122, Block from 124-464, Block from 466-586, and Block from 588-65535. Viewing the cameras should be unaffected on the LAN, and VPN clients are on also the LAN for all intents and purposes. So there is no need (AFICS) for there to be any other Camera traffic going to the Internet.

I also have general rule in my Router blocking NETBIOS that applies for everything on my LAN. That particular rule is NOT being triggered currently.

So, I'm wondering why I am getting constant Router logs alarms with the Amcrest IP addresses attempting to send traffic on ports 1-122 and ports 124-464? (Two different rules are logging alerts). Most of the log alerts are for ports 124-464, a few for 1-122, and NONE for 588-65535.

To be clear, I don't believe the Amcrest are trying to use ALL the ports in the blocked range, just probably 1 or 2 of them. But from the log, I can only get the alert for the full range (1-122 or 124-464), as tied to the rules. So the point is that the Amcrests are attempting to send traffic out to the internet on SOME port (or ports) in these ranges.

Any ideas? This is disconcerting, as AFAICT, there is no reason for the Amcrest to be trying to go thru the gateway. Also, it is interesting that I do not see any any traffic logs for attempts from ports 588-65535.

I don't want to have to hook up Wireshark and do packet captures as that is a pain. If anybody has any ideas, they would be much appreciated.

Otherwise, I have concerns that we have some kind of stealth "Phone home" thing going on. I'm glad I can block in my router, but I should not have to do that if I disable otherwise in the Cameras. Plus it eats up network / router overhead. It's not like i have some commercial router...it is a simple consumer class NETGEAR.

Hello bguzikf,

Please take a look at the below thread. I think your problem is related.

https://amcrest.com/forum/technical-dis ... 7ed06386a9

Melvin,

I'm still not seeing any kind of respectable answer from Amcrest as to what is going on. If outside internet access is disabled by the end user for the devices, then the devices SHOULD NOT be trying to otherwise communicate out to the Internet...period. Doing otherwise creates the perception that Amcrest is spying on it's customers, which is completely unacceptable in a safety/security product. Amcrest needs to fix this. After disabling all access except for NTP and email for my Insteon (Foscam) 720p cameras, they are NOT making any other attempts to communicate out to the internet. That is how it should be.

Hello bguzik,

We do understand your point and will investigate on this. Thank you for the suggestion.

It's definitely not just an fw update check. There is at least one destination outside the internal network that the camera constantly tries to reach, even tho p2p/cloud is disabled.
It's a fixed IP 54.158.250.32, which is an IP address of amcrestcloud.com and the connection attempts are made on port 443 (https).
";; ANSWER SECTION:
amcrestcloud.com. 19 IN A 54.158.250.32"
So not even the trick of not pointing the cam settings to a working DNS server does work, as it's using fixed addresses.

I agree that this is not very trustworthy for a security product! And even more, it's not a "sugesstion" to let the user decide if the device calls home, but an urgent demand!

Hello all,

To clarify some of the questions regarding the camera's connection to the cloud.

1 - By design, the camera does connect to the cloud servers so that it's available to be added to a user's account. No video data is transmitted during this step and if the camera is not added to a user's account within 2 hours the connection from the cloud servers is dropped.

2 - The information related to the cloud services provider being discussed here is simply standard information contained within the server's TLS certificate. It's part of the information exchanged when establishing a trusted TLS (SSL) connection, along with exchanging encryption keys. Here's a primer on TLS for those that are interested: https://en.wikipedia.org/wiki/Transport_Layer_Security

Hello Melvin,

thanks for getting back to us with this issue.
Regarding your points:
1. This is not true, I never had an user account nor did I ever try to connect my camera to it, but still, after days (not hours) of usage it is still trying to connect to the IP 54.158.250.32.
2. I understand SSL/TSL technology, but the question still remains, if the user decides not to connect the camera to the cloud, by not activating the function in the web interface, why does it still attempt to make a connection at all?