Skip to main content
Version: 1.2.0

Example: Secure Ingestion

This section will help you get started with devices to ingest data with specific protocols, walking you through a common use case.

info

For a detailed discussion of devices, see this section.

Loading include…

Scenario​

Use a TCP as the listening protocol.

Setup and Trial​

We will create a TLS-enabled device to ingest data over TCP securely. We will be sending an TLS-encrypted message over a TCP connection, and to do that we will be using OpenSSL.

info

OpenSSL is not available by default on Windows. If you have not previously installed it yourself, the procedure is under the foldable link.

Install OpenSSL

  1. Open a terminal with Administrative privileges.

  2. On the command line type:

    winget search openssl

    This will have an output like:

    Name                 Id                           Version Match        Source
    -----------------------------------------------------------------------------
    FireDaemon Lozenge   FireDaemon.FireDaemonLozenge 3.0.4   Tag: openssl winget
    FireDaemon OpenSSL 3 FireDaemon.OpenSSL           3.5.0   Tag: openssl winget
    Stunnel              MichalTrojnara.Stunnel       5.75    Tag: openssl winget
    OpenSSL 3.5.0        ShiningLight.OpenSSL.Dev     3.5.0                winget
    OpenSSL Light 3.5.0  ShiningLight.OpenSSL.Light   3.5.0                winget

    We will pick FireDaemon for installation.

  3. Write the installation command for winget:

    winget install --id=FireDaemon.OpenSSL -e

    This will have an output that resembles this:

    Found FireDaemon OpenSSL 3 [FireDaemon.OpenSSL] Version 3.1.4
    This application is licensed to you by its owner.
    Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
    Downloading https://download.firedaemon.com/FireDaemon-OpenSSL/FireDaemon-OpenSSL-x64-3.1.4.exe
      ██████████████████████████████  11.3 MB / 11.3 MB
    Successfully verified installer hash
    Starting package install...
    Successfully installed

  4. Add the installation location to your $PATH—if you did not change the default installation directory, this will be:

    $Env:PATH += ";C:\Program Files\FireDaemon OpenSSL 3\bin"

  5. Finally, test to see whether OpenSSL is working as expected—type the command:

    C:\>openssl
    help:

    Standard commands
    asn1parse         ca                ciphers           cmp
    cms               crl               crl2pkcs7         dgst
    dhparam           dsa               dsaparam          ec
    ecparam           enc               engine            errstr
    fipsinstall       gendsa            genpkey           genrsa
    help              info              kdf               list  
    ...
    etc.
Loading include…

We can now proceed to our scenario.

Prepare the certificates​

First, we have to prepare TLS certificates for the secure connection. The following procedure is platform-specific, so please follow it through:

This can be done with OpenSSL. Open a terminal and stay at the $HOME directory. Then type this command:

openssl genrsa -out cert.key 2048

Now enter the following line—you will be prompted to enter some information like country, state/province, locality, etc. For our purposes, you can leave all of them blank by typing .:

openssl req -new -x509 -key cert.key -out cert.crt -days 365

We will now generate a pfx file from these. Enter the following command, and type again . for password when prompted:

openssl pkcs12 -export -out cert.pfx -inkey cert.key -in cert.crt

If you check your current directory, you will see that these files were created:

Get-ChildItem cert.* | Format-Table Name

Name
----
cert.crt
cert.key
cert.pfx

Place the certificates​

Now we have to convert this PFX file to the PEM format that Director uses. To do that, we first have to copy the cert.pfx file to <vm_root> and navigate there:

Copy-Item -Path cert.pfx -Destination "<vm_root>"
Set-Location <vm_root>

To generate the PEM files, enter the following command:

.\vmetric-director -pfx2pem "cert.pfx"

You will be prompted for the password—we picked . above; enter it—and then the *.pem files will generated.

Check your current directory to verify that they are there:

Get-ChildItem *.pem | Format-Table Name

Name
----
cert.pem
key.pem
note
  • The private key file (key.pem) should be readable only by the Director process
  • The certificate file (cert.pem) can be world-readable

Create the secure configuration​

We will now prepare a secure configuration by creating another file named from-syslog-tcp.yml in our working directory:

from-syslog-tcp.yml
devices:
  - id: 2222
    name: from_syslog_tcp
    type: syslog
    status: true
    properties:
      protocol: tcp
      address: 127.0.0.1
      port: 6514
      tls:
        status: true
        cert_name: cert.pem
        key_name: key.pem

Note that we have specified the *.pem files we have created in the previous step. That is because we have set the status of the tls field to true so unless we point to these files the process will not run.

Also, port 6514 is the one commonly used for Syslog over TLS (RFC 5425).

Run the listener​

Open a terminal and enter the following in the command line to start Director:

.\vmetric-director -background

This will start Director as a background process which you can verify as indicated before. Now enter:

.\vmetric-director -console

After you press Enter, you will see a stream of initialization messages and our device will be spawned off. If it has successfully processed the pem files, you should get the following status messages:

[2025-06-30 11:40:32] [Information] [vmetric-director] Reassigned device 2222 to node VM_LAPTOP
[2025-06-30 11:40:39] [Information] [vmetric-director] [syslog-2222] Listener server is successfully started.

Now it is waiting to receive messages from Syslog.

Test the configuration​

Time to test the secure connection configuration. But first we have to make sure that our connection is working.

Open another terminal to send messages in generator mode, and enter the following command:

Test-NetConnection -ComputerName 127.0.0.1 -Port 6514

If everything is running as expected, you should see the following:

ComputerName     : 127.0.0.1
RemoteAddress    : 127.0.0.1
RemotePort       : 6514
InterfaceAlias   : Loopback Pseudo-Interface 1
SourceAddress    : 127.0.0.1
TcpTestSucceeded : True

This time we will send our message using a standard command and piping it through openssl. In the same terminal, enter the following command:

Write-Output "Hello world" | openssl s_client -connect 127.0.0.1:6514

This command

  • sends a "Hello world" message to the terminal's pipeline;
  • opens a TLS-encrypted TCP connection to 127.0.0.1 on port 6514, and sends the message piped into it over the encrypted connection.

The output of the command should be a long status report starting as:

Connecting to 127.0.0.1
CONNECTED(0000018C)
Can't use SSL_get_servername
depth=0 C=AU, ST=Some-State, L=city, O=Widgets Ltd, OU=TW, CN=JohnDoe, emailAddress=johndoe@somewhere.com
verify error:num=18:self-signed certificate
...

When you switch back to the other terminal where Director is issuing status messages, you should see:

[2025-06-30 11:45:05] [Information] [vmetric-director] [syslog-2222] Processing Syslog messages.. Number of Messages: 1
[2025-06-30 11:45:06] [Information] [vmetric-director] [syslog-2222] Completed processing of vmdb.syslog.2222.1751273105828017700.1.vmfl logs. Number of processed logs: 1

You can now exit the process on both terminals by pressing Ctrl+C.

Monitoring​

Check that secure ingestion worked by verifying:

  • TLS connection established successfully (no connection errors)
  • Encrypted messages appeared in Director's console output
  • No error files in <vm_root>/Director/storage/logs/

If you see the test messages displayed and no TLS connection errors, secure data ingestion is working correctly.

In the next section, we will create a different type of target to forward the data ingested through a UDP device.