I have a firewall that is not letting Alexa access the Smartbridge. Can someone advise what ports are needed for Alexa to use the bridge?
Printable View
I have a firewall that is not letting Alexa access the Smartbridge. Can someone advise what ports are needed for Alexa to use the bridge?
From some network analysis I've been doing within my home network, I see that port 8081/tcp is needed from the app on iOS as well.
Just FYI, this isn't noted on the FAQ and might be worth updating. Also, I see it wants to ping (ICMP) a lot. If that's required, I suggest that that also be listed.
I'm summarizing a bunch of traffic (so far a day and change). Once I have about a week of my device running, I will have a report that shows what ports it used (to go out), what IPs it connected to and the corresponding DNS query it made for connecting to that IP (if it made one).
At an initial glance, this makes it a lot more clear what might be needed to allow the external control/service, what might be needed just to allow updates... and also some odd traffic to "www.google.com" on 80/tcp that doesn't look like web requests at first glance.
I truly suck at networking/IoT, but I believe that might be the SMB getting the time and date?Quote:
Originally Posted by asleeis
I don't think it's time related. There is regular traffic on port 123/UFO which is NTP for time. It may be some API or function of google I'm not familiar with. I haven't really dug into the packets deeply, but what I saw looked like a small binary request to www.google.com:80 with a small binary response.
Anyway. I don't want to derail this thread too much. At a minimum, I'm spending a little time to analyze connects made out and connections made internally, doing packet captures on one of my switches. Security is my day job, network analysis is more hobby. My wife thinks I'm crazy spending free time doing packet analysis... for fun. Heh
When I do get a good breakdown of connections needed, Im happy to share the report. Already I see how I can readily lock down some services, while still allowing for updates. I also plan to validate that the device is verifying the ssl certificate is valid (not just encrypted). I guess I'm doing a mini security assessment of sorts. Hehe.
By chance did you finish your analysis? If so I would love to see what you have found even if it is only partially done.Quote:
Originally Posted by asleeis
The FAQ has great info on the ports that are required, but I would prefer to also lock things down to outgoing IP address or domain name.
I had posted it on another thread of a related topic.
https://forums.lutron.com/showthread...ll=1#post13380
It can change over time, but is a pretty good start/analysis. It's good to have the ports, but 80/443 to all the Internet isn't much of a control. The IP list may change over time, so it's hard to be certain. I decided to specify the wider subnets for the IP ranges that vary (cloud services). I was happy to see that Lutron separates software updates from the remote access/control function. I would like to see them change the URLs to the update hashes (presumably for download validation) to TLS. But overall, not too bad. I just wish they would publish something more granular than ports to all of the Interwebs. :)
Cheers,
-Alex