All of their stuff including cameras used to use Chinese servers, people freaked out, they moved US users to US servers (at those cheap hosting companies along with AWS). Some of the IPs even used to come back to the Chinese Military (which is likely just because China had their own servers they required Wyze to use or something, being Communist and all).
Any inbound unsolicited UDP should be blocked by default as long as you don’t have uPNP or port triggering enabled. I don’t see anything like that but I’m not logging inbound WAN drops either.
When I don’t have the app open, my OG cams all show a single outbound UDP connection to AWS and nothing else, it bounces between heartbeats and an established connection (assuming it only establishes when it needs to send an “event”). When I open the app and view the camera, a TCP connection to AWS establishes along with several more UDP AWS connections. A UDP connection to prudential insurance (odd, may just be incorrectly registered in ARIN) pops up but never establishes, just stays unreplied, so it is either just a heartbeat or something they forgot to remove from the code.
My Pan v3s with the app closed show two TCP connections to AWS (I’m guessing one for control and one for video). They often show 2 or 3 more TCP connections to AWS that are in TIME_WAIT so just waiting to age out, not sure if they switch servers frequently or if it is attempting to connect to something that doesn’t exist. They also show 3 UDP connections to OVH Hosting (canadian company), Velianet US, and Leaseweb USA, but they all are only heartbeating. When I view that cam in the app, the AWS TCP connections don’t change, but a ton of UDP connections to those same 3 non-AWS IPs fire off. Many of them never connect and disappear but there are a lot that do connect on various UDP ports. Then after a minute or two all the non-AWS UDP connections go away except those original 3 heartbeat ones.
I’m guessing they’re either working on migrating everything to AWS and haven’t finished, or maybe there is just old stuff still left in the code. Or initial authentication still goes through their own servers. Dunno all just guesses.
I haven’t bothered to worry about it as my cams are on an isolated network and none of them are inside my house where someone watching would see anything I care about.
Maybe someone from Wyze can add some more insight.
For my OG, the heartbeats are going to 48.182.52.225:44258 which is the one that is registered to Prudential.
For the Pan v3 the heartbeats are
23.82.72.130:10001 (Leaseweb)
192.99.8.134:10001 (OVH)
207.38.90.8:10001 (Velianet)
When viewing the cam it is those same 3 servers on many different UDP ports for a minute or two then they go back to just the ones above. The same Prudential IP also pops up on a different port for a while and then goes away.
One to a different prudential IP (48.182.52.255) starts heartbeating from my phone too while the app is open (I’m guessing that is a NAT IP since normally that would be a local broadcast address and not valid).
If that post mentioned above is to be believed, it is just some sort of up/down status tracking. Not sure why they’d be leaving that on non-AWS but perhaps it is for interoperability with other Wyze devices that may not use AWS. Also not sure why so many UDP ports would need to be established for a short time on the PAN, but I’ve seen that behavior with many applications with messy code or timeouts set too low etc.
**Edit - I suppose it makes sense. Their products work with Alexa, Google, Apple, etc, and have to interoperate with other products that use those, so there being a 3rd party aggregator that is tracking up/down status of various IOT devices from many brands for that interoperability wouldn’t be surprising. Someone has to coordinate that, every IOT company isn’t going to build a connection to every other IOT company (for logistical and security reasons).
I was going to suggest using Wireshark to see what was in the packets being sent… 