Sniffing modes: Difference between revisions

From VoIPmonitor.org
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
= Linux host =  
= VoIPmonitor Deployment 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.  
== Overview ==
VoIPmonitor can run '''on the same host''' as your PBX/SBC or on a '''dedicated sensor''' that receives mirrored traffic.
This page lists supported deployment models, tunnelling methods, firewall rules and minimal configuration examples.


= Hardware port mirroring =
== Linux host capture ==
Running the sniffer directly on a PBX/SBC requires '''no extra hardware''' or topology changes, but adds CPU / RAM / I/O load to that host. 
If sharing resources is unacceptable, use hardware or software mirroring instead.


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.
== Hardware port mirroring ==
Port-mirroring (SPAN, RAP…) on your switch sends a copy of selected traffic to a dedicated Linux box running VoIPmonitor.
The sniffer interface is set to promiscuous mode automatically; to capture on multiple ports set <code>interface = any</code> and 
enable promiscuous mode on each NIC manually:
  ifconfig eth1 promisc


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
== Tunnelling options ==
* IP-in-IP, GRE, ERSPAN – built-in 
* TZSP (Mikrotik) → <code>udp_port_tzsp = 37008</code> 
* L2TP → <code>udp_port_l2tp = 1701</code> 
* VXLAN (AWS) → <code>udp_port_vxlan = 4789</code> 
* [[audiocodes tunneling]] → <code>udp_port_audiocodes</code> / <code>tcp_port_audiocodes</code> 
* HEP3 → enable <code>hep*</code> options 
* IPFIX (Oracle SBC) → <code>ipfix*</code> options 


  ifconfig eth1 promisc
== Software packet mirroring ==
=== All-in-one ===
When the sniffer, MySQL and GUI share a host, the GUI reads PCAPs locally and connects to MySQL over <code>localhost</code>.  
No sensor records are required in the GUI.


= Tunneling =
=== Multiple remote sensors, one DB / GUI ===
A '''sensor''' (a.k.a. sniffer / probe) can operate in two main ways:
# '''Standard remote sniffer''' – processes packets locally, stores PCAPs locally, sends only CDRs to MySQL. GUI connects directly to each sensor’s management port. 
# '''New client / server mode (v20+)''' – encrypted TCP channel between sensor and a '''central sniffer'''. 
  * Sensor can process packets locally and send only CDRs, '''or''' 
  * mirror packets to the central sniffer for processing. 
  GUI talks only to the central sniffer; sensors can stay behind NAT.


Voipmonitor supports several tunneling options:
;Summary of remote deployment modes
{| class="wikitable"
! Deployment
! Packet processing
! PCAP storage
! Traffic to DB
! GUI connectivity
|-
| Standard remote sniffer
| Remote
| Remote
| Minimal (CDR only)
| GUI&nbsp;↔&nbsp;sensor (management port)
|-
| New client/server&nbsp;(v20+) – '''local processing'''
| Remote
| Remote
| Encrypted&nbsp;TCP (CDR only)
| GUI&nbsp;↔&nbsp;central sniffer
|-
| New client/server&nbsp;(v20+) – '''packet mirroring'''
| Central
| Central
| Encrypted&nbsp;TCP (full packets)
| GUI&nbsp;↔&nbsp;central sniffer
|}


*IPinIP (out of the box)
=== New client / server configuration ===
*GRE (out of the box)  
''client (remote) example''
*ERSPAN (out of the box)
  id_sensor              = <unique < 65536>
*TZSP (mikrotik) - udp_port_tzsp = 37008 option in voipmonitor.conf
  server_destination      = <central-IP>
*Layer 2 Tunneling Protocol - udp_port_l2tp = 1701 option in voipmonitor.conf
  server_destination_port = 60024
*VXLAN (used by amazon aws) - udp_port_vxlan = 4789 option in voipmonitor.conf
  server_password        = somepassword
*[[audiocodes tunneling]] - audiocodes, udp_port_audiocodes, tcp_port_audiocodes options in voipmonitor.conf
  ; uncomment next line to send full packet stream instead of local processing
*HEP3 (requires hep* options enabled in voipmonitor.conf)
  ; packetbuffer_sender  = yes
*ipfix (tested with ACME / ORACLE SBC, ipfix* options)


= Software packet mirroring =
''server (central) example''
  server_bind            = 0.0.0.0
  server_bind_port        = 60024
  server_password        = somepassword
  ; remember to set mysql* options


== All in one ==
Connection uses DH key-exchange + AES encryption and compression. 
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.  
Sensors appear automatically in '''GUI → Settings → Sensors'''.


