Sniffing modes
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:
- 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.
- 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.