Skip to main content
Welcome to Virtru's support portal. As we work to make this page more accessible to screen readers, please contact us at support@virtru.com for technical support.

Virtru Private Keystore (for Virtru Solutions): Reference - Firewall

  • Updated

To minimize exposure and maximize security for the Virtru Private Keystore (for Virtru Solutions) appliance Virtru will only send traffic to the Virtru Private Keystore from specific IP addresses.

Action Required: New Virtru IP Addresses

We're expanding the IP addresses the Virtru Private Keystore uses to support growing usage and improve the resilience of our infrastructure. If your organization allowlists Virtru's IP addresses, add the following addresses before Monday, October 26, 2026 to avoid any disruption to your Virtru Private Keystore. If you don't maintain an IP allowlist for Virtru, no action is required.

Primary IP addresses (going live together):

  • TCP
    • 34.173.130.111 (currently active)
    • 34.71.154.120
    • 34.59.3.196
  • Port
    • Defined by client
    • Default 443

Failover IP addresses:

  • TCP
    • 34.145.120.255
    • 136.66.26.169
    • 34.169.5.97
  • Port
    • Defined by client
    • Default 443

We recommend adding all six addresses now so you're covered as the rollout progresses. 

The complete list of required IP addresses is in the Traffic Requirements section below.

Traffic Requirements

Ingress:

Inbound to the Virtru Private Keystore from Virtru SaaS for normal decrypt operations:

  • TCP
    • 52.14.8.108
    • 18.216.244.36
    • 13.59.117.136
    • 34.173.130.111
    • 34.71.154.120
    • 34.59.3.196
    • 34.145.120.255
    • 136.66.26.169
    • 34.169.5.97
  • Port
    • Defined by client
    • Default 443

Older Virtru IP addresses that no longer appear in this list are no longer in use and may be safely removed from your allowlist.

Inbound to the Virtru Private Keystore from Virtru IPs for setup, testing, and health monitoring:

  • TCP
    • 104.30.163.207
    • 104.30.177.28
  • Port
    • Defined by client
    • Default 443

Remote access to the server for SSH (for configuration and setup)

  • TCP
    • <Your Company IPs>
  • Port
    • Default 22

Egress:

Outbound from the Virtru Private Keystore to the Virtru SaaS environment. 

 

Port Configuration

All traffic from Virtru to your infrastructure will arrive on port 443. If using a different destination port, apply an internal translation on your edge firewall to direct incoming traffic from port 443 to your specified <defined port> for the VPK server.

To update the port for the VPK container, modify the run.sh script’s -p flag:

  • Original: -p 443:9000
  • Updated: -p <defined port>:9000

Replace <defined port> with the desired port number.

Example docker run command for the Virtru container

docker run \
  --name Virtru_CKS \
  --interactive --tty --detach \
  --env-file /var/virtru/cks/env/cks.env \
  -v /var/virtru/cks/keys/:/app/keys \
  -v /var/virtru/cks/ssl/:/app/ssl \
  -p <defined port>:9000 \
  --restart unless-stopped \
  containers.virtru.com/cks:<latestCKSVersion>

Note

Virtru does NOT require SSH access to any host, this is only a reference for industry best practices.

 

Load Balancer TLS Configuration

If you deploy the Virtru Private Keystore behind a load balancer (LB), the LB must re-encrypt traffic to the Virtru Private Keystore nodes using a standard, modern TLS profile. The Virtru Private Keystore terminates TLS on each node and will reject handshakes that offer only legacy or weak cipher suites. 

Note that this applies to the server-side TLS profile — the one governing the connection between the LB and the Virtru Private Keystore node — not the client-facing profile that handles inbound connections to the load balancer's virtual server. 

Use your LB's default or standard server-side TLS profile. Avoid legacy or "compatibility mode" profiles: despite names implying broader interoperability, these typically enable an older cipher list the Virtru Private Keystore does not accept, and applying one results in SSL handshake failures between the LB and the node(s). 

These failures commonly surface immediately after a Virtru Private Keystore version upgrade, when a newer build tightens its accepted cipher suites and a previously working legacy profile stops negotiating. If you run multiple keystore nodes behind the load balancer, apply the same server-side TLS profile to every pool member, and disable a node in the pool before upgrading it so traffic drains cleanly to the remaining node.

Related articles