Sniffing modes: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
 
(48 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 '''RSPAN'''. 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>ip link set dev eth1 promisc on</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 ===
Sensors can be configured in two ways - mirroring all packets by the remote sniffer to central sniffer or the remote sniffer is processing VoIP directly and only sends CDR to remote database keeping pcap files on local storage.  
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 cloud 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)


=== Standard remote sniffer ===
== Distributed Deployment Models ==
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)
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/MariaDB database to write CDRs. For PCAP retrieval the GUI typically needs network access to each sensor's management port (default <code>TCP/5029</code>).
* '''Pros:''' Simple conceptual model.
* '''Cons:''' Requires opening firewall ports to each sensor and managing database credentials on every remote machine.


'''What you need to configure on remote sniffer:'''
=== Modern Mode: Client/Server Architecture (v20+) — Recommended ===
This model uses a secure, encrypted TCP channel between remote sensors (clients) and a central sensor instance (server). The GUI communicates with the central server only, which significantly simplifies networking and security.


*/etc/voipmonitor.conf
This architecture supports two primary modes:
id_sensor = unique_number < 65535
# '''Local Processing:''' Remote sensors process packets locally and send only lightweight CDR data over the encrypted channel. PCAPs remain on the remote sensor. On-demand PCAP fetch is proxied via the central server (to the sensor's <code>TCP/5029</code>).
managerip = 0.0.0.0
# '''Packet Mirroring:''' Remote sensors forward the entire raw packet stream to the central server, which performs all processing and storage. Ideal for low-resource remote sites.
mysqlhost = remotedatabaseIPorHost
#mysqlport = 3306
mysqlusername = voipmonitor
mysqlpassword = safu3q28n
mysqldb = voipmonitor


Note: you probably need to reconfigure your central MySQL to be able to listen not only on localhost. Check your mysql configuration option
==== Architecture Diagrams (PlantUML) ====


  bind-address = 0.0.0.0
  <kroki lang="plantuml">
  @startuml
  skinparam shadowing false
  skinparam defaultFontName Arial
  skinparam rectangle {
    BorderColor #4A90E2
    BackgroundColor #FFFFFF
    stereotypeFontColor #333333
  }
  skinparam packageBorderColor #B0BEC5
  skinparam packageBackgroundColor #F7F9FC


You also need to create user for your database:
  title Client/Server Architecture — Local Processing Mode


MySQL> GRANT ALL ON voipmonitor.* TO 'voipmonitor'@'%' IDENTIFIED BY 'safu3q28n';
  package "Remote Site" {
MySQL> GRANT SUPER ON *.* TO 'voipmonitor'@'%' IDENTIFIED BY 'safu3q28n';
    [Remote Probe/Sensor] as Remote
MySQL> FLUSH PRIVILEGES;
    database "Local Storage (PCAP)" as RemotePCAP
  }


*allow TCP port 5029 on firewall from GUI server
  package "Central Site" {
    [Central VoIPmonitor Server] as Central
    database "Central MySQL/MariaDB" as CentralDB
    [Web GUI] as GUI
  }


