1. Home
  2. OmniCenter Reference
  3. OmniCenter Overview Product

OmniCenter Overview Product

With OmniCenter Overview distributed monitoring, individual OmniCenter appliances are deployed in networks which are closer to the devices and applications being polled. Very large global customers can deploy OmniCenters at regional hubs, eliminating the need to directly backhaul all polling traffic all the way to the core, and MSPs can deploy OmniCenters directly into actual customer networks. Networking issues are simplified due to the embedded TLS-based VPN architecture built automatically by OmniCenter. While at the core facility, the user interfaces of all client OmniCenters are aggregated into a single screen on the Overview.

Overview Cloud Libraries

The OmniCenter Overview libraries function in an identical way to the Netreo cloud libraries, except with the Overview acting as the repository for up- and downloads to and from its client OmniCenters. The Overview itself, however, is still able to connect normally to the Netreo cloud libraries. This allows the Overview to download modules from the Netreo cloud and then control distribution of those modules to its clients. Similar the Netreo cloud library operations, client OmniCenters can upload modules to the Overview libraries for redistribution to other clients. But, unlike the Netreo cloud, the approval process for modules uploaded to an Overview library is completely under the control of the Overview administrator.

Although client OmniCenters connected to an Overview may upload modules to their Overview’s libraries, they may not upload modules to the Netreo cloud libraries. Only the Overview itself may upload to the Netreo cloud.

Addressing

This information covers the architecture of the OmniCenter Overview product and how addressing and authentication work over the VPN tunnels. This information is important for setting up Overview.

OmniCenter Overview lives at your IT headquarters location, typically a managed service provider. VPN tunnels connect different remote OmniCenter clients to the Overview. These remote OmniCenter clients will also be connected to their own client networks. When Overview connects to client OmniCenters, the VPN can multiplex created SSL tunnels on a single TCP/UDP port.

In this architecture, it’s ok for the different client networks to overlap address spaces. In this case, the overlap of the various client networks doesn’t matter because the devices being managed in each network only need to be able to get to their local OmniCenter. The address spaces can even overlap the Overview local network address space, because all of these individual networks will be kept separate and isolated from each other by the VPN Subnet, as explained in the definitions below.

Let’s define some important terms to know when setting up an Overview.

Local Network – For the purposes of discussing an Overview setup, the “Local Network” is the local network that the Overview is on. The address space of the Local Network is permitted to overlap with “Client Networks” (see below).

Client Network – The “Client Network” is the local network that a client OmniCenter is on. The address spaces of Client Networks are permitted to overlap with each other and with the Local Network.

Local IP – The IP address of the Overview on the Local Network. That is, the IP address that Local Network users will use to get to the web interface of the Overview. This is not equivalent to the “Client IP” listed further down.

Public Overview IP – The IP address of the Overview as seen from outside the Local Network. This address must be mapped (port forwarded) to the Local IP. This is the address that client OmniCenters will try to open a tunnel to.

VPN Subnet – This is the network that facilitates private communication between the Overview and its client OmniCenters. It must be defined during the initial Overview installation and configured by your Netreo engineer. The VPN Subnet must have its own unique subnet address that does not overlap address space with either the Local Network or any of the Client Networks. (This is very important. If a Client Network used the same address space as the VPN Subnet, and a device on that network had the same local address as the Overview, it would be unable to find the Overview to reply to requests.) This subnet must be routable from the Local Network. That is, the gateway for the Local Network must have a static route to the VPN Subnet using the Local IP as the next hop.

Tunnel Interface – This is the virtual interface between an OmniCenter (Overview or client) and the VPN Subnet. The IP address of the tunnel interface is how the Overview and client OmniCenters are identified within the subnet. The tunnel interface for the Overview is always .1 on the VPN Subnet.

Client IP – The IP address of the tunnel interface of a client OmniCenter within the VPN Subnet. Each connecting OmniCenter client is given its own unique IP address within that subnet.

This image shows the “logical” (as opposed to physical) network connections of an OmniCenter Overview installation. Note that the IP address of the Overview’s local network conflicts with that of two of the client networks. This is not a problem due to the use of the VPN tunnel interface addressing scheme and the fact that Overview translates its traffic to appear as though it originates from the VPN.

