Opsview Monitor can be configured to route all connections to/from the Opsview Collectors via SSH tunnels. This is especially useful when the Collectors are behind restrictive firewalls.

It is possible to use forward and reverse tunnels on your system. A forward tunnel is made from the Orchestrator to a Collector, whereas a reverse tunnel is made from the Collector to the Orchestrator.

## Forward tunnels

Forward tunnels are made from the Orchestrator to a Collector.

### How to set up a Collector with a forward tunnel

These instructions describe the process for setting up a new Collector, `de_collector_01` which communicates with an existing Orchestrator, `orchestrator` through an SSH tunnel originating from `orchestrator`.

When using the example commands, you should replace the variables to suit your environment. Below are two tables showing the details of our example hosts (`de_collector_01` and `orchestrator`) that you need to substitute.

**Orchestrator**

**Collector**

📘

Local users require full root access

The local users for your Orchestrator and Collector must have full root access. You may use the default root user as this local user.

**Making an SSH connection** **1.** Generate an SSH key on the Orchestrator as `orchestrator_user` (do not set a password): --- Check in the ~/.ssh/ directory of the user you are wishing to use and if a SSH key pair already exists, you may use this and skip to the next step

**2.** Copy the public key you just generated to `collector_user` on the Collector:

**3.** Test the connection of your Orchestrator to your Collector:

You should be able to log in without any password prompts or errors.

**Deploy the Collector** **1.** Edit `/opt/opsview/deploy/etc/opsview_deploy.yml` to include a new section within `collector_clusters` like the below example:

**2.** Edit `/opt/opsview/deploy/etc/user_vars.yml` and add the below:

🚧

If you are using NATed IP addresses...

Follow the additional steps at the bottom of this page.

**3.** Run the setup-everything and setup-monitoring playbooks on your Orchestrator:

*** If you are deploying one new collector use the -l (l for lima) against the individual collector and then run the ssh-tunnels against the orchestrator

If you are adding the collector into a cluster, please look at the steps on [Managing Collectors and Clusters](🔗) page .

## Reverse tunnels

Reverse tunnels are made from a Collector to the Orchestrator. You may want to use a Collector with a reverse tunnel if your Collector is behind a restrictive firewall and your Orchestrator is in a different location.

### How to set up a Collector with a reverse tunnel

These instructions describe the process for setting up a new Collector, `fr_collector_01` which communicates with an existing Orchestrator, `orchestrator` through an SSH tunnel originating from `fr_collector_01`.

You will need to open two terminal windows: one with access to your Orchestrator and the other with access to the Collector.

When using the example commands, you should replace the variables to suit your environment. Below are two tables showing the details of our example hosts (`fr_collector_01` and `orchestrator`) that you need to substitute.

**Orchestrator**

**Collector**

📘

Local users require full root access

The local users for your Orchestrator and Collector must have full root access. You may use the default root user as this local user.

**Making an SSH connection** **1.** Generate an SSH key on the Collector as `collector_user` (do not set a password):

**2.** Copy the public key you just generated to `orchestrator_user` on the Orchestrator:

**3.** Generate an SSH key on the Orchestrator as `orchestrator_user` (do not set a password): --- Check in the ~/.ssh/ directory of the user you are wishing to use and if a SSH key pair already exists, you may use this and skip to the next step

**4.** Copy the public key you just generated to `collector_user` on the Collector:

**5.** Identify an unused port on the orchestrator to test the SSH connection. We use port 9022 in this example. **6.** Open a test reverse SSH tunnel from your Collector to your Orchestrator:

You should be able to log in without any password prompts or errors. Do not close this session yet! **7.** Test the connection of your Orchestrator to the Collector now that the reverse tunnel is open: --- If you receive any password prompts here, you will need to revisit the SSH key steps

You should be able to log in without any password prompts or errors.

**Preparing the Orchestrator** The following steps must be performed on your Orchestrator while the test tunnel from the Collector is open. **1.** Edit `/opt/opsview/deploy/etc/opsview_deploy.yml` to include a new section within `collector_clusters` like the below example:

📘

opsview_deploy.yml

More information on correct formatting and syntax for this file can be found in [Managing Clusters and Collectors](🔗).

**2.** Edit the SSH config file (`/home/orchestrator_user/.ssh/config`) for `orchestrator_user` to include an entry like the below. If you are using the `root` user, edit `/root/.ssh/config` instead.

**3.** Edit `/opt/opsview/deploy/etc/user_vars.yml` and add the below:

**Deploy the Collector** **1.** Run the setup-everything playbook on your Orchestrator:

**2.** Close the test SSH tunnel from your Collector to your Orchestrator. **3.** Restart all Opsview components on the Collector.

**4.** Run the setup-monitoring playbook on your Orchestrator.

You should now be able to register your new collector in the UI as described in [Managing Clusters and Collectors](🔗).

## Additional steps for NATed IP addresses

### Forward tunnels

**1.** Edit the SSH config file (`/home/orchestrator_user/.ssh/config`) for `orchestrator_user` on `orchestrator` to include an entry like the below:

**2.** Edit the newly added section in `/opt/opsview/deploy/etc/opsview_deploy.yml` to mirror the below example: