How Witina works for an MSP

Witina has two parts. The Witina cloud is where you and your team work, in the browser. Gateways are small virtual machines you run inside the networks you manage. This page explains both, and the ideas you’ll use to organize your customers: regions, divisions, customers, and contexts.

The cloud and your gateways

The cloud is where you see and manage your networks: maps, device details, alerts and incidents, change management, and your customers dashboard. It stores what gateways report about the network. It doesn’t store your device passwords.

A gateway does the work that has to happen inside a network. It discovers devices, polls them, holds the credentials that log in to them, and carries out the changes and remote sessions you start from the browser. It also carries your technicians’ VPN sessions into the network.

A gateway connects out to Witina over HTTPS (port 443). Commands from the cloud come back down that same connection, so nothing on the internet needs to reach the gateway, and you don’t forward any ports to it.

You can run a gateway as:

A virtual machine: an OVA for VMware, VirtualBox and other hypervisors, or a one-line PowerShell install for Hyper-V.
An ISO, for a bare-metal appliance or a manual VM install.
A container, under Docker, Docker Compose, or Kubernetes.

All three are under Gateways → Add gateway.

How a gateway learns about a network

Polling devices over SNMP.
Logging in over SSH or Telnet, or through a device’s web interface or API, to read configuration and run the operations you ask for.
Asking a controller that manages the devices. Today that’s UniFi: Witina reads UniFi networks through the UniFi console.
Listening to what the network already sends: LLDP and CDP announcements between neighbors, ARP and IPv6 neighbor discovery, and DHCP. This finds devices and the links between them without scanning.

Witina supports modern Arista and Juniper devices, and UniFi networks through the UniFi console. Other devices that answer SNMP are discovered and monitored too; how much more Witina can do with them depends on the vendor and model.

More than one gateway

A region (see below) can have several gateways. Witina spreads the region’s devices across the gateways that are online, and each device is polled by one gateway at a time. If a gateway goes offline, its devices and controllers move to the others in the region within a few minutes. A gateway added to a region later receives that region’s credentials automatically, so it can take over without you re-entering anything.

Regions

A region is a part of a network where every IP address means exactly one thing, and where the region’s gateways can reach its devices. Everything in Witina that depends on reaching something belongs to a region:

Gateways. Each gateway belongs to one region, chosen when you install it.
Devices. Each device belongs to one region and is polled by that region’s gateways.
Credentials. Each credential belongs to a region and is sent only to that region’s gateways.
Controllers, such as a UniFi console, are polled by their region’s gateways.
Maps and segments are drawn per region.

Witina only compares addresses within a region. Two customers can both use 192.168.1.0/24, and both have a switch at 192.168.1.2, without either being mistaken for the other.

Any gateway in a region may be handed any device in that region, so every gateway in a region must be able to reach every device in it. Two offices joined by a VPN, where a gateway in one office can reach devices in the other, can be one region. Two offices with no route between them need a region each.

For an MSP, the usual layout is one region per customer, with a gateway on that customer’s network, plus a region for your own network. When you onboard a customer, Witina creates their first region for you. Regions are listed under Organization Admin → Regions.

Why “region”?

A region is usually either a physical location, such as an office or a campus, or a logical chunk of a network, such as one customer’s routed estate. What defines it is addressing and reachability, not geography: if two places share one routed network and your gateways can reach across it, they can be one region.

Divisions and customers

A division is a part of your organization: a department, a business unit, or, for an MSP, a client. Regions, gateways, and devices can belong to a division, and so can the people allowed to see them. A region that doesn’t belong to a division belongs to the whole organization; the Regions list shows its owner as “Organization”.

A customer is a division you’ve marked as a customer. To use customers, turn on MSP mode under Organization Admin → General. A Customers section then appears in the navigation, with a Dashboard across all your customers and a page for each one.

Customers → All customers → Onboard new customer sets up a customer in one step. It creates:

a division for the customer
a region named “Customer Region”
a context named “Customer Admin”, with an Administrators team that holds the Administrator role in it
a gateway provisioning token for that region, valid for 30 days
if you ask for one, an invitation for the customer’s own administrator, valid for 7 days

If you already have divisions, Add existing division marks them as customers without creating anything else.

Lifecycle, tier, and notes

Each customer has a lifecycle (prospect, onboarding, active, suspended, or offboarded), and optionally a tier and an account manager. These are for your own records. Changing a customer’s lifecycle doesn’t stop monitoring, pause devices, or change billing. The one effect: a prospect or offboarded customer with nothing set up yet isn’t flagged as needing attention.

Each customer also has notes, a free-form Markdown page for contacts, maintenance windows, and links to your ticketing system and documentation.

Customer health

Each customer is shown as healthy, warning, or critical: the worst result from a set of checks covering unreachable devices, gateways that are offline or have never connected, regions with no gateway, failing collection, and open incidents.

UniFi Site Manager

If your customers run UniFi, Witina can read your UniFi Site Manager account and list every console and site you manage:

Connect Site Manager in your own region, not a customer’s, using your Site Manager API key. Only gateways in that region receive the key. Witina warns you if you pick a customer’s region.
Witina lists every site it finds. For each one, choose the region it belongs to (that customer’s region), and adopt it.
Adopting creates a UniFi controller in the customer’s region. A gateway in that region polls the console, either through UniFi’s cloud (recommended; it uses a Site Manager key limited to that one console) or directly on the console’s network (it uses an API key created on the console, and the gateway must be able to reach it).

A customer’s UniFi site is polled by a gateway in the customer’s region, so each customer region needs at least one gateway. Until one is online, an adopted site waits.

Run that gateway on the customer’s network. Going through UniFi’s cloud means the gateway doesn’t strictly need a path to the console, but a gateway on the customer’s network can also poll devices directly over SNMP, open terminal and web sessions to them, and hear the LLDP and DHCP traffic Witina uses to find devices and spot rogue DHCP servers. A gateway elsewhere can do none of that.

People and access

People get access through teams. A team holds a role, such as Administrator, in a context. A context covers either your whole organization or one division, so a team whose role is in “Acme Admin” works only with Acme’s regions, gateways, and devices. The Switch to this customer action on a customer’s page changes which context you’re working in.

Users are under Organization Admin → Users, and contexts, teams, and roles under the Permissions pages of Organization Admin. See Give your team and your customers access.

Plans

Plans count four things: devices, gateways, users, and regions. See MSP pricing.