question about managing equipments from different network

[skyhigh]

Hi everyone! I have been reading the forum on aircontrol and didn't really get a direct answer or it could be me not understanding the terms used in this discussion. Can air control manage Ubiquiti equipments on different network? I can scan and find other units on a different IP range but I'm unable to get air control to manage them. Or is it because I have to make sure that the HTTP port on other network router open on HTTP 8080?

Thanks,

[UBNT-Thomas]

The devices need to be able to reach the HTTP port of the AirControl host - which is 9080 per default. Sometimes there are firewall rules for outgoing connections that prevent this. You would see and error message when you attempt to connect stating this.

[sep78]

Remember, if your external IP is port forwarding to a different IP than your actual internal server (internal ip) you will have to tell the remote AP the external IP by sshing.

mca-ctrl -t connect -s http://nat.ip.address.x:9080/heartbeat

[UBNT-Thomas]

It is assumed that the AirControl server is directly reachable from the units. Above is a workaround for a currently non-supported deployment scenario.

Out of curiosity, what is the reason you need to run the AirControl server behind NAT? It would be possible to add a global system setting for the server address if that is something that is frequently needed.

[lncommunications]

Hi all,

Thomas I believe it's a similar the scenario I have been dealing with.

We have a number of networks all remote and in different places. Most of the networks are setup with a local subnet with NAT i.e.

[DSL/Fibre Modem] --- (public IP)[WAN - Linux Gateway - LAN](local subnet) --- [First Ubiquiti Device]>>>[rest of the network]

Linux Gateway IP: 192.168.100.1
Linux Gateway WAN: 80.x.x.x (public)
Linux Gateway LAN: 192.168.100.x
First Ubiquiti Device: 192.168.100.10 (then rest of the devices .11, .12, .13 and so on)

Before the patch, which ill come back to, I envisaged having to put a dedicated server with AirControl install into each local subnet so we can log in from our office to manage devices.

Now...the way I have got AirControl to work is with the latest patch you sent, I can VPN into our existing Linux gateway so I become a member on the local subnet. I then go to add a device manually and input my subnet e.g. 192.168.100.0/24 - BINGO! all my devices appear! I can then manage as I would if I were in the network itself. I then create a seperate watch folder for each network, add the devices per network to each network folder. When I want to check/manage I VPN to the network I want to, load AirControl, go to the folder click scan and within seconds all contact is restored.

One problem I have found with the VPN scenario is that no historic data is saved for obvious reasons, this is another PRO for having an AirControl server within the NAT'd network running 24/7.

Hope this help :S

[lncommunications]

By "global setting" do you mean add an IP the device reports info to? i.e. the server address out on the internet?

That would be good!

[UBNT-Thomas]

Yes, you would enter the (potentially forwarding) IP/port of the AirControl server once and it would be used for ALL devices as the reporting address. The default behavior is to automatically provide the IP of the AirControl server's network interface that connects to the device.

In your setup, this would be the VPN assigned IP, and therefore as soon as you switch to another VPN connection, the same becomes invalid and devices can no longer report statistics to the server (hence no historic data collected).

Is your AirControl server setup so that all device could reach it at the same IP without VPN? In that case what I suggested would solve your problem.

[lncommunications]

I like the idea of a centralised AirControl Server, though surely it would render the "launch web UI" useless though that is just a small if not minute issue.

I just want to make sure we are talking about the same thing here...

All our Ubiquiti devices are behind a firewall/router in local subnet NAT land, ideally from my point of view and situation I would prefer all devices no matter where in the country they are or what subnet they are in, to report back to a centralised server.

As i've said, we use VPN at the moment but we can only log into single networks at a time so therefore we can only check one network at a time and no historic stats are saved, it works but not ideal.

If you live 'IN' the network its fine.
If you have enough public IP's to give each device its fine.
If you can put an AirControl server into each network its fine.

Do you see where im coming from, I hope so, if not the coloured crayons are coming out :) but thats for my benefit.

[UBNT-Thomas]

Alternatively you can use port forwarding or perhaps a permanent VLAN/VRF?

Launch Web UI requires a connection from the machine where your browser runs to the device. You need a permanently reachable address/port for each device. Currently you cannot enter HTTP IP/port for individual devices, but that will be possible in the future specifically for those folks that use this technique to manage devices through NAT without AirControl anyways.