== Multiple remote sensors one DB/GUI server ==
== Cloud mode ==
  id_sensor              = <unique>
  cloud_token            = __your_token__
  cloud_url              = https://cloud.voipmonitor.org/reg/register.php
  packetbuffer_file_path = /var/spool/voipmonitor/packetbuffer


Note: sensor = sniffer, sniffer = sensor
== Firewall checklist ==
* '''New client/server''' – central: 60024/TCP (probes) + 60024/TCP & 5029/TCP (GUI) 
* '''Old mirroring''' – central: 5030/TCP (probes) + 5029/TCP (GUI) 
* '''Standalone''' – DB: 3306/TCP (sensors) 
* '''Cloud''' – probes → cloud.voipmonitor.org :60023/TCP


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)
== Time synchronisation ==
All machines should run NTP with <code>minpoll 3</code> and <code>maxpoll 4</code>. Clock drift breaks call-leg correlation.


=== Standard remote sniffer ===
== Migration hints ==
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.
You may run two instances on the same host (one with legacy <code>mirror_bind_ip</code>, one with new <code>server_bind</code>) by giving each:
* its own <code>id_sensor</code>, <code>managerport</code>, <code>spooldir</code>
* a separate init script and/or binary


=== Client/server (aka sender/receiver aka remote/central) remote sniffers ===
== Why choose the new mode? ==
The sensors can sniff the packets on one host and process them on another host. There are two modes. The old mode (for compatibility reason, the existing users should migrate slowly to the new one) and the new mode (since version 20.0 of a sniffer, the new users should use this one). All voipmonitor configuration examples are minimal which leaves all options to default (can be changed). Don't mix old and new modes in one environment.
* Encrypted, compressed transport 
* One MySQL user on the central sniffer instead of many on each probe 
* GUI needs access only to the central sniffer, not to every probe 
* Optional off-loading of CPU/RAM from remote probes by mirroring packets 


=== OLD client/server (aka remote/central) sensor mode ===
For more details about multi-instance setups, contact support@voipmonitor.org.
 
* uses two type of sensors: server/central and client/remote
* uses mirror_* directives in configuration
* server and client must have the same time
 
'''client/remote sensor'''
* sniff data, NO processing of this data
* 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:
#change this number on each remote sniffer to unique number
id_sensor                      = 1         
#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'''
* has direct access to the sql
* has local storage
* receives sniffed data from clients, process them, saves cdrs to the sql and stores pcaps to the local spooldir
* management port needs to be accessible from gui
* sensor is NOT created automatically in gui/db
* gui communicates with sensor directly via management port
 
voipmonitor.conf:
#do not forget to configure mysql* options
#set here IP address of central server, which is accessible from remote sniffers.
mirror_bind_ip              = 0.0.0.0
mirror_bind_port            = 5030
 
=== NEW client/server (aka remote/central) sensor mode ===
* has two type of sensors: server(central) and client(remote)
* prerequisite is GNU/GPL sniffer version >= 20.x on both ends and version of a GUI >= 18.3 which is supporting also multiple receivers.
* this mode uses server_* options in voipmonitor.conf
* server and client must have the same time (ideally use NTP on both server/client or connection from remote will be refused)
 
Remote sniffers can operate in two ways:
 
* packets are sniffed and processed on remote sniffers which uses CPU/memory, sends CDR to central sniffer and stores pcap files on local storage.
* OR packets are sniffed and sent to central sniffer which process them (does not use much CPU/memory but uses more network throughput)
 
 
this mode is controlled by packetbuffer_sender option ("yes" will send packets to central sniffer).
 
* mysql configuration is set only on server(central) configuration
* Server(central) sniffer communicates with remote sniffers through TCP connection. Client is connecting to the server so it can be behind firewall/NAT etc.
* GUI communicates ONLY with the central server. If GUI wants to get pcap from remote sniffer it requests it from the central sniffer which contacts client sniffer (so there is no direct TCP connection to a client sniffers)
* Remote sensors are populated in GUI configuration automatically once remote sniffer is connected to a central sniffer.
* Connection between client/server uses strong encryption (DH key exchange / AES cypher) with compression.
* The server's managerport and server_bind_port ports need to be accessible from the GUI.
 
==== client(remote) sensor configuration ====
 
