Configure outbound-only communication

This is the standard outbound-only scenario where the OMi gateway and data processing servers are on the trusted, secure network and the RCPs and monitored nodes are on the network that is not assumed to be secure and trusted.

The figure below shows the network connections where there is a firewall that blocks inbound HTTPS connections to the gateway server as follows:

• The gateway server (1) makes an outbound connection through the firewall (2) to an RCP (3). This connection is called a reverse administration channel. The gateway server maintains the reverse administration channel, so that the RCP never needs to make an inbound connection to the gateway server.

• Agents (4) open connections to the RCP instead of the load balancer. The RCP forwards the agents' communications to the gateway server (1) using the reverse administration channel.

To configure outbound-only communication in this scenario, you must:

1. Configure the RCP, so that it listens for incoming connections. See Configure a reverse channel proxy.

2. Configure the gateway servers so that they open the reverse administration channel to the RCP. See Configure reverse administration channels.

3. Configure the agents, so that they use the RCP for their outbound connections to the gateway servers. See Forward outbound connections through a reverse channel proxy.

You can also configure outbound-only communication in environments with two firewalls. One firewall blocks inbound connections to the gateway servers. The other firewall blocks inbound connections to the agents.

Channeling RCP communication through two firewalls can serve the following scenarios:

• High security scenario. The server and agents are in trust zones with higher trust than the RCP.

• Service provider scenario. The management server runs in a service provider intranet, and the HTTPS agents are located at the customer site. From the customer’s perspective, the agents are located in a fully trusted site, but the server is not. From the service provider’s perspective, the server is located in a fully trusted site, but the agents are not.

• The gateway server (1) opens a reverse administration channel through the firewall (2) to the RCP (3). The gateway server maintains the reverse administration channel, so that the RCP never needs to make an inbound connection to the gateway server.

• Each agent (5) opens a reverse administration channel through the firewall (4) to the RCP (3). Agents maintain these connections, so that the RCP never needs to make inbound connections to the agents.

• The gateway servers (1) and agents (5) open outbound connections to the RCP (3), instead of directly to each other. The RCP forwards these communications using the reverse administration channel.

To configure outbound-only communication in this scenario, you must:

1. Configure the RCP, so that it listens for incoming connections. See Configure a reverse channel proxy.

2. Configure the gateway servers, so that they open a reverse administration channel to the RCP. See Configure reverse administration channels.

3. Configure the gateway servers, so that they use the RCP as a proxy for their outbound connections to agents. See Forward outbound connections through a reverse channel proxy.

4. Configure the agents, so that they each open a reverse administration channel to the RCP. See Configure reverse administration channels.

5. Configure the agents, so that they use the RCP for their outbound connections to the gateway servers. See Forward outbound connections through a reverse channel proxy.

In environments with multiple gateway servers and load balancers, each gateway (1) server opens a reverse administration channel through the firewall (2) to an RCP (3). The agents (4) communicate with the RCP instead of the load balancer. The load balancer serves only the UIs and other non-agent related traffic.

If a gateway server, an open reverse administration channel, or an RCP fails, the communication between the server and the agents is interrupted until the connection is established again.

To configure outbound-only communication in this scenario, you must:

1. Configure the RCP, so that it listens for incoming connections. See Configure a reverse channel proxy.

2. Configure the gateway servers so that they open the reverse administration channels to all RCPs. Configure at least two gateway servers (a primary and a backup server) to provide for the case when one gateway server fails. See Configure reverse administration channels.

3. Make sure the MANAGER setting in the sec.core.auth namespace on the HPE Operations Agent system is set to a gateway server, not to the load balancer. To check the setting, type the following command on the agent system:

   ovconfget sec.core.auth MANAGER

   To change the setting, run the following command:

   ovconfchg ‑ns sec.core.auth ‑set MANAGER <gateway server>

4. Configure the agents so that they use the RCP for their outbound connections to the gateway server. See Forward outbound connections through a reverse channel proxy.

