Switches and AccessPonits connect to some Links in in the Internet
Hi everybody,
did anyone know for what my switches an aps need to connect to the belows links?
n-devs-smb.tplinkcloud.com
n-deventry-smb.tplinkcloud.com
thank you
- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
I am new to the Omada Platform and was VERY surprised when my firewall registered some connection attempts to some AWS EC2 instances from the Management VLAN (to be exact from a JetStream Switch). I have a local self-hosted Software controller, don't use nor EVER enabled Cloud Access. So my question is why the switch is still trying to reach out to TP-Link Cloud??? This is to me a very strange and concerning behavior.
I hope TP-Link has a good explanation for this, otherwise this is not really confidence inspiring.
- Copy Link
- Report Inappropriate Content
Its nothing to worry about
The SDN needs to check if there is internet connection and it does this by sending occasional pings to a few random sites. If i remember right, during my testing I came across AWS and Azure
The packets didn't have anything bad, was literally just checking internet connectivity against common sites occasionally. The sites where random order and generally something you can guarantee will be online 24/7, like AWS for example.
Most vendors do the same thing but hit a few select sites of their own hosting, TP Link seem to do it differently however and use 3rd parties.
- Copy Link
- Report Inappropriate Content
Not quite (at least in my case) it is not going to random sites, it is specifically going to the two endpoints mentioned above (n-devs-smb.tplinkcloud.com and n-deventry-smb.tplinkcloud.com) which are hosted on AWS EC2 Instances. Btw, if in your case it's random sites, just to check for internet connection, I then genuinely wonder why should a switch care about internet connection??)
After some packet capture, the connection happens when the switch starts up (or the internet connection is broken). After the initial TLS handshake and a chunk of data is sent out (484 Bytes) the connection is then kept alive by constantly sending small amount of data (from 28 to 54 Bytes) back and forth.
In the documentation of the Cloud Based Controller I found this "Add devices with the serial number, make sure the devices are online and in factory default".
So here's my assumption: Omada Devices in factory defaults "register" themselves (their serial numbers) to the TP-Link Cloud and keep the connection alive (either hole punching or polling for adoption status/request) until they get adopted by a cloud based controller.
Now I understand this is nothing to worry about, but it would have been great if TP-Link gave us the option to disable this "registration" process once the device is adopted by a Hardware or a Software controller. Or better disable it automatically, as once adopted by a controller the admin password is changed from the default one and they cannot be adopted by the cloud controller anyway (hence requiring factory default for cloud controller adoption)
Side note: Love how devices get adopted by cloud controller only with their serial number and default admin password...... so basically, if you are not quick enough and/or someone else at the same time made a typo, your device will be adopted by another account (and with automation, this is basically a DoS attack on the Cloud Adoption Process) :D
- Copy Link
- Report Inappropriate Content
Information
Helpful: 1
Views: 1210
Replies: 4