Directing traffic to Azure vSensor

How to direct traffic to Azure vSensors.

Forwarding Traffic to Azure vSensors

If you wish to use 3^rd party tools to direct traffic at the vSensor capture port, it should be VXLAN encapsulated and sent on port 4789. When using such tools, to ensure accurate metadata generation and session reconstruction, traffic distribution to Vectra sensors must maintain flow-level persistence — that is, all packets from a single network session must be seen by the same sensor. Azure standard load balancers cannot be used because the vSensor cannot respond to required Azure standard load balancer health checks. It only listens for traffic coming inbound.

To find the IP assigned during deployment to your traffic NIC, go to your Azure resource group that was used during deployment, click on the traffic NIC (it will be the interface that ends with trafficnic), and there you will see the private IP that was assigned to the traffic NIC (capture interface of your newly deployed vSensor).

Summary:

You can use any method or third party tool you want to direct traffic to Vectra vSensors as long as:

• It is forwarded to the traffic NIC.
• It is VXLAN encapsulated over port 4789.
• Flow-level persistence is maintained. That is, all packets from a single network session must be seen by the same Vectra Sensor.

Azure Virtual Network TAP (VTAP)

Azure VTAP is still in public preview and may not be available in all regions.

For Microsoft's guidance on using Microsoft VTAP to direct traffic, please see Virtual network TAP at Microsoft. They also have portal and CLI instructions here:

• Work with a virtual network TAP using the Azure portal
• Work with a virtual network TAP using the Azure CLI

Vectra professional services can also assist in Azure deployments. Please contact your Vectra account team for details.

cPacket cVu-V Integration

Vectra created a deployment guide to customers wishing to use cPacket cVu-V technology to forward Azure traffic to Vectra vSensors deployed in Azure. Please work with your cPacket team on the deployment and see Vectra's guide here: Azure cPacket cVu-V.

Traffic Validation

Please see the following Vectra support article for recommendations on network traffic that should be examined and excluded from analysis:

• Network Traffic Recommendations

After sending traffic to your Sensors, it is a best practice to validate that the traffic observed meets quality standards required for accurate detection and processing. Vectra’s Network Traffic Validation feature provides alarms and metrics that can be used to validate the quality of your traffic. Please see the following Vectra support article for details:

• Traffic Validation (ENTV)

Once you have directed traffic at your Sensor’s capture interface though either 3^rd party traffic broker or Azure VTAP and have traffic flowing to the Sensor you can validate the traffic flow.

To validate flow from the Vectra side there are several methods:

• To see that packets are being receive by the traffic interface, use ssh to login to the CLI of the Sensor as the vectra user and use the show traffic stats command. See SSH login process for CLI for details on accessing the CLI.

  • Run show traffic stats several times to see that packet counts are increasing.

  

  • In the Vectra GUI if you navigate to Network Stats > Ingested Traffic, you can see the traffic graph for your Sensor.

    • For this graph to display, there must be at least 1 Mbps of traffic being captured.
    • Once traffic capture begins, it will take a few minutes for this graph to be populated. Use the CLI of the Sensor as shown above to validate that packets are flowing 1^st.

• The Network Stats > Observed IPs page shows the subnets being observed and numbers of hosts seen: