I had a weird issue last night and wanted to get some feedback. I decided to go with the flow and I changed the mgmt vlan on an existing system to the default on route10. I only have a route10 and ap6 from Alta. I allowed the route10 to handle dhcp for mgmt and connected 10-15 various switches/servers, etc. I run my own DNS, there are at least 3 name servers in the network.
Everything was working fine until somehow the management vlan decided to grab local ip’s and map them to Alta ddns and I COULD NOT get the local name servers to resolve a correct address. In fact when I accessed one of my servers by its ip, I got the screen that told me that device was managed by the Alta cloud!!!
I would like to know what’s happening and the best way to stop it from happening again or I will need to find another vendor!!
I don’t think I’ve seen that behavior myself, but perhaps if someone else has they’ll chime in. Think it would be possible to have a little diagram of how the network and devices are setup right now? It might provide some more clarity to anyone else looking at the thread
We’ll need quite a bit more information to understand what is going on at your site. Can you please provide step-by-step instructions on how to reproduce your issue?
What local name servers are you using, and what names are you querying, and what did you expect vs what did you get? The only time Alta APs will intercept DNS traffic is when there is an unauthorized WiFi client connecting to a hotspot-enabled SSID (or during the time an SSID is scheduled off). Alta Routers will not intercept DNS traffic at all, though they will forward, of course, if configured to be the DNS Server for the VLAN, which is the default. Do you have any screen shots of your server showing that it’s managed by the Alta cloud? Alta’s controller can only manage Alta-branded devices.
The issue has been resolved but I don’t know why it happened. Here is a synopsis - I use the route10 as a firewall/gateway mainly. I have a Public static ip on the W1, the Default vlan1 (10.10.1.0), and the uplink to the core switch which is 10.10.90.10 on W2. All the vlans are routed on 2 layer 3 switches, so the route10 handles the connection to the internet. As I stated - I decided to switch out the existing mgmt vlan and use the “forced on me” default vlan 1. I had connected most of the switches and servers and thought everything was ok. I needed to spin up a new server with the ip 10.10.1.11 and in the process I got this http://10-10-1-11.lccz18xnta3.ddns.manage.alta.inc/hotspot.html instead of the mgmt interface on that server. I tried several times to connect, clearing the dns cache, rebooting, using different browsers, - even connecting through ssh and kept getting the url above. After making several changes and connecting directly to the server - I got the colorful window and this message - This device has already been configured on an Alta Labs controller. Please use the controller for further configuration. Of course when I logged into the controller that was not the case.
I have since disabled the DHCP server on route10 and am using dns within the network and everything is working fine for now. I was really ticked off when it happened but there is nothing to do at this moment because everything works. Just reporting an FYI.
I would like to see some options regarding a couple of things - since I have public ip’s, I DON”T like to deal with ddns and would like to see an easy way to disable it as well as an easier way of dealing with the vlan 1 situation. It probably makes it easier for you guys and novices that you deal with - but it’s an irritant for IT people.
If you are using the latest firmware to set up the Route10 initially, there is actually an option to specify an alternate management VLAN/subnet during the setup process, so I’d be curious if you performed a Power-on-Reset before setting things up.
Glad to hear that the issue seems resolved. The main reason why we use dynamic DNS out of the box is to eliminate all insecure communication when setting up and configuring your network. As you’ll note with most network vendors, broken SSL locks are pervasive. Security is a top priority for us, and TLS certificates require a valid hostname, which is where DDNS comes in.
