Sniffing modes: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
No edit summary
 
(39 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 (from version 20.x) ===
;On the ''Central Server'':
<pre>
# /etc/voipmonitor.conf on the central server


* has two type of sensors: server/central and client/remote
server_bind            = 0.0.0.0
* uses server_* directives in configuration
server_bind_port        = 60024
* server and client must have the same time
server_password        = your_strong_password


'''client/remote sensor'''
# Remember to configure mysql* options for the central database connection
* sniff packets
mysqlhost              = localhost
* packets processing depends on packetbuffer_sender directive, no means local packet processing, yes means send packets to server sensor
mysqldb                = voipmonitor
* local storage depends on packetbuffer_sender directive, no means local storage, yes means send packet to server sensor
mysqluser              = root
* send packets to server/central sensor depends on packetbuffer_sender directive, no means local processing, yes means send packets to server sensor
mysqlpassword          = db_password
* no sql cfg needed because sql commands are sent to server sensor
</pre>
* management port does NOT need to be accessible from gui
* sensor IS created automatically in gui/db (by server sensor)
* gui communicates with sensor via server sensor
* crypt and compress communication with server sensor


voipmonitor.conf:
=== Firewall Checklist ===
# this example configuration will process packets and sends only CDR to the server.
* '''Modern Client/Server Mode (v20+):'''
id_sensor = unique_number # must be < 65535
** On '''Central Server:''' Allow inbound <code>TCP/60024</code> from remote sensors. Allow inbound <code>TCP/5029</code> for GUI management access.
server_destination = serverip
* '''Cloud Mode:'''
server_destination_port = 60024 #can be any port
** On '''Remote Sensors:''' Allow outbound <code>TCP/60023</code> to <code>cloud.voipmonitor.org</code>.
server_password = somepassword
#If you want to mirror all packets (so the remote sniffer will not use much CPU and memory) add one more option:
# packetbuffer_sender = yes


'''server/central sensor'''
=== Time Synchronization ===
* has direct access to the sql
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.
* has local storage
* when clients send sniffed data, process them, saves cdrs to the sql and stores pcaps to the local spooldir
* receive sql commands from clients and redirect them sql server (proxy for client's sql commands)
* management port needs to be accessible from gui
* sensor is NOT created automatically in gui/db
* gui communicates with sensor directly via management port
* serve as a proxy between gui and client sensor for management commands
* can be only one server sensor in environment for now


voipmonitor.conf:
== AI Summary for RAG ==
server_bind = 0.0.0.0 #this will listen on all IPs
'''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.
server_bind_port = 60024
'''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
server_password = somepassword
'''Key Questions:'''
#do not forget to configure mysql* options
* 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?

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"