Secure Communication between GigaVUE Fabric Components

The Secure Communication feature in GigaVUE-FM enhances security by enabling mutual Transport Layer Security (mTLS)-based authentication across GigaVUE Fabric Components. With this feature, each fabric component is assigned a properly signed certificate from a Certificate Authority (CA), ensuring authenticated, encrypted communication without relying on static credentials.

In the above diagram, GigaVUE-FM establishes an mTLS connection and checks for GigaVUE V Series Proxy availability. If GigaVUE V Series Proxy is unavailable, it directly connects to the GigaVUE V Series Node through mTLS. If a GigaVUE V Series Proxy is available, then GigaVUE-FM first connects to the GigaVUE V Series Proxy, which then establishes an mTLS connection with the GigaVUE V Series Node. Separately, GigaVUE-FM also initiates an mTLS connection to the UCT-V Controller, which then establishes an mTLS connection with UCT-V. This structured flow ensures secure communication using mTLS-based authentication across all the fabric components.

GigaVUE-FM manages certificates by acting as the Public Key Infrastructure (PKI), ensuring a centralized and secure approach to certificate management.

GigaVUE-FM acts as the PKI

GigaVUE-FM acts as a private PKI, automatically issuing and managing certificates for all fabric components. GigaVUE-FM uses Step-CA to handle certificate issuance and renewal using the Automatic Certificate Management Environment (ACME) protocol in this method. This eliminates the need for external dependencies while ensuring secure, automated certificate management.

Bring Your Own CA

Organizations with existing PKI infrastructure can import externally issued certificates into GigaVUE-FM. This method supports enterprise CA solutions while allowing seamless integration with Gigamon’s secure communication framework.

For more details on how to integrate your PKI infrastructure with GigaVUE-FM, refer to Integrate Private CAIntegrate Private CAIntegrate Private CAIntegrate Private CAIntegrate Private CAIntegrate Private CAIntegrate Private CA

Secure Communication in FMHA Mode

In an FMHA cluster, the active instance synchronizes intermediate CA files across all standby instances and supporting instances to maintain consistency. Certificate requests are primarily managed by the active instance, but in the event of a failover, a standby node takes over this role. Both the root CA and intermediate CA are copied to standby instances, ensuring that even if the active instance is completely shut down, standalone instances can still manage the certificates.

Regardless of whether the fabric components are deployed through GigaVUE-FM or a third-party orchestration method, GigaVUE-FM provides the active instance’s CA details to all fabric components. If an instance is removed from the cluster, the CA service restarts on the removed instance with a new self-signed CA.

For more details on how to configure secure communication in FMHA mode, refer to Configure Secure Communication between Fabric Components in FMHA Configure Secure Communication between Fabric Components in FMHA.

Supported Platforms

  • AWS
  • Azure
  • OpenStack
  • Nutanix
  • Third Party Orchestration
  • VMware ESXi
  • VMware NSX-T

Supported Components

  • GigaVUE V Series Node
  • GigaVUE V Series Proxy
  • UCT-V
  • UCT-V Controller

Rules and Notes

  • For public cloud platforms, if the public IP is revoked, you can issue a new certificate from GigaVUE-FM to remove the public IP from the certificate.

    Note:  This is an optional configuration.

  • When GigaVUE-FM and GigaVUE Fabric Components are deployed on different hosts, ensure that the hosts are time-synchronized with NTP configured and running.
  • When applying the certificates, the GigaVUE Fabric Components may move to a Down state and automatically recover.
  • When using GigaVUE V Series Proxy, disable the Source/Destination Check feature on its network interfaces in AWS. Enabling this feature prevents packet forwarding if the source or destination IP in the packet does not belong to the interface.