Sniffing modes: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
 
(26 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 ==


= Tunneling =
=== 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.


Voipmonitor supports several tunneling options:
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>).


*IPinIP (out of the box)
=== B. Software-based Tunnelling ===
*GRE (out of the box)
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.
*ERSPAN (out of the box)
* '''Built-in Support:''' IP-in-IP, GRE, ERSPAN
*TZSP (mikrotik) - udp_port_tzsp = 37008 option in voipmonitor.conf
* '''UDP-based Tunnels:''' Configure the corresponding port in <code>voipmonitor.conf</code>:
*Layer 2 Tunneling Protocol - udp_port_l2tp = 1701 option in voipmonitor.conf
** <code>udp_port_tzsp = 37008</code> (for Mikrotik's TZSP)
*VXLAN (used by amazon aws) - udp_port_vxlan = 4789 option in voipmonitor.conf
** <code>udp_port_l2tp = 1701</code>
*audiocodes tunneling - audiocodes, udp_port_audiocodes, tcp_port_audiocodes options in voipmonitor.conf
** <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)


= Software packet mirroring =
== 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.


== All in one ==
=== Classic Mode: Standalone Remote Sensors ===
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.  
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.


== Multiple remote sensors one DB/GUI server ==
=== 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.


Note: sensor = sniffer, sniffer = sensor
This model supports two modes of operation:
# '''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.


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)  
==== 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'''
|}


=== Standard remote sniffer ===
== Configuration & Checklists ==
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.


=== Client/server (aka sender/receiver aka remote/central) remote sniffers ===
=== Client/Server Configuration Example ===
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 of a sniffer, 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.
Below is a minimal configuration for the modern client/server model.


=== OLD client/server (aka remote/central) sensor mode ===
;On each ''Remote Sensor (Client)'':
<pre>
# /etc/voipmonitor.conf on the remote sensor


* uses two type of sensors: server/central and client/remote
id_sensor              = 2      # MUST be unique for each sensor, < 65536
* uses mirror_* directives in configuration
server_destination      = 10.0.0.1 # IP address of your central server
* server and client must have the same time
server_destination_port = 60024
server_password        = your_strong_password


'''client/remote sensor'''
# Optional: Uncomment the next line to enable packet mirroring mode
* sniff data, NO processing of this data
# packetbuffer_sender  = yes
* no local storage
</pre>
* 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 the ''Central Server'':
#change this number on each remote sniffer to unique number
<pre>
id_sensor                      = 1         
# /etc/voipmonitor.conf on the central server
#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'''
server_bind            = 0.0.0.0
* has direct access to the sql
server_bind_port        = 60024
* has local storage
server_password        = your_strong_password
* receives sniffed data from clients, process them, saves cdrs to the sql and stores pcaps to the local spooldir
* 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:
# Remember to configure mysql* options for the central database connection
#do not forget to configure mysql* options
mysqlhost              = localhost
#set here IP address of central server, which is accessible from remote sniffers.
mysqldb                = voipmonitor
mirror_bind_ip               = 0.0.0.0
mysqluser               = root
mirror_bind_port            = 5030
mysqlpassword          = db_password
</pre>


=== NEW client/server (aka remote/central) sensor mode ===
=== Firewall Checklist ===
* has two type of sensors: server(central) and client(remote)
* '''Modern Client/Server Mode (v20+):'''
* prerequisite is GNU/GPL sniffer version >= 20.x on both ends and version of a GUI >= 18.3 which is supporting also multiple receivers.
** On '''Central Server:''' Allow inbound <code>TCP/60024</code> from remote sensors. Allow inbound <code>TCP/5029</code> for GUI management access.
* uses server_* options in voipmonitor.conf
* '''Cloud Mode:'''
* server and client must have the same time (ideally use NTP on both server/client or connection from remote will be refused)
** On '''Remote Sensors:''' Allow outbound <code>TCP/60023</code> to <code>cloud.voipmonitor.org</code>.


Remote sniffers can operate in two ways:
=== 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.


* packets are sniffed and processed on remote sniffers which uses CPU/memory, sends CDR to central sniffer and stores pcap files on local storage.  
== AI Summary for RAG ==
* OR packets are sniffed and sent to central sniffer which process them (does not use much CPU/memory but uses more network throughput)  
'''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:'''
this mode is controlled by packetbuffer_sender option ("yes" will send packets to central sniffer).  
* 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?
* mysql configuration is set only on server(central) configuration
* When should I use packet mirroring (packetbuffer_sender) instead of local processing?
* Server(central) sniffer communicates with remote sniffers through TCP connection. Client is connecting to the server so it can be behind firewall/NAT etc.  
* What are the firewall requirements for the client/server deployment model?
* 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)
* Can I run the sensor on the same machine as my Asterisk/FreeSWITCH server?
* Remote sensors are populated in GUI configuration automatically once remote sniffer is connected to a central sniffer.
* What is a SPAN port and how is it used with VoIPmonitor?
* Connection between client/server uses strong encryption (DH key exchange / AES cypher) with compression.
* Why is NTP important for a distributed VoIPmonitor setup?
* The server's managerport and server_bind_port ports need to be accessible from the GUI.
 
==== client(remote) sensor configuration ====
 
# this example configuration will process packets and sends only CDR to the server.
# id_Sensor needs to be < 65536
id_sensor = unique_number
server_destination = serverip
#needs to be defined same as server_bind_port option on the central server  
server_destination_port = 60024
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 ====
#this will listen on all IPs
server_bind = 0.0.0.0
server_bind_port = 60024
server_password = somepassword
#do not forget to configure mysql* options
 
= NTP server tweak =
 
It is recommended that all machines are synchronised with NTP with minpoll (3) and maxpoll (4) setting
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.

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"