5. Optional. Prepare the agents for a primary event receiver switch in case their dedicated gateway server fails:

   1. Create a flexible management policy and add both the primary and the backup gateway server as secondary and action-allowed servers. In the MSGTARGETRULES section, use the keyword $OPC_ALWAYS to configure the agent to always send all events to the agent's primary event receiver ($OPC_PRIMARY_MGR).

      For details, see How to switch the primary event receiver of an Agent managed by OMi.

   2. Deploy the policy to the monitored nodes.

   When one of the gateway server fails, run the following command on the other gateway server to change the primary manager for event reception of the agent:

   <OMi_HOME>/opr/bin/opr-agt <authentication> <target_nodes> -set_primary_manager <FQDN_of_backup_gateway_server>

   Example:

   <OMi_HOME>/opr/bin/opr-agt ‑username myU ‑password myPwd ‑node_list "node1.example.com,node2.example.com" -set_primary_manager newserver.example.com

   The command configures the agents on the nodes node1.example.com and node2.example.com to send data to the new primary event receiver newserver.example.com.

   For more information on opr-agt, see opr-agt Command-Line Interface.

   Note When you detect a failed connection to the gateway server, you must manually switch the agent communication from the old gateway server to the backup gateway server. Consider using health checking to monitor the availability of gateway servers. For details, see Configure health checks.

To ensure good performance, make sure that the RCP system can service incoming requests fast enough. The number of incoming requests depends on the number of agents the RCP serves:

• One RCP for one agent

  For a system hosting one RCP for one agent, meeting the minimum requirements for an agent system is sufficient. If you plan to use one RCP for each agent (located on the same system), system performance will not be significantly impacted by this single additional process.

• One RCP for more than one agent

  For a system hosting one RCP for more than one agent, meeting the minimum requirements for an agent system may not be sufficient. You must ensure that the RCP system will be able to service all incoming requests fast enough. Incoming requests are serviced on a first-come, first-served basis (FIFO queue).

  If an RCP has open reverse administration channel connections to more than one gateway server, and if communication with one of the gateway servers is interrupted, this interruption will not adversely affect communication with the other gateway servers. If the RCP gets overloaded, event throughput will drop. However, sufficient safeguards are in place to ensure that no events will be lost in transit (as long as the hard disks and file systems are functioning correctly).

  HTTPS outbound-only communication between the agent and the gateway server uses end-to-end TLS authentication. No TLS stops occur between the gateway server and the agent. As a result, no data is buffered by the RCP.

In an environment with many RCPs, the ovbbccb process on the gateway server establishes many outbound connections to these RCPs and may therefore run out of file descriptors, especially if there are also many incoming connections from monitored nodes. As a result, the agents on the monitored nodes cannot connect to ovbbccb on the gateway server and start buffering.

To avoid this problem, increase the number of file descriptors to 4096 on the gateway server:

Increase the maximum number of open files by using the limits.conf file:

tail /etc/security/limits.conf
* soft nofile 4096
* hard nofile 4096

The RCP (reverse channel proxy) is a passive element that waits for requests. It never opens any communication from its side. Its only purpose is to copy data from one TCP connection to another.

Normal HTTP proxies open a connection to the target side when a request comes in from the source side. In contrast, the RCP waits until the target side opens the channel. Otherwise, the RCP cannot copy the client side data to the target side.

The reverse channel is the connection opened by the target side to the RCP.

Assume the target side opened a reverse channel to the RCP. When a client sends a request to the RCP, then the RCP signals over the reverse channel that the target side should open a new TCP connection for the data transfer. As soon as this connection is established the RCP starts copying the payload between parties.

One TCP connection opened by the target side for administrative purposes, and n TCP connections for the clients, where n is the number of clients. In other words, there is no multiplexing of client data into one connection between RCP and the target side. Instead, every client gets its own TCP connection. In addition, there are connections going in the other direction, where the target side is in the client role.

The reverse channels are permanently open. If a firewall drops them, you can configure them to be auto-opened. All other connections are closed after a configured idle time.

The reverse channels are permanently open. If a firewall drops them, you can configure them to be auto-opened. All other connections are closed after a configured idle time.

Yes.

No.

No. Proxy chaining with RCP is not available, but you can put HTTP proxies together with an RCP to solve the issue.

An HTTP proxy can make things transparent for both the clients side and the target side, for instance with name resolution. A possible setup is:

client side > HTTP proxy 1..k > RCP < HTTP proxy k+1..1 < target side

On the target side (secure side):

Windows:

ovconfchg –ns bbc.cb –set ENABLE_REVERSE_ADMIN_CHANNELS true

ovconfchg –ns bbc.cb –set RC_CHANNELS <rcp_hostname>:9090

Linux:

ovconfchg –ns bbc.cb –set CHROOT_PATH /

ovc –kill; ovc -start

On the less-secure side (with local RCP):

ovcreg -add <install_dir>/newconfig/DataDir/conf/bbc/ovbbcrcp.xml

ovc –start ovbbcrcp

ovconfchg –ns bbc.http –set PROXY local_hostname:9090+(target_side)

On the target side (secure side):

ovbbccb -status

On the source or RCP side:

ovbbcrcp -status

bbcutil -gettarget

bbcutil -ping