AirControl attempts to restore connections through SSH (when the device stops reporting). Just like launch web UI, that won't work unless you forward the port at the NAT. So to "repair" a connection once it is lost you would have to still rotate your VPN connection.

Depending on how many devices you have to manage and/or their geographical distribution a single AirControl server may or may not be a good choice (bottleneck).

[gunther_01]

But something like an ALIX board with a small flash of Air Control, able to "sync" and be permanently VPN'ed back to a central air control server would be the, well, stuff ;)

For situations where the networks were scattered all over, and fed via different service providers behind NAT boxes.

[UBNT-Thomas]

A potential solution for those scenarios could also be local AirControl servers that feed aggregate data to a central instance (which would act the other way as proxy for access through its web UI). This would keep most processing and traffic local and feed summary info to the central instance, cutting down the expensive traffic.

But how reasonable is it to assume that within each of these island networks there is a machine that could host an AirControl instance?

[lncommunications]

Very reasonable if it would work on a low power ALIX board (which I have a shedload of) but I came into trouble with JRE and the 128mb RAM.

Though if a small client sync program could be developed to indeed feed back to a centralised AirControl server that would be very very useful!

Anychance you could make a module for pFsense (freebsd) :)

[sldnkarm]

Thomas,

I absolutely agree with your last post on the direction of where you plan to take the development of AirControl. I spent the afternoon troubleshooting my instance of deployment to understand why I was unable to have the device reporting back to the server (HTTP) and found that it was all to do with what you already described in this thread.

It was found that the IP of the server interface is being supplied directly to the CPE to be used with it's mca-ctrl execution (e.g. mca-ctrl -t connect -s http://x.x.x.x/heartbeat/) when in fact the external NAT'ed address was not being used. So when we were sniffing on the firewall interface we were expecting to see traffic from 9080, we never did, as it was being sent to the wrong destination. Offering a way to define the 'Console' server IP to use in each CPE would be a great help for all parties involved. That way Ubiquiti is not dictating security to their customers and everyone who is using it can fully utilize the tool.

Any workarounds to manually editing this variable on the 'Console' and not in each CPE via the mca-ctrl command would be a great help at this point, until a permanent fix can be provided in a new firmware release.

Thanks for the new tool and keep up the good work.

[UBNT-Thomas]

Very reasonable if it would work on a low power ALIX board (which I have a shedload of) but I came into trouble with JRE and the 128mb RAM.

Though if a small client sync program could be developed to indeed feed back to a centralised AirControl server that would be very very useful!

Anychance you could make a module for pFsense (freebsd) :)

We have currently no plans to develop a completely separate AirControl agent for this purpose that is specifically designed for small hardware. It would require significant amount of work and takes the backseat compared to other features that are requested for AirControl. What you are saying confirms our initial take on this - folks simply don't have large enough machines in every network to run full blown local servers. The more likely route to be taken will be one or multiple centralized AirControl servers on hardware suitable for the current stack and AirControl providing for better NAT support. The limit of devices that can be managed by each server (server capacity, network overhead) would ultimately drive the need and specifics of partitioning.

[lncommunications]

Either way is good for us Thomas, keep up the good work!

[sep78]

A local override option with the ability to enter in IP / Port on the AP gui would suffice for us I believe.

We have very distributed networks. Some APs can be reached via gre tunnels, some can be reached via nat forwarding, some can be reached by public routeables...

The AirControl server is behind a PIX being nat'd itself...
With the command I posted on the first page we have been able to get all our devices talking with AirControl.

[lncommunications]

After quite a bit of deliberation with Thomas, I now have a working solution for devices, behind a NAT firewall, to report back to a centralised AirControl server.

There are a few drawbacks at present but they are fairly minor and indicative of the way our networks are setup, so other may not encounter these problems.

I shall report back fully and hopefully make some wiki pages explaining how it is done...I just need the time!

Thanks to everyone who gave input to this thread, please by all means if you want info in the meantime PM me and ill advise.

Big thanks to Thomas for bearing with me and working with the community, it really is a breath of fresh air :D

Watch this space.

[UBNT-Ben]

lncommunications - If you can, please send your email address - ben.moore@ubnt.com

Thanks,
Ben

