Sniffing modes: Difference between revisions

From VoIPmonitor.org
(Rewrite: consolidated structure, removed redundancy, improved tables, kept all essential info)
 
(38 intermediate revisions by 4 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 covers VoIPmonitor deployment options: where to install the sensor, how to forward traffic, and distributed architectures for multi-site monitoring.


= Hardware port mirroring =
<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 15, 'rankSpacing': 30}}}%%
flowchart TB
    START[Where to deploy sensor?] --> Q1{PBX runs on Linux?}
    Q1 -->|Yes| Q2{Spare resources?}
    Q1 -->|No - Windows| DED[Dedicated Sensor]
    Q2 -->|Yes| ONHOST[On-Host Capture]
    Q2 -->|No| DED


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.
    DED --> Q3{Traffic forwarding method?}
    Q3 --> SPAN[SPAN/RSPAN]
    Q3 --> TUNNEL[Software Tunnel]
    Q3 --> CLOUD[Cloud 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
    TUNNEL --> T1[GRE/ERSPAN]
    TUNNEL --> T2[TZSP/VXLAN]
    TUNNEL --> T3[HEP/AudioCodes]
</kroki>


ifconfig eth1 promisc
= Sensor Deployment Options =


= Tunneling =
== On-Host Capture ==


Voipmonitor supports several tunneling options:
Install the sensor directly on the same Linux server as your PBX/SBC.


*IPinIP (out of the box)
{| class="wikitable"
*GRE (out of the box)
! Pros !! Cons
*ERSPAN (out of the box)
|-
*TZSP (mikrotik) - udp_port_tzsp = 37008 option in voipmonitor.conf
| No extra hardware, network changes, or port mirroring required || Adds CPU, memory, and disk I/O load to production voice server
*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
| Simplest setup || Not suitable if resources are critical
*audiocodes tunneling - audiocodes, udp_port_audiocodes, tcp_port_audiocodes options in voipmonitor.conf
|}


= Software packet mirroring =
{{Note|1=VoIPmonitor sensor runs '''exclusively on Linux'''. For Windows-based PBXs (e.g., 3CX Windows edition), you must use a dedicated Linux sensor with traffic mirroring.}}


== All in one ==
== Dedicated Sensor ==
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 ==
A separate Linux server runs only VoIPmonitor. '''Recommended for production environments''' as it isolates monitoring from voice platform resources.


Note: sensor = sniffer, sniffer = sensor
'''When Required:'''
* Windows-based PBXs
* Limited CPU/RAM/disk I/O on PBX server
* Zero monitoring impact needed
* Centralized capture from multiple sites


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)
= Traffic Forwarding Methods =


=== Standard remote sniffer ===
When using a dedicated sensor, you must forward traffic to it using one of these methods.
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 ===
== Hardware Port Mirroring (SPAN/RSPAN) ==
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 ===
Physical or virtual switches copy traffic from source port(s) to a monitoring port.


* uses two type of sensors: server/central and client/remote
=== Physical Switch ===
* uses mirror_* directives in configuration
* server and client must have the same time