'''What you need to configure on central GUI'''
  Remote -[#2F6CB0]-> Central : Encrypted TCP/60024\nCDRs only
  Remote --> RemotePCAP : Stores PCAP locally
  Central --> CentralDB : Writes CDRs
  GUI -[#2F6CB0]-> Central : Queries data & requests PCAPs
  Central -[#2F6CB0]-> RemotePCAP : Fetches PCAPs on demand (TCP/5029)
  @enduml
  </kroki>


*Go to main menu -> Settings -> Sensors -> add sensor ID, IP, port 5029, keep mysql settings blank.
<kroki lang="plantuml">
  @startuml
  skinparam shadowing false
  skinparam defaultFontName Arial
  skinparam rectangle {
    BorderColor #4A90E2
    BackgroundColor #FFFFFF
    stereotypeFontColor #333333
  }
  skinparam packageBorderColor #B0BEC5
  skinparam packageBackgroundColor #F7F9FC


=== Mirroring sniffer ===
  title Client/Server Architecture — Packet Mirroring Mode
Since version 8 remote sensor can be configured as packet sender (mirrorer) to  remote sensor which runs on different server. In this mode the sender sends all packets via compressed TCP stream to remote sniffer like it is sniffing directly on network interface. This setup is common in situation where you are not able to mirror packets directly via port spanning or taping and you need to install it directly on linux server where the PBX/SBC runs and you do not have to enough CPU or storage resources to process all packets there - the sender sensor uses minimal CPU / memory resources.


What you need to configure on remote sniffer (for example remote sniffer has IP 10.0.0.1, central sniffer has IP 192.168.0.1)
  package "Remote Site" {
    [Remote Probe/Sensor\n(Low Resource)] as Remote
  }


voipmonitor.conf:
  package "Central Site" {
[general]
    [Central VoIPmonitor Server] as Central
id_sensor = 1 #change this number on each remote sniffer to unique number
    database "Central MySQL/MariaDB" as CentralDB
interface = eth0 #change this to correct interface where you need to intercept traffic
     database "Central Storage (PCAP)" as CentralPCAP
ringbuffer = 200 #up to 2000MB
    [Web GUI] as GUI
packetbuffer_enable            = yes
  }
max_buffer_mem                  = 2000 #in MB
packetbuffer_compress          = yes #enable compression
packetbuffer_compress_ratio     = 100
mirror_destination_ip          = 192.168.0.1 #this is address of your dedicated server (central sniffer - mirroring receiver)
mirror_destination_port        = 5030


What you need to configure on central sniffer - configure voipmonitor.conf as a standard sniffer + mirror* options :  
  Remote -[#2F6CB0]-> Central : Encrypted TCP/60024\nRaw packet stream
  Central --> CentralDB : Writes CDRs
  Central --> CentralPCAP : Processes & stores PCAPs
  GUI -[#2F6CB0]-> Central : Queries data & downloads PCAPs
  @enduml
  </kroki>


voipmonitor.conf
==== Step-by-Step Configuration Guide ====
mirror_bind_ip              = 192.168.0.1 #set there ip address of central server, which is accessible from remote sniffers.
mirror_bind_port            = 5030


== Moving pcap files ==
; Prerequisites
* VoIPmonitor v20+ on all sensors.
* Central database reachable from the central server instance.
* Unique <code>id_sensor</code> per sensor (< 65536).
* NTP running everywhere (see '''Time Synchronization''' below).


VoIPmonitor sniffer runs directly on asterisk PBX storing pcap files to /var/spool/voipmonitor and moved to /mnt/ssh which is mounted /var/spool/voipmonitor on central WEB GUI. You can use sshfs to mount remote directory over ssh
; Scenario A — Local Processing (default, low WAN usage)
<pre>
# /etc/voipmonitor.conf on the REMOTE sensor (LOCAL PROCESSING)


sshfs root@guiserverIP:/var/spool/voipmonitor /mnt/ssh
id_sensor              = 2          # unique per sensor (< 65536)
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password        = your_strong_password


in voipmonitor.conf on asterisk PBX set
packetbuffer_sender    = no        # local analysis; sends only CDRs
interface              = eth0      # or: interface = any
sipport                = 5060      # example; add your usual sniffer options


cachedir = /var/spool/voipmonitor (or /dev/shm which is ramdisk to save some I/O)
# No MySQL credentials here — remote sensor does NOT write to DB directly.
spooldir = /mnt/ssh
</pre>


= Cloud mode=
<pre>
# /etc/voipmonitor.conf on the CENTRAL server (LOCAL PROCESSING network)


In cloud mode the voipmonitor sniffs and analyzes all packets and sends only complete CDR record (which is around 2kB for one CDR) over the encrypted https channel to the voipmonitor cloud. SIP and RTP packets are stored on local hard drive (if storing packets are enabled in the sniffer configuration) so they are not sent over network to the cloud. The cloud is downloading them from sniffer only on demand when user requests pcap file.  
server_bind            = 0.0.0.0
server_bind_port        = 60024
server_password        = your_strong_password


mysqlhost              = 10.224.0.201
mysqldb                = voipmonitor
mysqluser              = voipmonitor
mysqlpassword          = db_password


cdr_partition          = yes        # partitions for CDR tables
mysqlloadconfig        = yes        # allows DB-driven config if used


interface              =            # leave empty to avoid local sniffing
# The central server will proxy on-demand PCAP fetches to sensors (TCP/5029).
</pre>


; Scenario B — Packet Mirroring (centralized processing/storage)
<pre>
# /etc/voipmonitor.conf on the REMOTE sensor (PACKET MIRRORING)


id_sensor              = 3
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password        = your_strong_password


packetbuffer_sender    = yes        # send RAW packet stream to central
interface              = eth0      # capture source; no DB settings needed
</pre>


<pre>
# /etc/voipmonitor.conf on the CENTRAL server (PACKET MIRRORING)


server_bind            = 0.0.0.0
server_bind_port        = 60024
server_password        = your_strong_password


mysqlhost              = 10.224.0.201
mysqldb                = voipmonitor
mysqluser              = voipmonitor
mysqlpassword          = db_password


cdr_partition          = yes
mysqlloadconfig        = yes


# As this server does all analysis, configure as if sniffing locally:
sipport                = 5060
# ... add your usual sniffer/storage options (pcap directories, limits, etc.)
</pre>


==== Firewall Checklist (Quick Reference) ====
* '''Modern Client/Server (v20+):'''
** '''Central Server:''' Allow inbound <code>TCP/60024</code> from remote sensors. Allow inbound <code>TCP/5029</code> from GUI (management/API to central sensor).
** '''Remote Sensors (Local Processing only):''' Allow inbound <code>TCP/5029</code> from the central server (for on-demand PCAP fetch via proxy). Outbound <code>TCP/60024</code> to the central server.
* '''Cloud Mode:'''
** '''Remote Sensors:''' Allow outbound <code>TCP/60023</code> to <code>cloud.voipmonitor.org</code>.


== Configuration & Checklists ==


=== Parameter Notes (clarifications) ===
* '''<code>id_sensor</code>''' — Mandatory in any distributed deployment (Classic or Client/Server). Must be unique per sensor (< 65536). The value is written to the database and used by the GUI to identify where a call was captured.
* '''<code>cdr_partition</code>''' — In Client/Server, enable on the central server instance that writes to the database. It can be disabled on remote "client" sensors that only mirror packets.
* '''<code>mysqlloadconfig</code>''' — When enabled, the sensor can load additional parameters dynamically from the <code>sensor_config</code> table in the database. Typically enabled on the central server sensor that writes to DB; keep disabled on remote clients which do not access DB directly.
* '''<code>interface</code>''' — Use a specific NIC (e.g., <code>eth0</code>) or <code>any</code> to capture from multiple NICs. For <code>any</code> ensure promiscuous mode on each NIC.


=== Initial Service Start & Database Initialization ===
After installation, the '''first startup''' against a new/empty database is critical.
# Start the service: <code>systemctl start voipmonitor</code>
# Follow logs to ensure schema/partition creation completes:
#* <code>journalctl -u voipmonitor -f</code>
#* or <code>tail -f /var/log/syslog | grep voipmonitor</code>


You should see creation of functions and partitions shortly after start. If you see errors like <code>Table 'cdr_next_1' doesn't exist</code>, the sensor is failing to initialize the schema — usually due to insufficient DB privileges or connectivity. Fix DB access and restart the sensor so it can finish initialization.


=== 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 (e.g., <code>chrony</code> or <code>ntpdate</code>) to keep clocks in sync.


== 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''' (central proxies PCAP fetch)
|-
| '''Modern Client/Server (Packet Mirroring)'''
| '''Central'''
| '''Central'''
| High (Encrypted full packets)
| '''GUI ↔ Central Server only'''
|}


== FAQ & Common Pitfalls ==
* '''Do remote sensors need DB credentials in Client/Server?''' No. Only the central server instance writes to DB.
* '''Why is <code>id_sensor</code> required everywhere?''' The GUI uses it to tag and filter calls by capture source.
* '''Local Processing still fetches PCAPs from remote — who connects to whom?''' The GUI requests via the central server; the central server then connects to the remote sensor's <code>TCP/5029</code> to retrieve the PCAP.


 
== 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, PCAPs remain remote with central-proxied fetch) and packet mirroring (sending full, raw packets for central processing), which is ideal for low-resource endpoints. The guide concludes with step-by-step configuration, firewall rules, critical parameter notes, and the importance of NTP plus first-start DB initialization.
 
'''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 (<code>packetbuffer_sender</code>) 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 13:52, 3 November 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 RSPAN. 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., ip link set dev eth1 promisc on).

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 cloud 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/MariaDB database to write CDRs. For PCAP retrieval the GUI typically needs network access to each sensor's management port (default TCP/5029).
  • 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+) — Recommended

This model uses a secure, encrypted TCP channel between remote sensors (clients) and a central sensor instance (server). The GUI communicates with the central server only, which significantly simplifies networking and security.

This architecture supports two primary modes:

  1. Local Processing: Remote sensors process packets locally and send only lightweight CDR data over the encrypted channel. PCAPs remain on the remote sensor. On-demand PCAP fetch is proxied via the central server (to the sensor's TCP/5029).
  2. Packet Mirroring: Remote sensors forward the entire raw packet stream to the central server, which performs all processing and storage. Ideal for low-resource remote sites.

Architecture Diagrams (PlantUML)

Step-by-Step Configuration Guide

Prerequisites
  • VoIPmonitor v20+ on all sensors.
  • Central database reachable from the central server instance.
  • Unique id_sensor per sensor (< 65536).
  • NTP running everywhere (see Time Synchronization below).
Scenario A — Local Processing (default, low WAN usage)
# /etc/voipmonitor.conf on the REMOTE sensor (LOCAL PROCESSING)

id_sensor               = 2          # unique per sensor (< 65536)
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password         = your_strong_password

packetbuffer_sender     = no         # local analysis; sends only CDRs
interface               = eth0       # or: interface = any
sipport                 = 5060       # example; add your usual sniffer options

# No MySQL credentials here — remote sensor does NOT write to DB directly.

# /etc/voipmonitor.conf on the CENTRAL server (LOCAL PROCESSING network)

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

mysqlhost               = 10.224.0.201
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password

cdr_partition           = yes        # partitions for CDR tables
mysqlloadconfig         = yes        # allows DB-driven config if used

interface               =            # leave empty to avoid local sniffing
# The central server will proxy on-demand PCAP fetches to sensors (TCP/5029).
Scenario B — Packet Mirroring (centralized processing/storage)
# /etc/voipmonitor.conf on the REMOTE sensor (PACKET MIRRORING)

id_sensor               = 3
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password         = your_strong_password

packetbuffer_sender     = yes        # send RAW packet stream to central
interface               = eth0       # capture source; no DB settings needed

# /etc/voipmonitor.conf on the CENTRAL server (PACKET MIRRORING)

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

mysqlhost               = 10.224.0.201
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password

cdr_partition           = yes
mysqlloadconfig         = yes

# As this server does all analysis, configure as if sniffing locally:
sipport                 = 5060
# ... add your usual sniffer/storage options (pcap directories, limits, etc.)

Firewall Checklist (Quick Reference)

  • Modern Client/Server (v20+):
    • Central Server: Allow inbound TCP/60024 from remote sensors. Allow inbound TCP/5029 from GUI (management/API to central sensor).
    • Remote Sensors (Local Processing only): Allow inbound TCP/5029 from the central server (for on-demand PCAP fetch via proxy). Outbound TCP/60024 to the central server.
  • Cloud Mode:
    • Remote Sensors: Allow outbound TCP/60023 to cloud.voipmonitor.org.

Configuration & Checklists

Parameter Notes (clarifications)

  • id_sensor — Mandatory in any distributed deployment (Classic or Client/Server). Must be unique per sensor (< 65536). The value is written to the database and used by the GUI to identify where a call was captured.
  • cdr_partition — In Client/Server, enable on the central server instance that writes to the database. It can be disabled on remote "client" sensors that only mirror packets.
  • mysqlloadconfig — When enabled, the sensor can load additional parameters dynamically from the sensor_config table in the database. Typically enabled on the central server sensor that writes to DB; keep disabled on remote clients which do not access DB directly.
  • interface — Use a specific NIC (e.g., eth0) or any to capture from multiple NICs. For any ensure promiscuous mode on each NIC.

Initial Service Start & Database Initialization

After installation, the first startup against a new/empty database is critical.

  1. Start the service: systemctl start voipmonitor
  2. Follow logs to ensure schema/partition creation completes:
    • journalctl -u voipmonitor -f
    • or tail -f /var/log/syslog | grep voipmonitor

You should see creation of functions and partitions shortly after start. If you see errors like Table 'cdr_next_1' doesn't exist, the sensor is failing to initialize the schema — usually due to insufficient DB privileges or connectivity. Fix DB access and restart the sensor so it can finish initialization.

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 (e.g., chrony or ntpdate) to keep clocks in sync.

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 (central proxies PCAP fetch)
Modern Client/Server (Packet Mirroring) Central Central High (Encrypted full packets) GUI ↔ Central Server only

FAQ & Common Pitfalls

  • Do remote sensors need DB credentials in Client/Server? No. Only the central server instance writes to DB.
  • Why is id_sensor required everywhere? The GUI uses it to tag and filter calls by capture source.
  • Local Processing still fetches PCAPs from remote — who connects to whom? The GUI requests via the central server; the central server then connects to the remote sensor's TCP/5029 to retrieve the PCAP.

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, PCAPs remain remote with central-proxied fetch) and packet mirroring (sending full, raw packets for central processing), which is ideal for low-resource endpoints. The guide concludes with step-by-step configuration, firewall rules, critical parameter notes, and the importance of NTP plus first-start DB initialization. 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=5692"