Sniffing modes: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
 
(37 intermediate revisions by 3 users not shown)
Line 1: Line 1:
= Linux host =
{{DISPLAYTITLE:VoIPmonitor Deployment & Topology Guide}}


You can install or compile VoIPmonitor binary directly on linux PBX or SBC/SIP server. This does not requires additional hardware and changes in network topology. The only downside is that voipmonitor consumes hardware resources - RAM, CPU and I/O workload which can affect the whole system. If it is not acceptable to share hardware for voipmonitor the second common use case is doing port mirroring.  
'''This guide provides a comprehensive overview of VoIPmonitor's deployment models. It covers the fundamental choice between on-host and dedicated sensors, methods for capturing traffic, and detailed configurations for scalable, multi-site architectures.'''


= Hardware port mirroring =  
== Core Concept: Where to Capture Traffic ==
The first decision in any deployment is where the VoIPmonitor sensor (sniffer) will run.


Port Mirroring is used on a network switch to send a copy of network packets seen on one switch port (or an entire VLAN) to a network monitoring connection on another switch port => voipmonitor dedicated linux box. Port mirroring on a Cisco Systems switch is generally referred to as Switched Port Analyzer (SPAN); some other vendors have other names for it, such as Roving Analysis Port (RAP) on 3Com switches or just port mirroring.  
=== 1. On-Host Capture (on the PBX/SBC) ===
The sensor can be installed directly on the same Linux server that runs your PBX or SBC.
*'''Pros:''' Requires no extra hardware, network changes, or port mirroring. It is the simplest setup.
*'''Cons:''' Adds CPU, memory, and disk I/O load to your production voice server. If these resources are critical, a dedicated sensor is the recommended approach.


In case of hardware mirroring you often need to have additional ethernet port. Sniffer is configured to use this port (interface=eth1) and it automatically put the interface into Promiscuous mode. In case you need to mirror to more ethernet ports you can set interface=any in voipmonitor.conf which will enable mirroring on all interfaces but you need to set each ethernet interface into promiscuous mode manually
=== 2. Dedicated Sensor ===
A dedicated Linux server runs only the VoIPmonitor sensor. This is the recommended approach for production environments as it isolates monitoring resources from your voice platform. To use a dedicated sensor, you must forward a copy of the network traffic to it using one of the methods below.


ifconfig eth1 promisc
== Methods for Forwarding Traffic to a Dedicated Sensor ==


= Software packet mirroring =
=== A. Hardware Port Mirroring (SPAN/RSPAN) ===
This is the most common and reliable method. You configure your physical network switch to copy all traffic from the switch ports connected to your PBX/SBC to the switch port connected to the VoIPmonitor sensor. This feature is commonly called '''Port Mirroring''', '''SPAN''', or '''RAP'''. Consult your switch's documentation for configuration details.


== All in one ==
The VoIPmonitor sensor interface will be put into promiscuous mode automatically. To capture from multiple interfaces, set <code>interface = any</code> in <code>voipmonitor.conf</code> and enable promiscuous mode manually on each NIC (e.g., <code>ifconfig eth1 promisc</code>).
If the sensor is installed on the same server as MySQL and GUI you do not need to configure sensors in GUI. The GUI is reading PCAP files directly from local file system and database are connected via localhost mysql database.  


