Cameras outbound traffic trying to reach too many different IPs

I’ve asked support more than once for a list of IPs or something to whitelist for the outbound traffic from my cameras.

They have not answered.

However, I’m becoming less and less confident in the security of these cameras.

I’ve been whitelisting Amazon ranges. I’ve done about a dozen. But Amazon has about 800 in IPv4 space. Too many to whitelist all of Amazon AWS/EC2.

As I look at my logs tonight, I see one camera trying to reach,, hosted by OVH Hosting in Montreal.

And,, hosted by Linode in NJ.

I don’t understand why the camera needs to reach out to all these random locations.

I recommend everyone keep an eye on your outbound traffic. I wouldn’t recommend allowing these cameras to just reach out to the internet without knowing where it’s going.



I’ve noticed the same, traffic to a few IPs including the ones you listed that are concerning. At first it was just a bunch of dropped inbound UDP I saw, but it hinted me off to look at the traffic a bit more.

Tutk is p2p provider. The camera needs to keep a heartbeat with the P2P server so that it can let your phone to connect to the camera for live streaming.

@WyzeDongsheng I understand, but I do see a lot of dropped traffic on my firewall inbound that is not attached to an existing UDP stream.

And I mean constantly, a few every second:

proto UDP,>x.x.x.x:38445, len 44
proto UDP,>x.x.x.x:37962, len 44

Have any idea why I’d see so many inbound UDP calls? Is there a description of how the Tutk service works with Wyze a little more?

My UDP state connection tracking is set to 10 seconds for initial response, then 3 minutes for the stream timeout. This should be enough for the hole punching I’d imagine.

Hi, we talked to ThroughTek about the inbound packets. They confirmed the IPs are their servers and said the inbound packets were to make sure the servers can find the devices for future connections. This is related to NAT punching (Network Address Translation) working correctly. Thanks!

Any thoughts on why they are being dropped constantly by my firewall? That means they aren’t matching my NAT connection state tracking (or the equivalent for UDP which is connectionless).

It’s not a huge concern since Wyze seems to be operating correctly, but it may be indicative of something under the hood that is not working well or is inefficient at minimum. I wouldn’t expect so many inbound packets being dropped by my firewall under normal circumstances.

This is happening in two different homes for me, both with Mikrotik routers under fairly normal IPv4 firewall rulesets (basically near stock). It’s basically a basic Linux conntrack setup in terms of rules, timers, timeouts, etc which means it should be similar to consumer Netgear routers, etc. I’ll see if I can test on one of those, too.