Sniffer distributed architecture: Difference between revisions

From VoIPmonitor.org
(Fix: Replace non-existent Note/Warning templates with plain text)
(Update to modern Client-Server architecture with packetbuffer_sender, mark mirror_destination as legacy)
Line 1: Line 1:
{{DISPLAYTITLE:Distributed Architecture: Client-Server and Mirroring}}
{{DISPLAYTITLE:Distributed Architecture: Client-Server Mode}}


This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture.
This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture using the modern Client-Server mode.


== Overview ==
== Overview ==


VoIPmonitor supports three distributed deployment modes:
VoIPmonitor v20+ uses a '''Client-Server architecture''' for distributed deployments. Remote sensors connect to a central server via encrypted TCP channel.


{| class="wikitable"
{| class="wikitable"
|-
|-
! Mode !! What is sent !! Use case
! Mode !! What is sent !! Processing location !! Use case
|-
|-
| '''Client-Server''' || CDRs (call records) || Multiple sites → central database
| '''Local Processing''' || CDRs only || Remote sensor || Multiple sites, low bandwidth
|-
|-
| '''Packet Mirroring''' || Raw packets || Central analysis, SIP+RTP merging
| '''Packet Mirroring''' || Raw packets || Central server || Centralized analysis, low-resource remotes
|-
| '''Hybrid Chain''' || CDRs or packets || Multi-tier (workaround, not recommended)
|}
|}


== Client-Server Mode (Recommended) ==
The mode is controlled by a single option: <code>packetbuffer_sender</code>


Multiple sensors send CDRs to a central server. This is the standard architecture for multi-site deployments.
For comprehensive deployment options including on-host vs dedicated sensors, traffic forwarding methods (SPAN, GRE, TZSP, VXLAN), and NFS/SSHFS alternatives, see [[Sniffing_modes|VoIPmonitor Deployment & Topology Guide]].
 
== Client-Server Mode ==
 
=== Architecture ===


<kroki lang="plantuml">
<kroki lang="plantuml">
Line 31: Line 33:
}
}


rectangle "Sensor A" as A
rectangle "Remote Sensor A" as A
rectangle "Sensor B" as B
rectangle "Remote Sensor B" as B
rectangle "Central Server" as S
rectangle "Central Server" as S
database "MySQL" as DB
database "MySQL" as DB


A -down-> S : CDRs
A -down-> S : encrypted TCP/60024
B -down-> S : CDRs
B -down-> S : encrypted TCP/60024
S -right-> DB
S -right-> DB : CDRs


note bottom of A : PCAPs stored locally
note bottom of S
note bottom of B : PCAPs stored locally
  packetbuffer_sender=no → receives CDRs
  packetbuffer_sender=yes → receives raw packets
end note
@enduml
@enduml
</kroki>
</kroki>
Line 47: Line 51:
=== Configuration ===
=== Configuration ===


'''On each sensor (client):'''
'''Remote Sensor (client):'''
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
server_destination = central.server.ip
id_sensor              = 2                    # unique per sensor
server_destination     = central.server.ip
server_destination_port = 60024
server_destination_port = 60024
server_password = shared_secret
server_password         = your_strong_password
</syntaxhighlight>
 
'''On central server:'''
<syntaxhighlight lang="ini">
server_bind = 0.0.0.0
server_bind_port = 60024
server_password = shared_secret
</syntaxhighlight>
 
=== Data Storage ===
 
* '''CDRs''': Stored in MySQL on central server only
* '''PCAPs''': Stored on each sensor locally (GUI retrieves them via network)
 
'''Note:''' All instances must use the same <code>server_password</code>.


== Packet Mirroring Mode ==
# Choose one:
packetbuffer_sender    = no    # Local Processing: analyze locally, send CDRs
# packetbuffer_sender  = yes    # Packet Mirroring: send raw packets


One sensor forwards raw packets to another for analysis. Useful when you need central packet processing or when SIP and RTP are captured at different locations.
interface              = eth0
 
sipport                = 5060
<kroki lang="plantuml">
# No MySQL credentials needed on remote sensors
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
skinparam rectangle {
  BorderColor #4A90E2
  BackgroundColor #FFFFFF
}
 