# this example configuration will process packets and sends only CDR to the server.
# id_Sensor needs to be < 65536
id_sensor = unique_number
server_destination = serverip
#needs to be defined same as server_bind_port option on the central server
server_destination_port = 60024
server_password = somepassword
#If you want to mirror all packets (so the remote sniffer will not use much CPU and memory and NO local storage) add one more option:
packetbuffer_sender = yes
 
==== server(central) sensor configuration ====
#this will listen on all IPs
server_bind = 0.0.0.0
server_bind_port = 60024
server_password = somepassword
#do not forget to configure mysql* options
 
=== cloud mode - client sensor mode ===
 
in my services section you can download install script that will add options into default voipmonitor.conf
(you don't need to take care on the cloud* options - the cloud install script will add these.)
 
# id_Sensor needs to be unique number < 65536
id_sensor = unique_number
cloud_token = __Your_cloud_token_here__
cloud_url = https://cloud.voipmonitor.org/reg/register.php
packetbuffer_file_path = /var/spool/voipmonitor/packetbuffer
 
 
= Firewall settings =
== For new client/server mode ==
* You need to allow port 60024{tcp} on the server to be accessible by all probes.
* You need to allow port 60024{tcp} and '''managerport''' 5029{tcp} on the server to be accessible by GUI host. (if the GUI is on another host, modify '''managerip''' option on server side which binds by default to localhost only)
 
== For old mirroring mode ==
* You need to allow port 5030{tcp} on the server to be accessible by all probes.
* You need to allow port '''managerport''' 5029{tcp} on the server to be accessible by GUI host. If the GUI is on another server, modify '''managerip''' option on the server side, which binds by default to localhost only)
 
== For standalone mode ==
* You need to allow port 3306{tcp} on the db server to be accessible by all standalone remotes.
* If the GUI is on another host, modify '''managerip''' option on the server side, which binds by default to localhost only.
 
== For cloud mode ==
* You need to allow port 60023{tcp} of cloud.voipmonitor.org to be accessible by probes.
 
= NTP server tweak =
 
It is recommended that all machines are synchronised with NTP with minpoll (3) and maxpoll (4) setting
 
 
 
 
= Details/Hints =
The following describes the advantages of the new client/server mode in comparison to the standalone/old (mirror) probe configuration.
 
== History ==
Before the implementation of the new client/server mode, the options were:
* To mirror packets from the probe to the central ('''mirror_destination''') - the traffic between the probe and server is not encrypted and can be compressed (unlike in the new client-server mode where the traffic is encrypted).
* To use a standalone sniffer - each creating a separate connection to the database and analyzing packets locally, storing packet dumps locally, and sending CDRs directly to the database. However, this method requires setting up new users in MySQL for the sniffer instances to be able to push CDRs there directly.
 
Both modes above require setting the '''managerip''' and '''managerport''' options for each probe and server, and making it accessible from the GUI's host.
 
== Current ==
The new client/server mode allows you to choose whether packets should be processed locally ('''packetbuffer_sender=no''') or if the packets should be sent to the destination server ('''packetbuffer_sender=yes''').
* Save resources on the probe host
* Or to allow merging all the legs from more probes under a single CDR on the server side.
 
Additionally, in the new client/server mode, you only need one MySQL user.
* CDRs from all clients connected to a server instance are pushed by this server instance to a database
* The managerip, managerport does not need to be enabled to listen publicly on the probes, only on the server instance - because the stats/files are gathered by the GUI using the server's connection
 
Unlike when standard/standalone instances are used, or the instances with mirror_destination option enabled, the GUI is asking the probes directly using managerip/managerport) connection which makes it harder for hosts behind NAT.
 
== Mix ==
When you wish to migrate '''mirror_bind_ip'''(old) to '''server_bind'''(new) settings for a lot of probes:
 
You can run
* one server instance that will have '''server_bind''' enabled
* and another server instance on the same host that will have '''mirror_bind_ip''' enabled.
 
Each instance needs to have a separate '''config file''', with unique
* id_sensor
* managerport
* spooldir
* it is also recommended to use separate /etc/init.d/voipmonitor = init file and separate /usr/sbin/voipmonitor binary file
 
Then in the GUI you need to enable '''is server''' in client/server mode for these instances in GUI->Settings->Sensors - double click on each instance and enable 'is server'.
 
(For more details on how to run more instances on a single host ask support@voipmonitor.org)
 
All new probes connected to the server side will automatically appear in GUI->Settings->Sensors (you can rename it), but the probes that are running old type of settings require you to set managerip:manageport accessible from the GUI host and require you to configure records manually in GUI->Settings->Sensors for the GUI.
 
