Hi there! It’s been a while. How are you doing? In the last release of vRealize Network Insight, version 6.3, there’s a new feature called Secure Cluster Communication. By default, the communication between Platform and Collectors is encrypted via TLS. A Platform cluster, has a few data replication services (FoundationDB, Kafka,  running between them – which are not all encrypted by default. The Secure Cluster Communication feature allows you to set up VPN tunnels between the Platform nodes and encrypt all traffic going between them. 

It’s not recommended to split Platform nodes between different locations. But, if you do have Platforms living in separate networks or locations, or if you simply can’t trust your management network, you can now make sure the traffic can’t be snooped upon.

Secure Communication Cluster in vRealize Network Insight

Requirements

You’ll need version 6.3, and a free internal IP subnet. The subnet will be used for internal IP addressing on the Platform nodes and will not be exposed to the outside network interfaces. But, you’d still want to use a range that’s not used, because the Platform will use it locally. If you have users or services like SMTP, or SNMP, on the same subnet, they won’t be able to connect to the Platforms. By default, vRNI will use 192.168.10.0/24.

Configuring Secure Cluster Communication

Configuring the secure communication is possible via the consoleuser command-line. It’s a slightly disruptive operation, with the cluster services needing a restart to start using the VPN tunnels. It’ll also take 10-15 minutes of runtime. You only need to run this on the Platform 1 node in the cluster: it will reach out to the other Platform nodes on its own. 

Start by launching the console of the Platform 1 node. Because it takes a while, you don’t want to chance getting disconnected from a SSH session. Then log in with the consoleuser and run the secure-tunnel command.

The secure-tunnel command only takes a few parameters:

Really straight-forward: show the current status by providing –status, enable it with –enable and disable it with –disable. The -sub parameter can be used to provide a custom IP subnet, if you don’t want to use the default 192.168.10.0/24.

Running secure-tunnel

Here’s an example of how to run the secure-tunnel command. I’m providing a custom IP subnet (172.16.9.0/24) that’s used for the IP connectivity over the VPN tunnels.

Running the secure-tunnel command

Validation

If you check any of the Platform nodes after the setup process, they’ll tell you the secure tunnels are enabled:

If you sniff any of the traffic going between the Platform nodes, all you will see is this:

Good luck decyphering that. 😉 



Share the wealth!