Setting up the Kenna Virtual Tunnel

Installation Steps

Important: You must first contact before you are able to register your virtual tunnel VM. Direct Console access is required to configure the Virtual tunnel. 

  1. Provide Support with the following information to create the required VM image.

    • The IP address where you would like the VM to be set.

    • Gateway

    • Subnet mask

    • DNS

  2. Support creates the VM image based on the above provided information.

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. Important: 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

  1. 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 CentOS 8 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.

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

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

  3. 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. 

  4. 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. 

  5. 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.

  6. 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.

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Please sign in to leave a comment.