rectangle "Sensor A\n(source)" as A
rectangle "Sensor B\n(receiver)" as B
database "MySQL" as DB
 
A -right-> B : raw packets
B -down-> DB : CDRs
 
note bottom of B : Analyzes packets\nStores PCAPs & CDRs
@enduml
</kroki>
 
=== Configuration ===
 
'''On source (Sensor A):'''
<syntaxhighlight lang="ini">
mirror_destination = sensor.b.ip
mirror_destination_port = 5090
</syntaxhighlight>
</syntaxhighlight>


'''On receiver (Sensor B):'''
'''Central Server:'''
<syntaxhighlight lang="ini">
<syntaxhighlight lang="ini">
mirror_bind = 0.0.0.0
server_bind            = 0.0.0.0
mirror_bind_port = 5090
server_bind_port        = 60024
</syntaxhighlight>
server_password        = your_strong_password
 
=== Use Case: SIP + RTP Merging ===


When SIP signaling and RTP media are captured on separate machines, a SIP probe can forward packets to a central server that captures RTP locally:
mysqlhost              = localhost
mysqldb                = voipmonitor
mysqluser              = voipmonitor
mysqlpassword          = db_password


<kroki lang="plantuml">
# If receiving raw packets (packetbuffer_sender=yes on clients):
@startuml
sipport                = 5060
skinparam shadowing false
# ... other sniffer options
skinparam defaultFontName Arial
 
rectangle "SIP Probe" as PROBE
rectangle "Central Server" as SERVER
cloud "RTP Traffic" as RTP
 
PROBE -right-> SERVER : SIP packets
RTP -down-> SERVER : RTP packets
 
note bottom of SERVER : Merges SIP + RTP\ninto complete CDRs
@enduml
</kroki>
 
'''SIP Probe config:'''
<syntaxhighlight lang="ini">
packetbuffer_sender = yes
server_destination = central.server.ip
server_destination_port = 60024
</syntaxhighlight>
</syntaxhighlight>


'''Central Server config:'''
== Local Processing vs Packet Mirroring ==
<syntaxhighlight lang="ini">
server_bind = 0.0.0.0
server_bind_port = 60024
interface = eth0
</syntaxhighlight>
 
The <code>packetbuffer_sender = yes</code> option sends raw packets instead of CDRs.
 
== Hybrid Chain (Workaround) ==
 
'''Warning:''' This configuration is '''not officially supported''' and may break in future releases. Use standard client-server mode when possible.
 
A single sniffer '''cannot''' use both <code>server_bind</code> and <code>server_destination</code> simultaneously. However, you can combine mirroring with client-server mode as a workaround:
 
<kroki lang="plantuml">
@startuml
skinparam shadowing false
skinparam defaultFontName Arial
 
rectangle "Sensor A" as A
rectangle "Sensor B" as B
rectangle "Central Server C" as C
 
A -right-> B : packets\n(mirror)
B -right-> C : CDRs or packets\n(client-server)
@enduml
</kroki>
 
'''Sensor A''' uses <code>mirror_destination</code> → '''Sensor B'''
 
'''Sensor B''' uses <code>mirror_bind</code> + <code>server_destination</code> → '''Server C'''


{| class="wikitable"
{| class="wikitable"
|-
|-
! Sensor B setting !! Result
! !! Local Processing !! Packet Mirroring
|-
|-
| <code>packetbuffer_sender = no</code> || B analyzes packets, sends CDRs to C
| '''<code>packetbuffer_sender</code>''' || <code>no</code> (default) || <code>yes</code>
|-
|-
| <code>packetbuffer_sender = yes</code> || B forwards raw packets to C
| '''Packet analysis''' || On remote sensor || On central server
|-
| '''PCAP storage''' || On remote sensor || On central server
|-
| '''WAN bandwidth''' || Low (CDRs only) || High (full packets)
|-
| '''Remote CPU load''' || Higher || Minimal
|-
| '''Use case''' || Standard multi-site || Low-resource remotes
|}
|}


== Additional Configuration ==
=== PCAP Access in Local Processing Mode ===
 
=== GUI Visibility ===


