Sniffing modes

Linux host

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.

Hardware port mirroring

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.

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

ifconfig eth1 promisc

Tunneling

Voipmonitor supports several tunneling options:

• IPinIP (out of the box)
• GRE (out of the box)
• ERSPAN (out of the box)
• TZSP (mikrotik) - udp_port_tzsp = 37008 option in voipmonitor.conf
• Layer 2 Tunneling Protocol - udp_port_l2tp = 1701 option in voipmonitor.conf
• VXLAN (used by amazon aws) - udp_port_vxlan = 4789 option in voipmonitor.conf
• audiocodes tunneling - audiocodes, udp_port_audiocodes, tcp_port_audiocodes options in voipmonitor.conf
• HEP3 (requires hep* options enabled in voipmonitor.conf)
• ipfix (tested with ACME / ORACLE SBC, ipfix* options)

Software packet mirroring

All in one

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

Note: sensor = sniffer, sniffer = sensor

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)

Standard remote sniffer

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.

Client/server (aka sender/receiver aka remote/central) remote sniffers

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.

OLD client/server (aka remote/central) sensor mode

• 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)

.