'''client/remote sensor'''
Configure your switch to mirror traffic from PBX/SBC ports to the sensor's port. Consult your switch documentation for specific commands.
* 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:
<syntaxhighlight lang="ini">
#change this number on each remote sniffer to unique number
# /etc/voipmonitor.conf
id_sensor                      = 1         
interface = eth0
#change this to correct interface where you need to intercept traffic
sipport = 5060
interface                       = eth0      
savertp = yes
#up to 2000MB more reading about ringbuffer in scaling section of a doc.
</syntaxhighlight>
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'''
{{Tip|To capture from multiple interfaces, set <code>interface = any</code> and enable promiscuous mode on each NIC: <code>ip link set dev eth1 promisc on</code>}}
* 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:
=== VMware/ESXi Virtual Switch ===
#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 ===
For virtualized environments, VMware provides port mirroring at the virtual switch level.
* 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.
* 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:  
'''Standard vSwitch:'''
# In vSphere Client, navigate to ESXi host
# Select virtual switch → Properties/Edit Settings → Enable Port Mirroring
# Set source (SBC VM) and destination (VoIPmonitor VM) ports


* packets are sniffed and processed on remote sniffers which uses CPU/memory, sends CDR to central sniffer and stores pcap files on local storage.
'''Distributed vSwitch:'''
* OR packets are sniffed and sent to central sniffer which process them (does not use much CPU/memory but uses more network throughput)
# In vSphere Web Client → Networking → Select distributed switch
# Configure tab → Port Mirroring → Create mirroring session
# Specify source/destination ports and enable


{{Note|1=Distributed switch mirroring can span multiple ESXi hosts within a cluster.}}


this mode is controlled by packetbuffer_sender option ("yes" will send packets to central sniffer).
=== Multiple VoIP Platforms ===


* mysql configuration is set only on server(central) configuration
Monitor multiple platforms (e.g., Mitel + FreeSWITCH) with a single sensor by mirroring multiple source ports to one destination port.
* 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 ====
'''GUI differentiation:'''
* Filter by IP address ranges
* Filter by number prefixes
* Use separate sensors with unique <code>id_sensor</code> values


# this example configuration will process packets and sends only CDR to the server.
{{Warning|1='''Critical:''' When sniffing from multiple mirrored sources, packets may arrive as duplicates. Add <code>auto_enable_use_blocks = yes</code> to voipmonitor.conf to enable automatic deduplication. See [[Sniffer_configuration#auto_enable_use_blocks|Sniffer_configuration]] for details.}}
# 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 ====
== Software-based Tunneling ==
#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 ===
When hardware mirroring is unavailable, use software tunneling to encapsulate and forward packets.


in my services section you can download install script that will add options into default voipmonitor.conf
{| class="wikitable"
(you don't need to take care on the cloud* options - the cloud install script will add these.)
! Protocol !! Configuration Parameter !! Notes
|-
| IP-in-IP, GRE, ERSPAN || Built-in (auto-detected) || No additional config needed
|-
| TZSP (MikroTik) || <code>udp_port_tzsp = 37008</code> ||
|-
| L2TP || <code>udp_port_l2tp = 1701</code> ||
|-
| VXLAN || <code>udp_port_vxlan = 4789</code> || Common in cloud environments
|-
| AudioCodes || <code>udp_port_audiocodes = 925</code> || See [[Audiocodes_tunneling|AudioCodes Tunneling]]
|-
| IPFIX (Oracle SBCs) || <code>ipfix*</code> options || Enable ipfix options in config
|}


# id_Sensor needs to be unique number < 65536
=== HEP (Homer Encapsulation Protocol) ===
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


Lightweight protocol for mirroring VoIP packets. Supported by Kamailio, OpenSIPS, FreeSWITCH, and many SBCs.


= Firewall settings =
<syntaxhighlight lang="ini">
== For new client/server mode ==
# /etc/voipmonitor.conf
* You need to allow port 60024{tcp} on the server to be accessible by all probes.
hep = yes
* 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)
hep_bind_port = 9060
hep_bind_udp = yes
# Optional: hep_kamailio_protocol_id_fix = yes
</syntaxhighlight>


== For old mirroring mode ==
'''Known Limitations:'''
* 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 ==
{{Warning|1='''HEP Correlation ID Not Supported:''' VoIPmonitor does NOT use HEP correlation ID (captureNodeID) to correlate SIP and RTP packets. If SIP and RTP arrive from different HEP sources, they will NOT be correlated into a single CDR.
* 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 ==
VoIPmonitor correlates using standard SIP Call-ID, To/From tags, and RTP SSRC fields only. Feature request VS-1703 has been logged but there is no workaround currently.}}
* You need to allow port 60023{tcp} of cloud.voipmonitor.org to be accessible by probes.


= NTP server tweak =
'''HEP Timestamp:''' VoIPmonitor uses the HEP timestamp field. If the source has an unsynchronized clock, call timestamps will be incorrect. There is no option to ignore HEP timestamps.


It is recommended that all machines are synchronised with NTP with minpoll (3) and maxpoll (4) setting
'''HEP3 with Port 0:''' Not captured by default. Add port 0 to sipport:


<syntaxhighlight lang="ini">
sipport = 0,5060
</syntaxhighlight>


== Cloud Packet Mirroring ==


Cloud providers offer native mirroring services using VXLAN or GRE encapsulation.


{| class="wikitable"
! Provider !! Service Name
|-
| Google Cloud || Packet Mirroring
|-
| AWS || Traffic Mirroring
|-
| Azure || Virtual Network TAP
|}


'''Configuration Steps:'''


# Create a VoIPmonitor sensor VM in your cloud environment
# Create mirroring policy: select source VMs/subnets, set destination to sensor VM
# '''Critical:''' Capture traffic in '''BOTH directions''' (INGRESS and EGRESS)
# Configure sensor:


<syntaxhighlight lang="ini">
udp_port_vxlan = 4789
interface = eth0
sipport = 5060
</syntaxhighlight>


{{Warning|1=Capturing only ingress or only egress results in incomplete CDRs and broken call data.}}


'''Best Practices:'''
* Filter at source to forward only SIP/RTP ports
* Monitor NIC bandwidth limits
* Account for VXLAN overhead (~50 bytes) - may need jumbo frames
* Ensure NTP sync across all VMs


'''Alternative:''' Consider [[Sniffer_distributed_architecture|Client/Server architecture]] with on-host sensors instead of cloud mirroring for better performance.


== Pre-Deployment Verification ==


For complex setups (RSPAN, ERSPAN, proprietary SBCs), verify compatibility before production deployment:


# Configure test mirroring with a subset of traffic
# Capture test calls with tcpdump: <code>sudo tcpdump -i eth0 -s0 port 5060 -w /tmp/test.pcap</code>
# Verify pcap contains SIP and RTP: <code>tshark -r /tmp/test.pcap -Y "sip || rtp"</code>
# Submit pcap to VoIPmonitor support with hardware/configuration details


= Distributed Architectures =


For multi-site monitoring, sensors can be deployed in various configurations.


== Classic Mode: Standalone Sensors ==


Each sensor operates independently:
* Processes packets and stores PCAPs locally
* Connects directly to central MySQL to write CDRs
* GUI needs network access to each sensor's <code>TCP/5029</code> for PCAP retrieval


'''Alternative: NFS/SSHFS Mounting'''


If TCP/5029 access is blocked, mount remote spool directories on the GUI server:


<syntaxhighlight lang="bash">
# NFS mount
sudo mount -t nfs 10.224.0.101:/var/spool/voipmonitor /mnt/voipmonitor/sensor1


# SSHFS mount
sshfs voipmonitor@10.224.0.101:/var/spool/voipmonitor /mnt/voipmonitor/sensor1
</syntaxhighlight>


Configure GUI: '''Settings > System Configuration > Sniffer data path:'''
<code>/var/spool/voipmonitor:/mnt/voipmonitor/sensor1:/mnt/voipmonitor/sensor2</code>


{{Tip|For NFS, use <code>hard,nofail,tcp</code> mount options for reliability.}}


== Modern Mode: Client/Server (v20+) — Recommended ==


Secure encrypted TCP channel between remote sensors and central server. GUI communicates only with central server.


<kroki lang="mermaid">
%%{init: {'flowchart': {'nodeSpacing': 10, 'rankSpacing': 25}}}%%
flowchart LR
    subgraph "Local Processing"
        R1[Remote Sensor] -->|CDRs only| C1[Central Server]
        R1 -.->|PCAP on demand| C1
    end


    subgraph "Packet Mirroring"
        R2[Remote Sensor] -->|Raw packets| C2[Central Server]
    end
</kroki>


{| class="wikitable"
! Mode !! Processing !! PCAP Storage !! WAN Traffic !! Best For
|-
| '''Local Processing''' (<code>packetbuffer_sender=no</code>) || Remote || Remote || Low (CDRs only) || Limited WAN bandwidth
|-
| '''Packet Mirroring''' (<code>packetbuffer_sender=yes</code>) || Central || Central || High (full packets) || Low-resource remote sites
|}


For detailed configuration, see [[Sniffer_distributed_architecture|Distributed Architecture: Client-Server Mode]].


'''Quick Start - Remote Sensor (Local Processing):'''


<syntaxhighlight lang="ini">
id_sensor              = 2
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password        = your_strong_password
packetbuffer_sender    = no
interface              = eth0
sipport                = 5060
# No MySQL credentials needed - central server writes to DB
</syntaxhighlight>


'''Quick Start - Central Server:'''


<syntaxhighlight lang="ini">
server_bind            = 0.0.0.0
server_bind_port        = 60024
server_password        = your_strong_password
mysqlhost              = 10.224.0.201
mysqldb                = voipmonitor
mysqluser              = voipmonitor
mysqlpassword          = db_password
cdr_partition          = yes
interface              =  # Leave empty - don't sniff locally
</syntaxhighlight>


== Firewall Requirements ==


{| class="wikitable"
! Deployment !! Port !! Direction !! Purpose
|-
| Client/Server || TCP/60024 || Remote → Central || Encrypted CDR/packet channel
|-
| Client/Server || TCP/5029 || Central → Remote || On-demand PCAP fetch (Local Processing mode)
|-
| GUI Access || TCP/5029 || GUI → Central || Management/API
|-
| Cloud Mode || TCP/60023 || Sensor → cloud.voipmonitor.org || Cloud service connection
|}


= Configuration Notes =


== Critical Parameters ==


{| class="wikitable"
! Parameter !! Description !! Notes
|-
| <code>id_sensor</code> || Unique sensor identifier (1-65535) || '''Mandatory''' in distributed deployments
|-
| <code>cdr_partition</code> || Enable daily CDR table partitions || Enable on server writing to DB
|-
| <code>mysqlloadconfig</code> || Load config from database || Enable on central server only
|-
| <code>interface</code> || Capture interface || Use specific NIC or <code>any</code>
|}


== Time Synchronization ==


{{Warning|1=Accurate NTP sync is '''critical''' for correlating call legs across sensors. All servers (GUI, DB, sensors) must run NTP client (chrony or ntpd).}}


== First Startup ==


On first start against empty database:
# Start service: <code>systemctl start voipmonitor</code>
# Monitor logs: <code>journalctl -u voipmonitor -f</code>
# Wait for schema/partition creation to complete


If you see <code>Table 'cdr_next_1' doesn't exist</code> errors, check DB connectivity and privileges.


= Deployment Comparison =


{| class="wikitable"
! Model !! Processing !! PCAP Storage !! WAN Traffic !! GUI Connectivity
|-
| Classic Standalone || Remote || Remote || Minimal (MySQL CDRs) || GUI ↔ each Sensor
|-
| '''Client/Server (Local Processing)''' || Remote || Remote || Minimal (encrypted CDRs) || '''GUI ↔ Central only'''
|-
| '''Client/Server (Packet Mirroring)''' || Central || Central || High (encrypted packets) || '''GUI ↔ Central only'''
|}


= Troubleshooting =


== NFS/SSHFS Connectivity ==


Missing data for specific time periods usually indicates storage server connectivity issues.


{| class="wikitable"
! Symptom !! Likely Cause !! Solution
|-
| Data gap in time period || NFS/SSHFS server unreachable || Check logs for "not responding, timed out"
|-
| Stale file handle || Server rebooted or export changed || Remount NFS share
|-
| Connection resets || Network interruption || Check network stability
|-
| GUI shows "File not found" || Mount point dismounted || Verify mount with <code>mount | grep nfs</code>
|}


<syntaxhighlight lang="bash">
# Check for NFS errors
grep "nfs: server.*not responding" /var/log/syslog
grep "nfs.*timed out" /var/log/syslog


# Verify mount status
mount | grep nfs
stat /mnt/voipmonitor/sensor1
</syntaxhighlight>


= See Also =


* [[Sniffer_distributed_architecture|Distributed Architecture: Client-Server Mode]] - Detailed client/server configuration
* [[Sniffer_troubleshooting|Sniffer Troubleshooting]] - Diagnostic procedures
* [[Audiocodes_tunneling|AudioCodes Tunneling]] - AudioCodes SBC integration
* [[Tls|TLS/SRTP Decryption]] - Encrypted traffic monitoring
* [[Cloud|Cloud Service Configuration]] - Cloud deployment specifics
* [[Scaling|Scaling and Performance Tuning]] - Performance optimization


= AI Summary for RAG =


'''Summary:''' VoIPmonitor deployment guide covering sensor placement (on-host vs dedicated), traffic forwarding methods (SPAN/RSPAN, software tunneling, cloud mirroring), and distributed architectures. Key traffic forwarding options: hardware port mirroring (physical/VMware switches), software tunnels (GRE, ERSPAN, TZSP, VXLAN, HEP, AudioCodes, IPFIX), and cloud provider services (GCP Packet Mirroring, AWS Traffic Mirroring, Azure Virtual Network TAP). CRITICAL HEP LIMITATION: VoIPmonitor does NOT use HEP correlation ID (captureNodeID) - SIP and RTP from different HEP sources will NOT be correlated (feature request VS-1703, no workaround). HEP3 packets with port 0 require adding port 0 to sipport directive. Cloud mirroring requires BIDIRECTIONAL capture (ingress+egress) or CDRs will be incomplete. Distributed architectures: Classic standalone (each sensor writes to central DB, GUI connects to each sensor) vs Modern Client/Server (recommended, encrypted TCP/60024 channel, GUI connects only to central server). Client/Server modes: Local Processing (packetbuffer_sender=no, CDRs only, PCAPs remain remote) vs Packet Mirroring (packetbuffer_sender=yes, full packets sent to central). Alternative for blocked TCP/5029: mount remote spools via NFS/SSHFS, configure multiple paths in GUI Sniffer data path setting. NFS troubleshooting: check for "not responding, timed out" in logs, verify mount status, use hard,nofail,tcp mount options. Critical requirement: NTP sync across all servers.


'''Keywords:''' deployment, topology, on-host, dedicated sensor, SPAN, RSPAN, port mirroring, VMware, vSwitch, dvSwitch, tunneling, GRE, ERSPAN, TZSP, VXLAN, HEP, HEP correlation ID, captureNodeID, VS-1703, HEP port 0, sipport, AudioCodes, IPFIX, cloud mirroring, GCP, AWS, Azure, Packet Mirroring, Traffic Mirroring, ingress, egress, bidirectional, client server, packetbuffer_sender, local processing, packet mirroring, TCP 60024, TCP 5029, NFS, SSHFS, sniffer data path, NTP, time synchronization, id_sensor, cdr_partition


 
'''Key Questions:'''
 
* Should I install VoIPmonitor on my PBX or use a dedicated sensor?
 
* How do I configure port mirroring (SPAN) for VoIPmonitor?
 
* How do I configure VMware/ESXi virtual switch mirroring?
 
* What software tunneling protocols does VoIPmonitor support?
 
* How do I configure HEP (Homer Encapsulation Protocol)?
 
* Does VoIPmonitor use HEP correlation ID to correlate SIP and RTP?
 
* Why are SIP and RTP from different HEP sources not correlated?
 
* How do I capture HEP3 packets with port 0?
 
* How do I configure cloud packet mirroring (GCP/AWS/Azure)?
 
* Why do I get incomplete CDRs with cloud mirroring?
 
* What is the difference between classic and client/server deployment?
 
* What is the difference between local processing and packet mirroring mode?
 
* How do I access PCAPs if TCP/5029 is blocked?
 
* How do I configure NFS/SSHFS for remote spool access?
 
* How do I troubleshoot missing data with NFS mounts?
 
* What firewall ports are required for client/server mode?
 
* Why is NTP important for distributed VoIPmonitor?
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
.

Latest revision as of 16:49, 8 January 2026


This guide covers VoIPmonitor deployment options: where to install the sensor, how to forward traffic, and distributed architectures for multi-site monitoring.

Sensor Deployment Options

On-Host Capture

Install the sensor directly on the same Linux server as your PBX/SBC.

Pros Cons
No extra hardware, network changes, or port mirroring required Adds CPU, memory, and disk I/O load to production voice server
Simplest setup Not suitable if resources are critical

ℹ️ Note: VoIPmonitor sensor runs exclusively on Linux. For Windows-based PBXs (e.g., 3CX Windows edition), you must use a dedicated Linux sensor with traffic mirroring.

Dedicated Sensor

A separate Linux server runs only VoIPmonitor. Recommended for production environments as it isolates monitoring from voice platform resources.

When Required:

  • Windows-based PBXs
  • Limited CPU/RAM/disk I/O on PBX server
  • Zero monitoring impact needed
  • Centralized capture from multiple sites

Traffic Forwarding Methods

When using a dedicated sensor, you must forward traffic to it using one of these methods.

Hardware Port Mirroring (SPAN/RSPAN)

Physical or virtual switches copy traffic from source port(s) to a monitoring port.

Physical Switch

Configure your switch to mirror traffic from PBX/SBC ports to the sensor's port. Consult your switch documentation for specific commands. 

# /etc/voipmonitor.conf
interface = eth0
sipport = 5060
savertp = yes

💡 Tip:

VMware/ESXi Virtual Switch

For virtualized environments, VMware provides port mirroring at the virtual switch level.

Standard vSwitch:

  1. In vSphere Client, navigate to ESXi host
  2. Select virtual switch → Properties/Edit Settings → Enable Port Mirroring
  3. Set source (SBC VM) and destination (VoIPmonitor VM) ports

Distributed vSwitch:

  1. In vSphere Web Client → Networking → Select distributed switch
  2. Configure tab → Port Mirroring → Create mirroring session
  3. Specify source/destination ports and enable

ℹ️ Note: Distributed switch mirroring can span multiple ESXi hosts within a cluster.

Multiple VoIP Platforms

Monitor multiple platforms (e.g., Mitel + FreeSWITCH) with a single sensor by mirroring multiple source ports to one destination port.

GUI differentiation:

  • Filter by IP address ranges
  • Filter by number prefixes
  • Use separate sensors with unique id_sensor values

⚠️ Warning: Critical: When sniffing from multiple mirrored sources, packets may arrive as duplicates. Add auto_enable_use_blocks = yes to voipmonitor.conf to enable automatic deduplication. See Sniffer_configuration for details.

Software-based Tunneling

When hardware mirroring is unavailable, use software tunneling to encapsulate and forward packets.

Protocol Configuration Parameter Notes
IP-in-IP, GRE, ERSPAN Built-in (auto-detected) No additional config needed
TZSP (MikroTik) udp_port_tzsp = 37008
L2TP udp_port_l2tp = 1701
VXLAN udp_port_vxlan = 4789 Common in cloud environments
AudioCodes udp_port_audiocodes = 925 See AudioCodes Tunneling
IPFIX (Oracle SBCs) ipfix* options Enable ipfix options in config

HEP (Homer Encapsulation Protocol)

Lightweight protocol for mirroring VoIP packets. Supported by Kamailio, OpenSIPS, FreeSWITCH, and many SBCs. 

# /etc/voipmonitor.conf
hep = yes
hep_bind_port = 9060
hep_bind_udp = yes
# Optional: hep_kamailio_protocol_id_fix = yes

Known Limitations:

⚠️ Warning: HEP Correlation ID Not Supported: VoIPmonitor does NOT use HEP correlation ID (captureNodeID) to correlate SIP and RTP packets. If SIP and RTP arrive from different HEP sources, they will NOT be correlated into a single CDR.

VoIPmonitor correlates using standard SIP Call-ID, To/From tags, and RTP SSRC fields only. Feature request VS-1703 has been logged but there is no workaround currently.

HEP Timestamp: VoIPmonitor uses the HEP timestamp field. If the source has an unsynchronized clock, call timestamps will be incorrect. There is no option to ignore HEP timestamps.

HEP3 with Port 0: Not captured by default. Add port 0 to sipport: 

sipport = 0,5060

Cloud Packet Mirroring

Cloud providers offer native mirroring services using VXLAN or GRE encapsulation.

Provider Service Name
Google Cloud Packet Mirroring
AWS Traffic Mirroring
Azure Virtual Network TAP

Configuration Steps:

  1. Create a VoIPmonitor sensor VM in your cloud environment
  2. Create mirroring policy: select source VMs/subnets, set destination to sensor VM
  3. Critical: Capture traffic in BOTH directions (INGRESS and EGRESS)
  4. Configure sensor:
udp_port_vxlan = 4789
interface = eth0
sipport = 5060

⚠️ Warning: Capturing only ingress or only egress results in incomplete CDRs and broken call data.

Best Practices:

  • Filter at source to forward only SIP/RTP ports
  • Monitor NIC bandwidth limits
  • Account for VXLAN overhead (~50 bytes) - may need jumbo frames
  • Ensure NTP sync across all VMs

Alternative: Consider Client/Server architecture with on-host sensors instead of cloud mirroring for better performance.

Pre-Deployment Verification

For complex setups (RSPAN, ERSPAN, proprietary SBCs), verify compatibility before production deployment:

  1. Configure test mirroring with a subset of traffic
  2. Capture test calls with tcpdump: sudo tcpdump -i eth0 -s0 port 5060 -w /tmp/test.pcap
  3. Verify pcap contains SIP and RTP: tshark -r /tmp/test.pcap -Y "sip || rtp"
  4. Submit pcap to VoIPmonitor support with hardware/configuration details

Distributed Architectures

For multi-site monitoring, sensors can be deployed in various configurations.

Classic Mode: Standalone Sensors

Each sensor operates independently:

  • Processes packets and stores PCAPs locally
  • Connects directly to central MySQL to write CDRs
  • GUI needs network access to each sensor's TCP/5029 for PCAP retrieval

Alternative: NFS/SSHFS Mounting

If TCP/5029 access is blocked, mount remote spool directories on the GUI server: 

# NFS mount
sudo mount -t nfs 10.224.0.101:/var/spool/voipmonitor /mnt/voipmonitor/sensor1

# SSHFS mount
sshfs voipmonitor@10.224.0.101:/var/spool/voipmonitor /mnt/voipmonitor/sensor1

Configure GUI: Settings > System Configuration > Sniffer data path: /var/spool/voipmonitor:/mnt/voipmonitor/sensor1:/mnt/voipmonitor/sensor2

💡 Tip: For NFS, use hard,nofail,tcp mount options for reliability.

Modern Mode: Client/Server (v20+) — Recommended

Secure encrypted TCP channel between remote sensors and central server. GUI communicates only with central server.

Mode Processing PCAP Storage WAN Traffic Best For
Local Processing (packetbuffer_sender=no) Remote Remote Low (CDRs only) Limited WAN bandwidth
Packet Mirroring (packetbuffer_sender=yes) Central Central High (full packets) Low-resource remote sites

For detailed configuration, see Distributed Architecture: Client-Server Mode.

Quick Start - Remote Sensor (Local Processing): 

id_sensor               = 2
server_destination      = 10.224.0.250
server_destination_port = 60024
server_password         = your_strong_password
packetbuffer_sender     = no
interface               = eth0
sipport                 = 5060
# No MySQL credentials needed - central server writes to DB

Quick Start - Central Server: 

server_bind             = 0.0.0.0
server_bind_port        = 60024
server_password         = your_strong_password
mysqlhost               = 10.224.0.201
mysqldb                 = voipmonitor
mysqluser               = voipmonitor
mysqlpassword           = db_password
cdr_partition           = yes
interface               =   # Leave empty - don't sniff locally

Firewall Requirements

Deployment Port Direction Purpose
Client/Server TCP/60024 Remote → Central Encrypted CDR/packet channel
Client/Server TCP/5029 Central → Remote On-demand PCAP fetch (Local Processing mode)
GUI Access TCP/5029 GUI → Central Management/API
Cloud Mode TCP/60023 Sensor → cloud.voipmonitor.org Cloud service connection

Configuration Notes

Critical Parameters

Parameter Description Notes
id_sensor Unique sensor identifier (1-65535) Mandatory in distributed deployments
cdr_partition Enable daily CDR table partitions Enable on server writing to DB
mysqlloadconfig Load config from database Enable on central server only
interface Capture interface Use specific NIC or any

Time Synchronization

⚠️ Warning: Accurate NTP sync is critical for correlating call legs across sensors. All servers (GUI, DB, sensors) must run NTP client (chrony or ntpd).

First Startup

On first start against empty database:

  1. Start service: systemctl start voipmonitor
  2. Monitor logs: journalctl -u voipmonitor -f
  3. Wait for schema/partition creation to complete

If you see Table 'cdr_next_1' doesn't exist errors, check DB connectivity and privileges.

Deployment Comparison

Model Processing PCAP Storage WAN Traffic GUI Connectivity
Classic Standalone Remote Remote Minimal (MySQL CDRs) GUI ↔ each Sensor
Client/Server (Local Processing) Remote Remote Minimal (encrypted CDRs) GUI ↔ Central only
Client/Server (Packet Mirroring) Central Central High (encrypted packets) GUI ↔ Central only

Troubleshooting

NFS/SSHFS Connectivity

Missing data for specific time periods usually indicates storage server connectivity issues.

Symptom Likely Cause Solution
Data gap in time period NFS/SSHFS server unreachable Check logs for "not responding, timed out"
Stale file handle Server rebooted or export changed Remount NFS share
Connection resets Network interruption Check network stability
GUI shows "File not found" Mount point dismounted grep nfs 
# Check for NFS errors
grep "nfs: server.*not responding" /var/log/syslog
grep "nfs.*timed out" /var/log/syslog

# Verify mount status
mount | grep nfs
stat /mnt/voipmonitor/sensor1

See Also

AI Summary for RAG

Summary: VoIPmonitor deployment guide covering sensor placement (on-host vs dedicated), traffic forwarding methods (SPAN/RSPAN, software tunneling, cloud mirroring), and distributed architectures. Key traffic forwarding options: hardware port mirroring (physical/VMware switches), software tunnels (GRE, ERSPAN, TZSP, VXLAN, HEP, AudioCodes, IPFIX), and cloud provider services (GCP Packet Mirroring, AWS Traffic Mirroring, Azure Virtual Network TAP). CRITICAL HEP LIMITATION: VoIPmonitor does NOT use HEP correlation ID (captureNodeID) - SIP and RTP from different HEP sources will NOT be correlated (feature request VS-1703, no workaround). HEP3 packets with port 0 require adding port 0 to sipport directive. Cloud mirroring requires BIDIRECTIONAL capture (ingress+egress) or CDRs will be incomplete. Distributed architectures: Classic standalone (each sensor writes to central DB, GUI connects to each sensor) vs Modern Client/Server (recommended, encrypted TCP/60024 channel, GUI connects only to central server). Client/Server modes: Local Processing (packetbuffer_sender=no, CDRs only, PCAPs remain remote) vs Packet Mirroring (packetbuffer_sender=yes, full packets sent to central). Alternative for blocked TCP/5029: mount remote spools via NFS/SSHFS, configure multiple paths in GUI Sniffer data path setting. NFS troubleshooting: check for "not responding, timed out" in logs, verify mount status, use hard,nofail,tcp mount options. Critical requirement: NTP sync across all servers.

Keywords: deployment, topology, on-host, dedicated sensor, SPAN, RSPAN, port mirroring, VMware, vSwitch, dvSwitch, tunneling, GRE, ERSPAN, TZSP, VXLAN, HEP, HEP correlation ID, captureNodeID, VS-1703, HEP port 0, sipport, AudioCodes, IPFIX, cloud mirroring, GCP, AWS, Azure, Packet Mirroring, Traffic Mirroring, ingress, egress, bidirectional, client server, packetbuffer_sender, local processing, packet mirroring, TCP 60024, TCP 5029, NFS, SSHFS, sniffer data path, NTP, time synchronization, id_sensor, cdr_partition

Key Questions:

  • Should I install VoIPmonitor on my PBX or use a dedicated sensor?
  • How do I configure port mirroring (SPAN) for VoIPmonitor?
  • How do I configure VMware/ESXi virtual switch mirroring?
  • What software tunneling protocols does VoIPmonitor support?
  • How do I configure HEP (Homer Encapsulation Protocol)?
  • Does VoIPmonitor use HEP correlation ID to correlate SIP and RTP?
  • Why are SIP and RTP from different HEP sources not correlated?
  • How do I capture HEP3 packets with port 0?
  • How do I configure cloud packet mirroring (GCP/AWS/Azure)?
  • Why do I get incomplete CDRs with cloud mirroring?
  • What is the difference between classic and client/server deployment?
  • What is the difference between local processing and packet mirroring mode?
  • How do I access PCAPs if TCP/5029 is blocked?
  • How do I configure NFS/SSHFS for remote spool access?
  • How do I troubleshoot missing data with NFS mounts?
  • What firewall ports are required for client/server mode?
  • Why is NTP important for distributed VoIPmonitor?
Retrieved from "https://www.voipmonitor.org/doc/index.php?title=Sniffing_modes&oldid=10156"