When correctly set up, the Overview becomes a router (ip_forward = 1), forwarding traffic from the Local Network onto the Client Networks through the tunnel connections. It will have special rules in the IP routing tables to allow this to happen, and to restrict the traffic that’s allowed to go over the tunnels. By default, the only traffic allowed over the Overview tunnels is SNMP, SSH and web traffic.

When an Overview user wants to connect to a client OmniCenter, they will click on a link in the Overview web interface that points to a client address. This connection is usually done by name, meaning that the DNS server has to have an entry that says IP address xx.xx.xx.xx = client1.customer.local (or whatever the name is). The name doesn’t have to be a valid domain, but it does have to be one that your DNS server will resolve. The DNS server must have entries for each of the Overview clients.

When a user clicks a client link that says https://client1.customer.local the browser will try to get to IP address xx.xx.xx.xx, which is why the VPN Subnet needs to be routable. The default gateway (router) for the Local Network has to have a route that goes to the VPN Subnet through the Local IP. A request to get to the web interface of a client OmniCenter goes through the local gateway—which points to the Local IP of the Overview as the next hop—then gets routed through the Overview to the correct Client IP on the VPN Subnet which connects to the client OmniCenter.

Using a special rule in iptables, Overview translates the traffic that comes through it to look as though it’s originating from its tunnel interface IP. And, since the Overview effectively has direct access to a client OmniCenter through its tunnel interface (and will never need to directly access any devices on that client’s local network), local network address conflicts are irrelevant—as long as the VPN Subnet is unique among the subnets involved. This is why it’s okay for the Overview and client networks to have overlapping local address spaces.

Authentication

When an Overview user clicks on a link to connect to a client OmniCenter, they will still have to log in to that client OmniCenter separately—unless pass-through authentication has been configured in Overview. To do this, in the Overview system preferences (Administration → System → Preferences) the “Authentication Domain” field must be set to the domain of the client OmniCenters (in the example above customer.local). The same setting in the client OmniCenter must also be set to that domain. The reason for this is because authentication uses cookies. Cookies live in your specific browser—and browsers will not send cookies to an address outside of the domain that gave them the cookie. This means that the Overview Local IP must also be listed in DNS with the same domain name as the client OmniCenters that you want to reach.

With pass-through authentication properly set up, when Overview issues a cookie to a local user trying to get to a specific client, it will tie that cookie to the domain name that the particular client is on. When the Overview user’s browser hands that cookie to the client OmniCenter, the client says, “Ok, you’re from the same domain as me, come on in.” Then the user doesn’t need to log in to the client OmniCenter separately. But, this feature relies exclusively on DNS entries being set up correctly for each client and the Overview. It will not work through IP addresses alone. If DNS is not setup for this, everything else for the Overview will still work, but pass-through authentication will not work. So, the Overview user will have to log in to each of the clients separately—every time.

It’s recommended that customers create a separate domain to use with their Overview and client OmniCenters, if practical, for safety and simplicity’s sake—and to get pass-through authentication to work.

Since the Overview also functions as a router, if DNS is properly set up, you can also simply type the client URL into a browser on the Local Network and be taken directly to an OmniCenter web interface on a Client Network. If pass-through authentication is correctly set up, you will not be required to log in.

The web interface in Overview allows you to configure two types of information:

Information about the tunnel destination (what port and protocol it will use). This must match the tunnel definition specified during initial setup. The default port for the tunnel is UDP 1194. Please note that if you wish to use TCP/443 for the VPN, you will need multiple IP addresses for the Overview. This is because in order to log in to the web interface for an Overview using SSL, only one program can own port 443. It will either be the Overview VPN or the web server, it can’t be both. So, if you wanted users to attach using 443, Tunnel traffic would have to come into 443 on one IP address, and local web traffic would have to come into 443 on a different IP address.

Entries for each of the OmniCenter clients, including the statically assigned address in the VPN Subnet. Once a client’s information is provided, Overview will produce a GPG encrypted “blob” of data called a “configuration key.” This key is then further digitally signed and encrypted so that only an OmniCenter can open it to decrypt it. The configuration key can then be copy/pasted into the settings of the respective client OmniCenter. The blob of data in the key contains everything the client OmniCenter needs to open a VPN tunnel back to the Overview (keys, certificates, IP addresses, passwords, etc.). The VPN tunnel is always established from the client side to the Overview side—without exception.

