Setting up the Kenna Virtual Tunnel

Installation Steps

  1. You must first contact before you are able to register your virtual tunnel VM. Direct Console access is required to configure the Virtual tunnel.
  2. Support will provision the Virtual Tunnel Connector.
  3. Support confirms the Virtual Tunnel Host Server details for you to interact with.
    • API endpoint (see Outbound Traffic Requirements section)
    • Virtual Tunnel Host URL
  4. Whitelist the endpoints that support provided to you in your firewall.
  5. Based on the Virtual Tunnel Host Server details, download the appropriate OVA file from Cisco Software Downloads
  6. Retrieve Kenna Security API Key by going to Settings --> API Keys. See screenshot below for retrieving your API key. If you need further assistance with API Keys, click here for the help article. 
  7. Using a VM tool, import the OVA file.
  8. Enter the “Kenna Security API Key”.
  9. Enter “Network Configuration”.
  10. (If necessary) Enter “Proxy Configuration”.
  11. Ask Support to confirm its access to the Virtual Tunnel.



Important: Our support department cannot convert the image into your hypervisors native image format.

Important: The virtual tunnel's operating system does not support SCSI hard drive controllers, so any attempts to launch the image with SCSI will fail. Please use the standard IDE hard drive controller to run the virtual tunnel.


Troubleshooting Steps

  1. Verify that an API key has been entered.
  2. If your VM is a static IP, please confirm that you have entered in the IP information into the VM.
  3. Verify that the correct network requirements have been put in place:  outbound TCP connections on port 443 (NOT HTTPS) and our client gateway IP and url will differ based on the hosting environment where your instance lives. Ask support for the gateway information. 

Outbound Traffic Requirements






Kenna VM

Confirm via support ticket


Web traffic used to verify your API key and pull a VPN configuration from Kenna to the VM.

A firewall rule for this must use a hostname as a destination, as its IP may change. This traffic can be sent through a standard web proxy.

Kenna VM

Confirm via support ticket


OpenVPN traffic used to bring up a VPN tunnel from the VM to Kenna's client gateway.

This traffic is not HTTPS and requires a direct outbound connection; it cannot be sent through a web proxy.


Note: When considering where to deploy the file, remember that it must be able to reach both the security appliance or server inside your network AND make outbound TCP connections on port 443 (NOT HTTPS) to our client gateway. This can be on a permanent virtualization server or on your own computer. If you run the virtual machine on your computer, it will only have access to your network when the computer is running and the VM is active.


Virtual Tunnel Frequently Asked Questions

What image is the virtual tunnel based on? Does the virtual tunnel allow access to patch and maintain the image?

  • The Virtual Tunnel is running Rocky Linux as its operating system. Kenna does not provide client access to the virtual tunnel VM and does not require client iteration other than entering the API key and local network configuration settings in the console prompts. Support will patch the VM as needed.

How does Kenna secure data in transit between the virtual tunnel and Kenna?

  • All data is transmitted to Kenna via an encrypted OpenVPN tunnel.

How are the API credentials used for the scanners secured both in transit between the virtual tunnel and Kenna, and while at rest? Where are the credentials stored?

  • The API credentials for the scanner are entered and stored in the Connectors page of the UI, not in the VM itself; they are encrypted as part of the Kenna platform solution. The Kenna API key is entered once when establishing the tunnel and transmitted data to Kenna via HTTPS to complete the initial handshake after which the tunnel is established and all future communications occur securely over the tunnel. The API key is not saved and any subsequent reboots of the VM require that the API key is re-entered. 

Since OpenVPN is used, who is responsible for keeping it up-to-date and secure?

  • Kenna security is responsible for implementing secure OpenVPN libraries as part of our distributed tunnel solution. 

Is the virtual tunnel backed up in the cloud? Can my organization create a backup?

  • The virtual tunnel VM is not backed up by Kenna as it resides within your organization's own environment. Only one instance of the virtual tunnel is supported and can be running/connected at a given time. The connector settings or authentication information is saved in the Kenna UI, not in the virtual tunnel VM so it can easily be replaced with a fresh image by following the console configuration instructions.

What happens when I need to reboot my virtual tunnel?

  • The setup prompt appears every time the VM is rebooted and requires manual configuration.  There may be options at the hypervisor level to restrict console access to the VM but the setup menu must be accessible as that this the only way the VM can be configured with the API and local network configuration information.
  • A reboot will also trigger any pending kernel patching.

How do packages get updated on the VM?

  • Packages are updated automatically every week.

Can I scan the virtual tunnel for vulnerabilities?

  • Customers can use a local service account for authenticated security scans.
  • This local service account is included with the image and can be initialized with a password by following the command prompts when running the virtual tunnel VM.

What virtual hardware version does the virtual tunnel use?

  • The virtual tunnel OVA uses virtual hardware version 13 and will run on ESXi version 6.5 and above.
Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.