In client-server mode, only the central server appears in the GUI automatically. To make remote sensors visible (for charts, remote upgrades):
When using Local Processing, PCAPs are stored on remote sensors. The GUI retrieves them via the central server, which proxies requests to each sensor's management port (TCP/5029).


# Go to '''GUI → Settings → Sensors'''
'''Firewall requirements:'''
# Add sensor manually with its <code>manager_ip:manager_port</code>
* Central server must reach remote sensors on TCP/5029
# Ensure <code>manager_aes_key</code> matches the GUI database
* Remote sensors must reach central server on TCP/60024


=== Compression ===
== Data Storage Summary ==


Reduce bandwidth for mirroring:
* '''CDRs''': Always stored in MySQL on central server
* '''PCAPs''':
** Local Processing → stored on each remote sensor
** Packet Mirroring → stored on central server


<syntaxhighlight lang="ini">
== GUI Visibility ==
packetbuffer_compress = yes
packetbuffer_compress_ratio = 100
</syntaxhighlight>


=== SRTP/DTLS Decryption ===
Remote sensors appear automatically when connected. To customize names or configure additional settings:
# Go to '''GUI → Settings → Sensors'''
# Sensors are identified by their <code>id_sensor</code> value


When mirroring encrypted traffic:
== Legacy: Mirror Mode ==


* '''Source sensor''': Include TLS ports in <code>sipport = 5060,5061</code>
'''Note:''' The older <code>mirror_destination</code>/<code>mirror_bind</code> options still exist but the modern Client-Server approach with <code>packetbuffer_sender=yes</code> is preferred as it provides encryption and simpler management.
* '''Receiver sensor''': Configure <code>ssl_ipport</code> and <code>ssl_sessionkey</code> for decryption


== Limitations ==
== Limitations ==


* <code>server_bind</code> and <code>server_destination</code> cannot coexist in one instance
* All sensors must use the same <code>server_password</code>
* Hybrid chain is a workaround, not officially supported
* A single sniffer cannot be both server and client simultaneously
* All clients share the same password (no per-client authentication)
* Each sensor requires a unique <code>id_sensor</code> (< 65536)
* PCAP retrieval from remote sensors requires network connectivity to each sensor
* Time synchronization (NTP) is critical for correlating calls across sensors


== AI Summary for RAG ==
== AI Summary for RAG ==
'''Summary:''' VoIPmonitor supports distributed deployments using client-server mode (sensors send CDRs to central server), packet mirroring mode (sensors forward raw packets), or hybrid chain (workaround combining both). In client-server mode, CDRs are stored centrally while PCAPs remain on each sensor. Packet mirroring is useful for central packet analysis or merging SIP signaling with RTP media captured at different locations using <code>packetbuffer_sender=yes</code>. The hybrid chain workaround uses <code>mirror_bind</code> + <code>server_destination</code> on an intermediate sensor but is not officially supported.
'''Summary:''' VoIPmonitor v20+ uses Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP (port 60024). Two modes are available: Local Processing (<code>packetbuffer_sender=no</code>) where sensors analyze packets locally and send only CDRs, or Packet Mirroring (<code>packetbuffer_sender=yes</code>) where sensors forward raw packets to the central server for processing. CDRs are always stored centrally; PCAPs are stored on remote sensors in Local Processing mode or centrally in Packet Mirroring mode. The legacy <code>mirror_destination</code>/<code>mirror_bind</code> approach is superseded by the modern Client-Server mode.
'''Keywords:''' distributed architecture, client-server, mirror mode, server_destination, server_bind, mirror_destination, mirror_bind, packetbuffer_sender, SIP probe, RTP merging, hybrid chain, multi-site, central server, remote sensors
'''Keywords:''' distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, central server, multi-site, encrypted channel
'''Key Questions:'''
'''Key Questions:'''
* How do I connect multiple VoIPmonitor sensors to a central server?
* How do I connect multiple VoIPmonitor sensors to a central server?
* What is the difference between client-server mode and packet mirroring?
* What is the difference between Local Processing and Packet Mirroring?
* How do I merge SIP and RTP traffic captured on different machines?
* Can a single sniffer be both a server and a client?
* Where are CDRs and PCAP files stored in distributed mode?
* Where are CDRs and PCAP files stored in distributed mode?
* How do I make remote sensors visible in the GUI?
* What is packetbuffer_sender and when should I use it?
* How do I configure remote sensors to send raw packets to central server?