One of the configuration fields you will see in the web UI for the Overview when you set up the tunnel addresses is a field called the “Public Overview IP.” Since the Local IP is not routable, and the tunnels are actually running over the Internet, it means that the Local Network firewall has to be set up to allow traffic in on whatever ports you’ve decided (UDP 1194, typically), and then translate (map) it from a public address to the Local IP assigned to Overview (just like any web server in a network).

The Public Overview IP is the IP address that the client OmniCenters are going to try to open tunnels to, and is included in the configuration key data blob. Any given client OmniCenter will actually be going out its own firewall to the Internet in order to open a tunnel, so the physical path is client <–> firewall <–> Internet <–> firewall <–> Overview; even though the logical path appears to be a direct connection between the Overview and each client. To establish a tunnel, a client OmniCenter needs a public IP to connect to over the internet—which is then mapped to the Local IP to reach the Overview. It’s important to note that if any of the firewalls are “application aware,” you must specify that the tunnel traffic is VPN, and not SSL or web browsing. Otherwise, the firewall may become suspicious and block the traffic.

If you want to use your own VPN instead of the default tunnels, you can. But, each OmniCenter client will need to be manually configured. The built-in automatic connection of a client OmniCenter to an Overview can only be done using the VPN application provided by OmniCenter.

When Overview and a client OmniCenter begin communicating, they’re passing information back and forth using a password called an “API key.” This is a one time password that is unique to each client. Each client gets its password from the encrypted configuration key blob.

By default, when a client OmniCenter opens a tunnel to the Overview, it will also try to open a separate tunnel to Netreo. If you want to disable the Netreo VPN, but leave the Overview VPN intact, you can use the option in the System Diagnostics page to disable this by selecting “Overview tunnel only.”

Certificate Process

The certificate exchange process for Overview is the standard OpenVPN process, and uses a very standard two-way SSL connection.

Everything in Overview’s VPN is either a client, a server, or both. Overview is both. It’s a server to the Overview VPN network interface, but it’s a client to the Netreo VPN network interface (Overview also creates its own tunnel connection to Netreo), if you enable that option.

Client OmniCenters connect to Overview servers, never the other way around. So the remote client OmniCenters will attempt to attach to the Overview. To do that they will open a connection on whatever port and protocol you have specified in the configuration key settings. UDP 1194 is the default protocol and port.

When an OmniCenter client connects to an Overview server, it tries to open a connection on the specified port. The first thing a client OmniCenter must do when attempting to make a connection to the Overview is to present a “TLS key,” which is a 2048-bit password that is generated randomly when you first set up the Overview. Every Overview generates its own specific password, which is given to the client as part of the configuration key data blob. This password is static and is a shared secret between the server and its clients. No client can ever successfully make a connection to any other Overview, because no other Overview would have the same password (and thus, would not allow a connection).

If the client and server passwords match, the client will be allowed to connect. Once a connection is established, the client then needs to present a certificate in order to create a VPN tunnel (just like any other TLS connection). The server (in this case the Overview) is the certificate authority. The certificate authority signs a certificate given to both the server and the client (again, as part of the configuration key data blob).

When the client presents its certificate to the server (Overview), the Overview checks to see if it is the authority that signed that particular certificate to begin with. If it is, the server then presents its certificate to the client, who will then check to make sure that the server’s certificate was signed by the same authority as its own certificate. If it is, then the two can communicate. If it is not, then the tunnel will not be created. This prevents a client from ever connecting to another Overview by accident, or trying to connect to another client. If communication is allowed, all further communication across the tunnel is then encrypted with 128-bit AES encryption.

So, to summarize: First a connection must be established between a client and the server using the TLS key. Then, after 2-way certificate validation, a VPN tunnel is created so the two can communicate securely.

Updated on July 29, 2019

Was this article helpful?

Need Support?
Can’t find the answer you’re looking for? Don’t worry we’re here to help!
Contact Support

Leave a Reply