Packet Mirroring


You can set up traffic mirroring without running Nubeva Decryptors. The traffic reaching the target security tool will be encrypted. If you are using AWS VPC Traffic Mirrors you can skip to Decrypting AWS VPC Traffic Mirroring.

Creating Destinations

Destinations are define the IP addresses of instances running Cloud Tools. There are many packet inspection and processing tools in the open source community as well as many vendor offerings. Before we create a destination in the UI, we need to have an actual tool.

These are the steps to create a destination that points to a tool:

  1. Click on the “Marker” (bottom) icon on the “Destinations” box.

  2. The next screen allows you to define the properties of this new destination group.

  1. Name the destination.

  2. Choose between a single tool or a set of tools that you want to load share against. For a load share environment, insert multiple comma-separated IP addresses into the field and the traffic will be load-shared among the defined tools.


If you need more advanced load-balancing, you can use the front-end IP address of a cloud load balancer as the IP and configure this LB via the cloud portals.  To enable VXLAN traffic to your destination inbound traffic should be enabled on UDP port 4789.


One of the simplest tools you can use is tcpdump. This is a simple Unix command that takes all data received on an interface and displays it on the screen. You also use it to write this traffic to a file.

Create a Unix instance in your cloud provider. Connect to it and issue the command:

tcpdump -na -i eth0 port 4789

This will start a tcpdump session which will display all mirrored traffic on your default interface but it will not show your SSH session traffic.

  1. Click ‘save’ when finished.

Creating Connections

At this point, you can have one or more source groups and one or more tool destinations.

  1. To connect a source group to a destination/tool, simply click on the source and drag the connection line to the required destination and drop it. This will popup the following connection profile window, with the ‘Source Group’ and ‘Destination Group’ values preset.

../_images/DragConnection.png ../_images/AddConnection.png
  1. You can also click on the the icon in top left corner of on the Connections box and it will take you to the same screen, but you will have to choose the Source Group and Destination Group from their drop-down.

  1. You can use VXLAN tunnel encapsulation to send traffic to the destination. The VNI ID should be a unique number for the source group.

  2. Berkeley Packet Filter (BPF) is where you enter the data filters you want to apply to this connection.

  3. Click save to return to the dashboard. You will see mirroring indications in the diagram as well as the ‘throughput’ value in the connections box:


If you generate encrypted traffic on your source instance:

# run some https traffic on the client

You can see the decrypted traffic on your destination by issuing the command on the decryptor instance:

tcpdump -Ani nurx0 port 80

Decrypting AWS VPC Traffic Mirroring

To decrypt Amazon VPC traffic mirroring follow the first three steps described above:

  1. Installing Nubeva Sensors

  2. Creating Source Groups

  3. Launching Decryptors

Since the AWS VPC traffic mirrors are generating the packet flow, there is no need to create connections. Instead, setup an AWS VPC traffic mirroring session between your source where the nubeva sensor is running, and the destination where you installed the decryptor engine.

To set up a traffic mirroring session please review Working With AWS Traffic Mirroring. Additional information is available on the AWS News Blog.

Monitoring Sensors and Decryptors

You can monitor the status of your Sensors and Decryptors on the sensors and decryptors pages respectively. The figure below depicts the layout of the sensors page showing one active sensor:

Active Sensors


Active Decryptors


Both screens allow you to set the ‘sensitivity threshold’ for determining whether a sensor or a decryptor is ‘active’. Active states are define by the time since a sensor/decryptor last ‘phoned home’. The two figures below show how the same sensor is considered inactive with a threshold set to 6 hours and active when the threshold is set to 1 day.

Sensor active during the past 24 hours


Sensor inactive in the past six hours