== Conclusion ==
The new client/server mode makes probes much easier to configure (additionally allows you to override the settings in config file /etc/voipmonitor.conf for the probes directly using GUI->Settings->Sensors (wrench icon)
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.

Revision as of 00:25, 23 June 2025

VoIPmonitor Deployment Guide

Overview

VoIPmonitor can run on the same host as your PBX/SBC or on a dedicated sensor that receives mirrored traffic. This page lists supported deployment models, tunnelling methods, firewall rules and minimal configuration examples.

Linux host capture

Running the sniffer directly on a PBX/SBC requires no extra hardware or topology changes, but adds CPU / RAM / I/O load to that host. If sharing resources is unacceptable, use hardware or software mirroring instead.

Hardware port mirroring

Port-mirroring (SPAN, RAP…) on your switch sends a copy of selected traffic to a dedicated Linux box running VoIPmonitor. The sniffer interface is set to promiscuous mode automatically; to capture on multiple ports set interface = any and enable promiscuous mode on each NIC manually: 

 ifconfig eth1 promisc

Tunnelling options

  • IP-in-IP, GRE, ERSPAN – built-in
  • TZSP (Mikrotik) → udp_port_tzsp = 37008
  • L2TP → udp_port_l2tp = 1701
  • VXLAN (AWS) → udp_port_vxlan = 4789
  • audiocodes tunneling → udp_port_audiocodes / tcp_port_audiocodes
  • HEP3 → enable hep* options
  • IPFIX (Oracle SBC) → ipfix* options

Software packet mirroring

All-in-one

When the sniffer, MySQL and GUI share a host, the GUI reads PCAPs locally and connects to MySQL over localhost. No sensor records are required in the GUI.

Multiple remote sensors, one DB / GUI

A sensor (a.k.a. sniffer / probe) can operate in two main ways:

  1. Standard remote sniffer – processes packets locally, stores PCAPs locally, sends only CDRs to MySQL. GUI connects directly to each sensor’s management port.
  2. New client / server mode (v20+) – encrypted TCP channel between sensor and a central sniffer.
  * Sensor can process packets locally and send only CDRs, or  
  * mirror packets to the central sniffer for processing.  
  GUI talks only to the central sniffer; sensors can stay behind NAT.
Summary of remote deployment modes
Deployment Packet processing PCAP storage Traffic to DB GUI connectivity
Standard remote sniffer Remote Remote Minimal (CDR only) GUI ↔ sensor (management port)
New client/server (v20+) – local processing Remote Remote Encrypted TCP (CDR only) GUI ↔ central sniffer
New client/server (v20+) – packet mirroring Central Central Encrypted TCP (full packets) GUI ↔ central sniffer

New client / server configuration

client (remote) example 

 id_sensor               = <unique < 65536>
 server_destination      = <central-IP>
 server_destination_port = 60024
 server_password         = somepassword
 ; uncomment next line to send full packet stream instead of local processing
 ; packetbuffer_sender   = yes

server (central) example 

 server_bind             = 0.0.0.0
 server_bind_port        = 60024
 server_password         = somepassword
 ; remember to set mysql* options

Connection uses DH key-exchange + AES encryption and compression. Sensors appear automatically in GUI → Settings → Sensors.

Cloud mode

 id_sensor              = <unique>
 cloud_token            = __your_token__
 cloud_url              = https://cloud.voipmonitor.org/reg/register.php
 packetbuffer_file_path = /var/spool/voipmonitor/packetbuffer

Firewall checklist

  • New client/server – central: 60024/TCP (probes) + 60024/TCP & 5029/TCP (GUI)
  • Old mirroring – central: 5030/TCP (probes) + 5029/TCP (GUI)
  • Standalone – DB: 3306/TCP (sensors)
  • Cloud – probes → cloud.voipmonitor.org :60023/TCP

Time synchronisation

All machines should run NTP with minpoll 3 and maxpoll 4. Clock drift breaks call-leg correlation.

Migration hints

You may run two instances on the same host (one with legacy mirror_bind_ip, one with new server_bind) by giving each:

  • its own id_sensor, managerport, spooldir
  • a separate init script and/or binary

Why choose the new mode?

  • Encrypted, compressed transport
  • One MySQL user on the central sniffer instead of many on each probe
  • GUI needs access only to the central sniffer, not to every probe
  • Optional off-loading of CPU/RAM from remote probes by mirroring packets

For more details about multi-instance setups, contact support@voipmonitor.org.

Retrieved from "https://www.voipmonitor.org//doc/index.php?title=Sniffing_modes&oldid=5287"