Revision as of 14:26, 4 January 2026


This guide explains how to deploy multiple VoIPmonitor sensors in a distributed architecture using the modern Client-Server mode.

Overview

VoIPmonitor v20+ uses a Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP channel.

Mode What is sent Processing location Use case
Local Processing CDRs only Remote sensor Multiple sites, low bandwidth
Packet Mirroring Raw packets Central server Centralized analysis, low-resource remotes

The mode is controlled by a single option: packetbuffer_sender

For comprehensive deployment options including on-host vs dedicated sensors, traffic forwarding methods (SPAN, GRE, TZSP, VXLAN), and NFS/SSHFS alternatives, see VoIPmonitor Deployment & Topology Guide.

Client-Server Mode

Architecture

Configuration

Remote Sensor (client): 

id_sensor               = 2                    # unique per sensor
server_destination      = central.server.ip
server_destination_port = 60024
server_password         = your_strong_password

# Choose one:
packetbuffer_sender     = no     # Local Processing: analyze locally, send CDRs
# packetbuffer_sender   = yes    # Packet Mirroring: send raw packets

interface               = eth0
sipport                 = 5060
# No MySQL credentials needed on remote sensors

Central Server: 

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password

mysqlhost               = localhost
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password

# If receiving raw packets (packetbuffer_sender=yes on clients):
sipport                 = 5060
# ... other sniffer options

Local Processing vs Packet Mirroring

Local Processing Packet Mirroring
packetbuffer_sender no (default) yes
Packet analysis On remote sensor On central server
PCAP storage On remote sensor On central server
WAN bandwidth Low (CDRs only) High (full packets)
Remote CPU load Higher Minimal
Use case Standard multi-site Low-resource remotes

PCAP Access in Local Processing Mode

When using Local Processing, PCAPs are stored on remote sensors. The GUI retrieves them via the central server, which proxies requests to each sensor's management port (TCP/5029).

Firewall requirements:

  • Central server must reach remote sensors on TCP/5029
  • Remote sensors must reach central server on TCP/60024

Data Storage Summary

  • CDRs: Always stored in MySQL on central server
  • PCAPs:
    • Local Processing → stored on each remote sensor
    • Packet Mirroring → stored on central server

GUI Visibility

Remote sensors appear automatically when connected. To customize names or configure additional settings:

  1. Go to GUI → Settings → Sensors
  2. Sensors are identified by their id_sensor value

Legacy: Mirror Mode

Note: The older mirror_destination/mirror_bind options still exist but the modern Client-Server approach with packetbuffer_sender=yes is preferred as it provides encryption and simpler management.

Limitations

  • All sensors must use the same server_password
  • A single sniffer cannot be both server and client simultaneously
  • Each sensor requires a unique id_sensor (< 65536)
  • Time synchronization (NTP) is critical for correlating calls across sensors

AI Summary for RAG

Summary: VoIPmonitor v20+ uses Client-Server architecture for distributed deployments. Remote sensors connect to a central server via encrypted TCP (port 60024). Two modes are available: Local Processing (packetbuffer_sender=no) where sensors analyze packets locally and send only CDRs, or Packet Mirroring (packetbuffer_sender=yes) where sensors forward raw packets to the central server for processing. CDRs are always stored centrally; PCAPs are stored on remote sensors in Local Processing mode or centrally in Packet Mirroring mode. The legacy mirror_destination/mirror_bind approach is superseded by the modern Client-Server mode. Keywords: distributed architecture, client-server, server_destination, server_bind, packetbuffer_sender, local processing, packet mirroring, remote sensors, central server, multi-site, encrypted channel Key Questions:

  • How do I connect multiple VoIPmonitor sensors to a central server?
  • What is the difference between Local Processing and Packet Mirroring?
  • Where are CDRs and PCAP files stored in distributed mode?
  • What is packetbuffer_sender and when should I use it?
  • How do I configure remote sensors to send raw packets to central server?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Sniffer_distributed_architecture&oldid=6481"