Table of Contents
Logging Container Detail
Getting Started with VNS3 Container System
The following Logging Container functionality is deployed to VNS3 as a plugin using the container system. These instructions cover customization of a Cohesive Networks supplied Ubuntu-based container image. While you can use any source Linux LXC container image or Docker file you wish, unless you are very experienced with Docker, Cohesive Networks recommends starting with our default container (details in next section).
Getting the Default VNS3_Base Container
The default Linux (Ubuntu 20.04) Container is accessible at the following URL:
This is a read-only Amazon S3 storage location. Only Cohesive Networks can update or modify files stored in this location.
This URL can be used directly in a VNS3 Controller via the Web UI or API to import the container for use into that controller. (General screenshot walkthrough and help available in the Container System Overview document.)
(For older base OS needs, the following images remain available but are not being actively updated or maintained.)
Uploading the Container Image to the VNS3 Controller
From the Container —> Images menu item, choose Upload Image.
The name can be upper, lower, or mixed case. This is required to provide any allocated container from this image to mount the appropriate VNS3 system log files.
To use the pre-configured container paste the URL into the Image File URL box.
Getting the VNS3_Base Container
When the Image has imported it will say Ready in the Status Column.
To then launch a running VNS3_Base container, choose Allocate from the Action menu.
Launching a VNS3_Base Container
After selecting Allocate from the Actions menu you then name your container, provide a description and the command used to execute the container.
The name and description should be something meaningful within the context of your organization and its policies.
In the cases of using the CN Base Container Image, use the command:
/usr/bin/supervisord. This will ensure the ssh daemon is started so you can access the allocated container.
Confirming the VNS3_Base Container is Running
After executing the Allocate operation you will be taken to the Container Display page.
You should see your VNS3_Base Container with the name you specified.
The Status should be Running and it should have been given an IP address on your internal container subnet (in this case
Accessing and Securing the Logging Container
Accessing the Logging Container
Accessing a Container from the Public Internet or your internal subnets will require additions to the inbound hypervisor firewall rules with the VNS3 Controller as well as VNS3 Firewall.
The following example shows how to access an SSH server running as a Container listening on port 22.
Network Firewall/Security Group Rule
Allow port 22 from your source IP or subnets.
Enter rules to port forward incoming traffic to the Container Network and Masquerade outgoing traffic off the VNS3 Controller’s outer network interface.
#Let the Container Subnet Access the Internet Via the VNS3 Controller’s Outer or Public IP
MACRO_CUST -o eth0 -s <VNS3_Base Container Network IP> -j MASQUERADE
#Port forward port 44 to the Container port 22
PREROUTING_CUST -i eth0 -p tcp -s 0.0.0.0/0 --dport 44 -j DNAT --to <VNS3_Base Container Network IP>:22
#Copy all incoming tun0 (Overlay Network) traffic to the TCP Tools Container
Macro_CUST -j COPY --from tun0 --to 126.96.36.199 --inbound
Securing the VNS3_Base container
By default the container has the following accounts, configured as described.
“root” - The root account is locked. The root account is not allowed to remote shell into the container. This is our recommended approach. However, if you wish to, you can use the “container_admin” account to unlock root, provide a root password, and edit /etc/ssh/sshd_config to allow remote login by root.
“container_admin” - The default password is
container_admin_123! The default demo public key is also installed in the
/home/container_admin/.ssh/authorized_keys. _PLEASE change this password and this key_ when configuring, or create a new default plugin container image as your base for future use, following your authentication procedures. The account
“container_admin” has “sudo” or superuser privileges, and is allowed to remote shell into the container.
By default the VNS3 Base container is configured for username/password login. You can customize the container for SSH key usage by allocating an instance of the container, modifying sshd_config to not allow password authentication, entering your public key into
/home/container_admin/.ssh/authorized_keys and save a new custom base image for your use.
Accessing via the default private key
Here is the default private key for initial login:
-----BEGIN RSA PRIVATE KEY-----
-----END RSA PRIVATE KEY-----
Primary files for customization
There are two significant files for securing the VNS3_Base container:
Please ensure this file is configured to your organization’s best practices.
The base container comes with an example public key installed, and private key for use in VNS3 documentation. Please remove after initial use or programmatic configuration.
Available Log Files
Log Files available via the Logging Container:
/mnt/logs/kern.log - VNS3 kernel log
/mnt/logs/syslog - VNS3 system log
/mnt/logs/vnscubed_api_background/completed/ - Directory showing completed API calls
/mnt/logs/vnscubed_connection_logs/ipsec.log - IPsec system log files
/mnt/logs/vnscubed_connection_logs/tun0.log - Overlay Network server connection log files
./mnt/logs/version.log (this contains one row with the VNS3 version on it for use in scrpts which need to be version dependent)
Log file rotation
VNS3 controllers rotate log files to both ensure a useful log history is available at all times without taking up too much disk.
Log files on VNS3 are rotated weekly with a history of 14 log files compressed and retained. As a result the previously mentioned log directory available in the Logging Container (
/mnt/logs) may include some additional historical files
Options for Consuming the Log Files via Logging Container
Once the Logging Container has been correctly allocated, adding agents/collectors to the Container will allow 3rd party services/applications to consume the logs and custom alerts can be configured.