== Multiple remote sensors one DB/GUI server ==
=== B. Software-based Tunnelling ===
When hardware mirroring is not an option, many network devices and PBXs can encapsulate VoIP packets and send them to the sensor's IP address using a tunnel. VoIPmonitor natively supports a wide range of protocols.
* '''Built-in Support:''' IP-in-IP, GRE, ERSPAN
* '''UDP-based Tunnels:''' Configure the corresponding port in <code>voipmonitor.conf</code>:
** <code>udp_port_tzsp = 37008</code> (for Mikrotik's TZSP)
** <code>udp_port_l2tp = 1701</code>
** <code>udp_port_vxlan = 4789</code> (Common in AWS environments)
* '''Proprietary & Other Protocols:'''
** [[audiocodes tunneling|AudioCodes Tunneling]] (uses <code>udp_port_audiocodes</code> or <code>tcp_port_audiocodes</code>)
** HEP (v3+) (enable <code>hep*</code> options)
** IPFIX (for Oracle SBCs) (enable <code>ipfix*</code> options)


Note: sensor = sniffer, sniffer = sensor
== Distributed Deployment Models ==
For monitoring multiple remote offices or a large infrastructure, a distributed model is essential. This involves a central GUI/Database server collecting data from multiple remote sensors.


Sensors can be configured in two ways - mirroring all packets by the remote sensor to central sensor or the remote sensor is processing packets directly and only sends CDR to central sensor which is connected to the database (keeping pcap files on local storage located on remote sensors)
=== Classic Mode: Standalone Remote Sensors ===
In this traditional model, each remote sensor is a fully independent entity.
*'''How it works:''' The remote sensor processes packets and stores PCAPs locally. It connects directly to the central MySQL database to write CDRs. The central GUI must also have direct network access to each sensor's management port (default 5029) to fetch PCAP files.
*'''Pros:''' Simple conceptual model.
*'''Cons:''' Requires opening firewall ports to each sensor and managing database credentials on every remote machine.


=== Standard remote sniffer ===
=== Modern Mode: Client/Server Architecture (v20+) ===
Remote sensor in standard mode processes all packets and stores CDR to database keeping pcap files on local disk. This setup generates minimal traffic between sensor and remote database (it sends only CDR). The GUI needs a direct access to the management ip/port (to get stats, pcaps, etc.). The sensor is NOT automatically created in the GUI.
This is the '''recommended''' model for all new distributed deployments. It uses a secure, encrypted TCP channel between remote sensors (clients) and a central sensor instance (server). The GUI only needs to communicate with the central server.


=== Client/server (aka sender/receiver aka remote/central) remote sniffers ===
This model supports two modes of operation:
The sensors can sniff the packets on one host and process them on another host. There are two modes. The old mode (for compatibility reason, the existing users should migrate slowly to the new one) and the new mode (since version 20.0, the new users should use this one). All voipmonitor configuration examples are minimal which leaves all options to default (can be changed). Don't mix old and new modes in one environment.
# '''Local Processing:''' Remote sensors process packets locally and send only the small CDR data over the encrypted channel. PCAPs remain on the remote sensor.
# '''Packet Mirroring:''' Remote sensors do '''no''' processing. They forward the entire raw packet stream over the encrypted channel to the central server, which handles all processing and storage. This is ideal for low-resource remote devices.


=== OLD client/server (aka remote/central) sensor mode ===
==== Comparison of Remote Deployment Modes ====
{| class="wikitable"
! Deployment Model
! Packet Processing Location
! PCAP Storage Location
! Network Traffic to Central Server
! GUI Connectivity
|-
| Classic Standalone
| Remote
| Remote
| Minimal (MySQL CDRs)
| GUI ↔ each Sensor (management port)
|-
| '''Modern Client/Server (Local Processing)'''
| Remote
| Remote
| Minimal (Encrypted CDRs)
| '''GUI ↔ Central Server only'''
|-
| '''Modern Client/Server (Packet Mirroring)'''
| '''Central'''
| '''Central'''
| High (Encrypted full packets)
| '''GUI ↔ Central Server only'''
|}


* uses two type of sensors: server/central and client/remote
== Configuration & Checklists ==
* uses mirror_* directives in configuration
* server and client must have the same time


'''client/remote sensor'''
=== Client/Server Configuration Example ===
* sniff data, NO processing of this data
Below is a minimal configuration for the modern client/server model.
* no local storage
* send data to server/central node
* no sql cfg needed
* management port needs to be accessible from gui
* sensor is NOT created automatically in gui/db
* gui communicates with sensor directly via management port


voipmonitor.conf:
;On each ''Remote Sensor (Client)'':
#change this number on each remote sniffer to unique number
<pre>
id_sensor                      = 1         
# /etc/voipmonitor.conf on the remote sensor
#change this to correct interface where you need to intercept traffic
interface                      = eth0       
#up to 2000MB more reading about ringbuffer in scaling section of a doc.
ringbuffer                      = 200       
packetbuffer_enable            = yes
#in MB
max_buffer_mem                  = 2000       
packetbuffer_compress          = yes
#enable compression
packetbuffer_compress_ratio    = 100
#this is address of your dedicated server (central sniffer - mirroring receiver)
mirror_destination_ip          = 192.168.0.1
mirror_destination_port        = 5030


'''server/central sensor'''
id_sensor              = 2      # MUST be unique for each sensor, < 65536
* has direct access to the sql
server_destination      = 10.0.0.1 # IP address of your central server
* has local storage
server_destination_port = 60024
* receives sniffed data from clients, process them, saves cdrs to the sql and stores pcaps to the local spooldir
server_password        = your_strong_password
* management port needs to be accessible from gui
* sensor is NOT created automatically in gui/db
* gui communicates with sensor directly via management port


voipmonitor.conf:
# Optional: Uncomment the next line to enable packet mirroring mode
#do not forget to configure mysql* options
# packetbuffer_sender  = yes
#set here IP address of central server, which is accessible from remote sniffers.
</pre>
mirror_bind_ip              = 0.0.0.0
mirror_bind_port            = 5030


=== NEW client/server (aka remote/central) sensor mode ===
;On the ''Central Server'':
* prerequisite is GNU/GPL sniffer version > 20.x on both ends
<pre>
* has two type of sensors: server(central) and client(remote)
# /etc/voipmonitor.conf on the central server
* uses server_* options in voipmonitor.conf  
* server and client must have the same time (ideally use NTP on both server/client or connection from remote will be refused)


Remote sniffers can operate in two ways:
server_bind            = 0.0.0.0
server_bind_port        = 60024
server_password        = your_strong_password


* packets are sniffed and processed on remote sniffers which uses CPU/memory, sends CDR to central sniffer and stores pcap files on local storage.
# Remember to configure mysql* options for the central database connection
* OR packets are sniffed and sent to central sniffer which process them (does not use much CPU/memory but uses more network throughput)
mysqlhost              = localhost
mysqldb                = voipmonitor
mysqluser              = root
mysqlpassword          = db_password
</pre>


=== Firewall Checklist ===
* '''Modern Client/Server Mode (v20+):'''
** On '''Central Server:''' Allow inbound <code>TCP/60024</code> from remote sensors. Allow inbound <code>TCP/5029</code> for GUI management access.
* '''Cloud Mode:'''
** On '''Remote Sensors:''' Allow outbound <code>TCP/60023</code> to <code>cloud.voipmonitor.org</code>.


this mode is controlled by packetbuffer_sender option ("yes" will send packets to central sniffer).  
=== Time Synchronization ===
Accurate and synchronized time is '''critical''' for correlating call legs from different sensors. All servers (GUI, DB, and all Sensors) must run an NTP client (like `chrony` or `ntpdate`) to keep their clocks in sync.


* mysql configuration is set only on server(central) configuration
== AI Summary for RAG ==
* Server(central) sniffer communicates with remote sniffers through TCP connection. Client is connecting to the server so it can be behind firewall/NAT etc.
'''Summary:''' This guide covers the deployment topologies for VoIPmonitor. It contrasts running the sensor on the same host as a PBX versus on a dedicated server. For dedicated sensors, it details methods for forwarding traffic, including hardware-based port mirroring (SPAN) and various software-based tunneling protocols (IP-in-IP, GRE, TZSP, VXLAN, HEP, etc.). The core of the article explains distributed architectures for multi-site monitoring, comparing the "classic" standalone remote sensor model with the modern, recommended "client/server" model. It details the two operational modes of the client/server architecture: local processing (sending only CDRs) and packet mirroring (sending full, raw packets for central processing), which is ideal for low-resource endpoints. The guide concludes with minimal configuration examples and firewall rules for the client/server setup and emphasizes the critical importance of time synchronization using NTP.
* GUI communicates ONLY with the central server. If GUI wants to get pcap from remote sniffer it requests it from the central sniffer which contacts client sniffer (so there is no direct TCP connection to a client sniffers)
'''Keywords:''' deployment, architecture, topology, on-host, dedicated sensor, port mirroring, SPAN, RSPAN, traffic mirroring, tunneling, GRE, TZSP, VXLAN, HEP, remote sensor, multi-site, client server mode, packet mirroring, local processing, firewall rules, NTP, time synchronization, cloud mode
* Remote sensors are populated in GUI configuration automatically once remote sniffer is connected to a central sniffer.
'''Key Questions:'''
* Connection between client/server uses strong encryption (DH key exchange / AES cypher) with compression.
* How do I set up VoIPmonitor to monitor multiple remote locations?
 
* What is the difference between the classic remote sensor and the modern client/server mode?
==== client(remote) sensor configuration ====
* When should I use packet mirroring (packetbuffer_sender) instead of local processing?
 
* What are the firewall requirements for the client/server deployment model?
# this example configuration will process packets and sends only CDR to the server.
* Can I run the sensor on the same machine as my Asterisk/FreeSWITCH server?
id_sensor = unique_number # must be < 65535
* What is a SPAN port and how is it used with VoIPmonitor?
server_destination = serverip
* Why is NTP important for a distributed VoIPmonitor setup?
server_destination_port = 60024 #must be same as server_bind_port on central server  
server_password = somepassword
#If you want to mirror all packets (so the remote sniffer will not use much CPU and memory and NO local storage) add one more option:
packetbuffer_sender = yes
 
==== server(central) sensor configuration ====
 
server_bind = 0.0.0.0 #this will listen on all IPs
server_bind_port = 60024
server_password = somepassword
#do not forget to configure mysql* options
 
 
 
.

Latest revision as of 10:37, 30 June 2025


This guide provides a comprehensive overview of VoIPmonitor's deployment models. It covers the fundamental choice between on-host and dedicated sensors, methods for capturing traffic, and detailed configurations for scalable, multi-site architectures.

Core Concept: Where to Capture Traffic

The first decision in any deployment is where the VoIPmonitor sensor (sniffer) will run.

1. On-Host Capture (on the PBX/SBC)

The sensor can be installed directly on the same Linux server that runs your PBX or SBC.

  • Pros: Requires no extra hardware, network changes, or port mirroring. It is the simplest setup.
  • Cons: Adds CPU, memory, and disk I/O load to your production voice server. If these resources are critical, a dedicated sensor is the recommended approach.

2. Dedicated Sensor

A dedicated Linux server runs only the VoIPmonitor sensor. This is the recommended approach for production environments as it isolates monitoring resources from your voice platform. To use a dedicated sensor, you must forward a copy of the network traffic to it using one of the methods below.

Methods for Forwarding Traffic to a Dedicated Sensor

A. Hardware Port Mirroring (SPAN/RSPAN)

This is the most common and reliable method. You configure your physical network switch to copy all traffic from the switch ports connected to your PBX/SBC to the switch port connected to the VoIPmonitor sensor. This feature is commonly called Port Mirroring, SPAN, or RAP. Consult your switch's documentation for configuration details.

The VoIPmonitor sensor interface will be put into promiscuous mode automatically. To capture from multiple interfaces, set interface = any in voipmonitor.conf and enable promiscuous mode manually on each NIC (e.g., ifconfig eth1 promisc).

B. Software-based Tunnelling

When hardware mirroring is not an option, many network devices and PBXs can encapsulate VoIP packets and send them to the sensor's IP address using a tunnel. VoIPmonitor natively supports a wide range of protocols.

  • Built-in Support: IP-in-IP, GRE, ERSPAN
  • UDP-based Tunnels: Configure the corresponding port in voipmonitor.conf:
    • udp_port_tzsp = 37008 (for Mikrotik's TZSP)
    • udp_port_l2tp = 1701
    • udp_port_vxlan = 4789 (Common in AWS environments)
  • Proprietary & Other Protocols:
    • AudioCodes Tunneling (uses udp_port_audiocodes or tcp_port_audiocodes)
    • HEP (v3+) (enable hep* options)
    • IPFIX (for Oracle SBCs) (enable ipfix* options)

Distributed Deployment Models

For monitoring multiple remote offices or a large infrastructure, a distributed model is essential. This involves a central GUI/Database server collecting data from multiple remote sensors.

Classic Mode: Standalone Remote Sensors

In this traditional model, each remote sensor is a fully independent entity.

  • How it works: The remote sensor processes packets and stores PCAPs locally. It connects directly to the central MySQL database to write CDRs. The central GUI must also have direct network access to each sensor's management port (default 5029) to fetch PCAP files.
  • Pros: Simple conceptual model.
  • Cons: Requires opening firewall ports to each sensor and managing database credentials on every remote machine.

Modern Mode: Client/Server Architecture (v20+)

This is the recommended model for all new distributed deployments. It uses a secure, encrypted TCP channel between remote sensors (clients) and a central sensor instance (server). The GUI only needs to communicate with the central server.

This model supports two modes of operation:

  1. Local Processing: Remote sensors process packets locally and send only the small CDR data over the encrypted channel. PCAPs remain on the remote sensor.
  2. Packet Mirroring: Remote sensors do no processing. They forward the entire raw packet stream over the encrypted channel to the central server, which handles all processing and storage. This is ideal for low-resource remote devices.

Comparison of Remote Deployment Modes

Deployment Model Packet Processing Location PCAP Storage Location Network Traffic to Central Server GUI Connectivity
Classic Standalone Remote Remote Minimal (MySQL CDRs) GUI ↔ each Sensor (management port)
Modern Client/Server (Local Processing) Remote Remote Minimal (Encrypted CDRs) GUI ↔ Central Server only
Modern Client/Server (Packet Mirroring) Central Central High (Encrypted full packets) GUI ↔ Central Server only

Configuration & Checklists

Client/Server Configuration Example

Below is a minimal configuration for the modern client/server model.

On each Remote Sensor (Client)
# /etc/voipmonitor.conf on the remote sensor

id_sensor               = 2      # MUST be unique for each sensor, < 65536
server_destination      = 10.0.0.1 # IP address of your central server
server_destination_port = 60024
server_password         = your_strong_password

# Optional: Uncomment the next line to enable packet mirroring mode
# packetbuffer_sender   = yes
On the Central Server
# /etc/voipmonitor.conf on the central server

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

# Remember to configure mysql* options for the central database connection
mysqlhost               = localhost
mysqldb                 = voipmonitor
mysqluser               = root
mysqlpassword           = db_password

Firewall Checklist

  • Modern Client/Server Mode (v20+):
    • On Central Server: Allow inbound TCP/60024 from remote sensors. Allow inbound TCP/5029 for GUI management access.
  • Cloud Mode:
    • On Remote Sensors: Allow outbound TCP/60023 to cloud.voipmonitor.org.

Time Synchronization

Accurate and synchronized time is critical for correlating call legs from different sensors. All servers (GUI, DB, and all Sensors) must run an NTP client (like `chrony` or `ntpdate`) to keep their clocks in sync.

AI Summary for RAG

Summary: This guide covers the deployment topologies for VoIPmonitor. It contrasts running the sensor on the same host as a PBX versus on a dedicated server. For dedicated sensors, it details methods for forwarding traffic, including hardware-based port mirroring (SPAN) and various software-based tunneling protocols (IP-in-IP, GRE, TZSP, VXLAN, HEP, etc.). The core of the article explains distributed architectures for multi-site monitoring, comparing the "classic" standalone remote sensor model with the modern, recommended "client/server" model. It details the two operational modes of the client/server architecture: local processing (sending only CDRs) and packet mirroring (sending full, raw packets for central processing), which is ideal for low-resource endpoints. The guide concludes with minimal configuration examples and firewall rules for the client/server setup and emphasizes the critical importance of time synchronization using NTP. Keywords: deployment, architecture, topology, on-host, dedicated sensor, port mirroring, SPAN, RSPAN, traffic mirroring, tunneling, GRE, TZSP, VXLAN, HEP, remote sensor, multi-site, client server mode, packet mirroring, local processing, firewall rules, NTP, time synchronization, cloud mode Key Questions:

  • How do I set up VoIPmonitor to monitor multiple remote locations?
  • What is the difference between the classic remote sensor and the modern client/server mode?
  • When should I use packet mirroring (packetbuffer_sender) instead of local processing?
  • What are the firewall requirements for the client/server deployment model?
  • Can I run the sensor on the same machine as my Asterisk/FreeSWITCH server?
  • What is a SPAN port and how is it used with VoIPmonitor?
  • Why is NTP important for a distributed VoIPmonitor setup?
Retrieved from "https://www.voipmonitor.org//doc/index.php?title=Sniffing_modes&oldid=5341"