I know these messages are normally apps that have been removed or whatever.. but this ip address is very strange.. anyone have any idea what from an amazon aws ip would be trying to call and ap or url in the hub?
could be one of the devices i shared via the alexa app? but none of my alexa routeines have fired. i will look at my alexa app for activity around that time.
Usually the errors if the app is removed are different, and list an app number it was trying to reach.
I think even if a malformed Maker API post from externally would have an app ID in the error?
Its not something to do with Matter is it? Did you have and remove a matter device possibly?
Otherwise, the hex strings after the IP remind me of Zigbee DNIs
no matter in use..
only thing i did today was install a new linptech mmwave zigbee.. wonder if it went out trying to hit something..(maybe parent app) i dont have a tuya hub so paired directly with hubitat.. but if that was the case the pseduo zigbee ids would all be the same.. really weird.
Are you using port forwarding with your hub directly exposed to the Internet? From the log entry, that seems like the only way this could happen -- something at that IP address sending something to your hub on port 39501. (If you have anything forwarded to your hub on that port by any means, I'd also check that.)
I suppose it might be possible for a device on your network to purport to have that IP address (even though locally it shouldn't) and send traffic on 39501 to your hub as well, if it could somehow route there within your network, but what that could be, I couldn't guess...
Has to be... there are two port fwd rules for the 2 ecowitt installations in florida to port 39501 . But why would some ip in the amazon cloud be hitting those high ports i use? Must be some sort of port scanner. I will block it in my firewall going fwd.
Couldn't you just use maker API or the ecowitt cloud stuff instead of opening that port on the hub to the wild? Basically, there are better (safer?) ways to do that instead of exposing the hub.
no it is not updating a specific attribute but there is an entire data stream propriatary coming in from the ecowitt sensor.. i can further refine that port to just fl. but the problem is i need to open up pretty much everything from the aws cloud.. ( i dont specifically open that port anyway) i open stuff from the subnet that the condos at so outgoing email and stuff works as well.
when i dont open up the aws ips, stuff like apps on my phone .. ie residio, tesla, samsung cams, amazon, ewelink etc. dont work correctly and unfortunately most of these stupid apps dont publish what weird ports they are using and it is really hard to figure out.. ie if look at ports or requests my phone send out there are way too many to go through... i have tried. it would be nice if all the apps just used port 80 but they dont. that ip is one in the aws cloud i open up. from random ips.. if you try to hit that port it will not work.. go ahead and try to hit 173.14.182.124. its not even that port anyway.. it is another high port being port forwarded to it.
not applicable.. cant use permant site to site vpn in a rental condo
and what does that have to do with certain aws ips being open in order for apps to work.. (which is the crux of the issue).
this is much more complicated than a normal home router.. i have true public ips.
Actually in reading this thread I was thinking you are managing more that 1 external Ecowitt. My thought was that you were allowing access to the port for your purposes, and that you are able to control both sides. My apology if mis-read. Never said it was a home router.
Respectively, I will take a step back.
I would not be hanging 39501 open to the world. Assuming you know the remote locations, and assuming they are static/public IP's why not apply an ACL rule or other rule that only allows them to access. There may be a technical reason that you are aware of, and unless I am missing something, I just cannot think of one.
it is not open to the publc.. see above.. that is what the port probe shows.. in addition the port fwd to it 8910 (also shown) above is not open to the public
the problem is i dont know what specific ports form amazon aws ips i need to open for apps and things to work..
but i will add a specific rule to block amazon aws to the fwd ports and port 39501 before i open stuff up.. thanks
new rules
add chain=input action=drop src-address-list=AmazonAWS dst-port=8900-8910 comment="Block amazon to ecowitt"
add chain=input action=drop src-address-list=AmazonAWS dst-port=39501 comment="Block amazon to ecowitt"
I should have looked closer at the images..
Also, 39501 is the Hubitat API (some-what API) and is not specific to Ecowitt.
Maybe why I am confusing things in this thread.
Assuming you are sending data from the Ecowitt, you are sending to your Hubitat device.
Hubitat is listening for requests on port 39501. Is that now what you are doing?
correct but only from specific ips.. (only the ports forwarded to 39501)
however stuff is pretty much wide open from aws ips.. if i close them down.. which i did in the past ...many stupid apps that use aws dont work on our phones because they are using non std ports and don't document what they are using..
i am not sure what home firewalls do.. but my default is everything i don't specifically open is closed and when this is done on aws ips it breaks many apps.
39501 is listening to everything, and will match the source IP or MAC with a matching DNI within Hubitat. With respects to firewall, I am not a big fan of consumer firewalls, as they overly simplify things, which is fine for most users.
If you adding rules to prevent ingress is breaking things, I would think the rule(s) are either setup in the wrong direction, or may not be stateful. What I have instructed my teams in the past is to
block all inbound, and allow inbound established or allow inbound responses to an outbound request, and then to allow/restrict outbound access as needed.
Most firewall's today are stateful so that should not be a problem, and by default will allow all outbound with only inbound established. When adding VIP's or port forwarding you need to be careful with respect to who or what can access them, creating the necessary rules to protect the destination devices.
Not sure what type of FW you are using, and if things break connecting from internal to external, I would suggest closely analyzing your ruleset(s).
My apologies if this is obvious to you, and I mean no disrespect.
Take care.