[swissvoip]

I read all the information about using aircontrol to manage station behind a nat port forwarded. I think this will be be a greate feature and also to have the possibility to enter station with a port number other than 22 because in my case I have 5 ubnt behind a single ex ip with port forwarded 220, 221,... to each station. I set up this one year ago when aircontrol was not existing. I have some phyton script that ssh station and grep information. I really hope to do the same with aicontrol because it look really nice. By the way is there any documentation how aircontrol take information of ubnt ?

[UBNT-Thomas]

You can use port number other than 22 already - enter it when you connect to the device with the login details.

[swissvoip]

It works fine to enter the first one than connect example to port 220. But when entering an other one that is on the same nat the aircontrol doesn't let me to add the same wan ip... example i can enter 85.5.12.5 connect to port 220 but i can not add an other one 85.5.12.5 to connect to port 221.

[UBNT-Thomas]

Are you using the latest AirControl version? This was a problem existed earlier and was fixed.

[swissvoip]

I am using v1.0.07-beta.1283 2010-01-16 14:45. Do you need any log file ? or debug trace ? I am using it on a debian server. I will install and check the windows version.

[UBNT-Thomas]

Linux server is ideal for investigation if you can give me SSH access. Send me private forum message.

[skyhigh]

Thomas,

this may be a stupid question to you but I just wanted to confirm this. can i use air control to manage customers on network ip address of 10.72.1.1/255.255.255.0 from my data center running a ip address of 10.72.0.1/255.255.255.0? the problem is that I have multiple wan lines from a isp and had to use a load balancer router at the data center which ip address is 10.72.0.1/255.255.255.0 with my computer with Air Control will be located at. All my customers are at a distance tower about 16 miles away and we have a router there that is 10.72.1.1/255.255.255.0. Before I had all my customer just get routed from the router at the data center but I had alot of customer calling me stating that their service was slow or keep dropping off. I do feel that the 16 miles link using the rocket dish is strong and working well but there is too much switching or routes the cpe have to go throught before it reach the router at the data center. so that is why i'm changing things around and add another router at the tower site. Did I do the right thing on the router issue and can I manage those two network with Air control at the data center?

Thanks,

Sky High

[UBNT-Thomas]

You certainly do the right thing if it improves the service. AirControl is not there to dictate your network setup.

Look at this here, put together by another user who seems to have a similar setup:

http://www.ubnt.com/wiki/index.php/AirControl_behind_NAT

When you read that page and this entire thread you will see that while there is no full NAT support at the moment, you can get the status reporting from other networks working with the current version (devices use HTTP to AirControl).

Only when you want to run a firmware update or have to reconnect devices, you need a route from the AirControl server to the remote devices. That can be either a temporary tunnel or some other folks use permanent port forwarding (you can override address and port in the connect dialog).

[UBNT-Thomas]

I am using v1.0.07-beta.1283 2010-01-16 14:45. Do you need any log file ? or debug trace ? I am using it on a debian server. I will install and check the windows version.
After looking at your system the issue is clear. You added one of the NATed devices manually, then successfully connected it, then deleted it. Then, when you tried to add it again, AirControl failed internally due to duplicate MAC.

I have made a few changes so that existing/deleted records with the same MAC are recovered automatically. Deployed the patch to your box, was able to add both of the units now. This will be part of the next release.

[bobcopro]

I've got what should be a simple scenario, but being new to Mikrotik I'm hoping someone can point me in the right direction. I've got a DualWAN router on 192.168.180.1 and the airControl box is on 192.168.180.4 (the whole system used to me on that address range). Now I have an old Dell running MicroTik OS (running as a hotspot) with the WAN on 192.168.180.2 and 6 NICs each on their own IP's (172.20.1.1, 172.20.2.1, etc) with each NIC handing out appropriate DHCP for each one (172.20.1.100-254, 172.20.2.100-254, etc). I leave the first 99 addresses open so I can leave the UBNT devices hardset in each range. The client computers get internet access fine.

I figure I need to punch a hole through the firewall on the MikroTik or create routes for the UBNT devices to talk with airControl and could use any help (really specific would be great) on how to go about this. The airControl box (Ubuntu 9.1) and the MikroTik box are in the same physical location.

Any help from someone more experienced with this setup?