Sniffing modes: Difference between revisions

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


Since version 20.0 there is new encrypted and compressed TCP protocol between sniffers. Here is minimal voipmonitor configuration which leaves all options to default (can be changed)
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.


'''What you need to configure on remote sniffer:'''
==== 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'''
|}


edit file /etc/voipmonitor.conf
== Configuration & Checklists ==


=== Client/Server Configuration Example ===
Below is a minimal configuration for the modern client/server model.


id_sensor = unique_number # must be < 65535
;On each ''Remote Sensor (Client)'':
server_destination = serverip
<pre>
server_destination_port = 60024 #can be any port server_password = somepassword
# /etc/voipmonitor.conf on the remote sensor


this example configuration will process packets and sends only CDR to the server. If you want to mirror all packets (so the remote sniffer will not use much CPU and memory) add one more option:
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


packetbuffer_sender = yes  
# Optional: Uncomment the next line to enable packet mirroring mode
# packetbuffer_sender   = yes
</pre>


;On the ''Central Server'':
<pre>
# /etc/voipmonitor.conf on the central server


'''What you need to configure on 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
</pre>


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


=== 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 ==
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 you should see in GUI'''
* What is the difference between the classic remote sensor and the modern client/server mode?
The GUI will automatically add sensors in Main menu -> Settings -> Sensors
* When should I use packet mirroring (packetbuffer_sender) instead of local processing?
The advantage of this new protocol is that remote sniffers can be used behind NAT - the GUI communicates with remote sniffers over the TCP protocol, the protocol is encrypted and compressed.
* 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?
== Moving pcap files ==
* What is a SPAN port and how is it used with VoIPmonitor?
 
* Why is NTP important for a distributed VoIPmonitor setup?
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
 
sshfs root@guiserverIP:/var/spool/voipmonitor /mnt/ssh
 
in voipmonitor.conf on asterisk PBX set  
 
cachedir = /var/spool/voipmonitor (or /dev/shm which is ramdisk to save some I/O)
spooldir = /mnt/ssh
 
= Cloud mode=
 
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.
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.

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"