TL;DR – Configure Merkari Firewall for VoIP
If you are looking for the best way to configure a Cisco Meraki firewall, here’s a quick rundown:
Put phones in a dedicated voice VLAN and keep voice off noisy data VLANs.
Do not chase “disable SIP ALG” on MX. Meraki MX does not implement SIP ALG.
Keep VoIP on a single WAN uplink per site when you have dual WANs. Use uplink preferences for voice.
Configure traffic shaping so VoIP gets High priority and (optionally) DSCP re-marking, and make sure uplink bandwidth values are accurate.
Treat inbound port forwarding as the exception. Cloud VoIP typically works via outbound stateful flows unless you are hosting something on-prem.
If IDS/IPS or content filtering is enabled, be ready to allowlist or tune if it causes VoIP false positives or resets.
Validate with packet captures from the MX and confirm DSCP markings and jitter/loss during a real call.
If you are looking for the best way to configure a Cisco Meraki firewall for VoIP, the goal is not “open a bunch of ports.” The goal is predictable NAT behavior, clean QoS prioritization under congestion, and removing security features that accidentally disrupt SIP signaling or RTP media.
This guide is written for MSPs, network admins, and VoIP resellers deploying Viirtue cloud VoIP and scaling to many sites. It assumes you are managing Meraki MX appliances in Dashboard and want exact settings, where to click, and why each setting matters.
Table of Contents
What breaks VoIP behind Cisco Meraki firewalls and why
Quick diagnosis
Start by classifying the failure. It determines whether you should look at NAT/firewall, QoS, or a security feature.
Registration fails (phones show “unregistered”)
Usually, DNS, outbound firewall policy, SIP signaling reachability, or upstream filtering.
One-way audio
Almost always RTP return path is blocked, wrong NAT expectations, or asymmetric routing. Meraki calls out that VoIP commonly uses two simultaneous UDP streams, and one direction can fail.
Choppy audio, robotic audio, or drops during busy hours
Congestion and missing QoS, incorrect uplink bandwidth settings, or jitter/loss spikes.
Calls drop after being on hold or “silent”
Idle UDP flow timeout somewhere. On Meraki MX, the UDP timer exists but is not configurable.
Baseline network targets
Use measurable targets before you touch firewall rules.
Baseline targets for business VoIP
One-way latency: ≤ 150 ms (beyond this, conversational quality degrades)
Jitter: ≤ 30 ms
Packet loss: ≤ 1%
If you have Meraki Insight, you can also monitor uplink quality for VoIP with MOS-style scoring, but you still need to fix the underlying jitter/loss and routing issues.
Notable market stat: Zion Market Research reports the global UCaaS market at USD 87.4B in 2024 (market size) and projects growth through 2034.
Common Symptoms to Configure a Cisco Meraki Firewall:
Common symptom | Likely cause | Fix |
|---|---|---|
One-way audio | RTP return traffic blocked, wrong NAT expectation, asymmetric routing | Avoid inbound port forwards unless required; keep voice on a single uplink; capture RTP to confirm both directions |
Calls drop during peak internet usage | No QoS prioritization, uplink bandwidth set wrong | Configure traffic shaping priorities and DSCP; set accurate uplink bandwidth |
Phones register, but calls fail | Firewall rules too restrictive, provider IPs not allowed, DNS/FQDN rule mismatch | Validate outbound allow rules and DNS visibility; use the provider IP list when possible |
Web softphone fails or times out | Content filtering or L7 rules interfering with HTTPS/TLS | Exempt VoIP web apps from filtering; understand SNI-only classification limitations |
Sporadic issues only on dual WAN sites | Voice flows split across uplinks, NAT changes mid-call | Force VoIP to a preferred uplink for consistency |
What this firewall feature does: ALG and SIP helpers
Many VoIP vendors say, “Disable SIP ALG.” On Meraki MX, this is usually a dead end.
Meraki explicitly states that the MX is a stateful firewall and does not have any ALG functionality.
If a PBX or legacy design “requires ALG,” you typically solve it by changing the PBX NAT traversal approach and ensuring predictable routing, not by searching for a non-existent ALG toggle on the MX.
For a VoIP-focused explainer and MSP checklist, see Viirtue’s SIP ALG reference.
Step-by-step: best way to configure a Cisco Meraki firewall for VoIP with Viirtue
Prerequisites
Get these details from your VoIP provider (do not guess):
SIP signaling protocol(s): UDP/TCP and whether SIP-TLS is used
RTP media IP ranges or SBC IPs (ideally per region)
RTP port range and whether symmetric RTP is required
Any required FQDNs for softphone/web clients
Preferred codec list and bandwidth guidance per call (codec-dependent)
Any required DNS SRV records or provisioning URLs
Meraki prerequisites:
Confirm your MX is routing VLANs (or know where inter-VLAN routing occurs).
If the site has dual WAN, plan to pin VoIP to one uplink for stability. Meraki calls this out as prudent and points you to uplink preferences under traffic shaping.
Set uplink bandwidth settings accurately. Meraki notes that QoS prioritization and priority behavior depend on correct throughput settings.
Know your MX firmware major version. Traffic shaping queuing behavior differs by firmware (18.2+ vs 18.1 and lower).
Recommended baseline vs optional hardening (how to think about it)
Recommended baseline: VLAN segregation + QoS + keep security features enabled unless they prove they are breaking traffic.
Optional hardening: Default deny outbound, strict allowlists to provider IPs, IDS/IPS tightening, and selective exclusions for VoIP.
Disable or adjust SIP ALG or helper
Recommended baseline
On Meraki MX, there is no SIP ALG to disable. Meraki states the MX has no ALG functionality.
If your customer also has an ISP router, LTE gateway, or another firewall upstream, that device may have SIP ALG. Disable it there if it is known to break SIP.
What to document for the ticket
“Meraki MX does not implement SIP ALG; the issue is not due to the MX SIP helper.”
UDP and RTP timeouts
Recommended baseline
Do not plan a “Meraki UDP timeout tweak.” Meraki documents that the MX has a UDP timer that cannot be changed.
Instead, ensure endpoints use keepalives and that SIP session timers are configured per vendor guidance (phone or softphone side).
When this matters
If calls drop only during long holds or long silences, you likely have an idle timeout in the path. On MX, you cannot change it, so you must fix it with endpoint keepalives or fix another device in the path that has a short UDP idle timeout.
NAT and firewall rules
Meraki’s model is stateful and default-deny inbound.
Key behaviors to design around
MX allows inbound traffic primarily as return traffic to an established outbound conversation.
In NAT/routed mode, inbound is denied by default unless you configure port forwarding or NAT rules.
Outbound is allowed by default (unless you add rules to restrict it).
Layer 3 firewall rules are stateful, and rules are flow-based (existing flows may not be affected until timeout or reboot).
Recommended baseline design (typical cloud VoIP)
No inbound port forwarding for phones.
Phones and softphones create outbound sessions to Viirtue SBCs, and MX permits return traffic statefully.
Optional hardening (MSP “deny by default” posture)
If you run a “default deny” outbound stance, create explicit allow rules.
Dashboard path
Security & SD-WAN > Configure > Firewall
Copy/paste-ready rule blueprint (edit placeholders):
# OUTBOUND L3 RULES (top-down order matters)
# Goal: allow voice VLAN to Viirtue, keep everything else least-privilege.
1) Allow DNS UDP/TCP src=VOICE_VLAN_SUBNET dst=DNS_RESOLVERS dstPort=53
2) Allow NTP UDP src=VOICE_VLAN_SUBNET dst=NTP_SERVERS dstPort=123
# Signaling (confirm ports/protocols with your provider)
3) Allow SIP/SIP-TLS TCP/UDP src=VOICE_VLAN_SUBNET dst=VIIRTUE_SBC_IPS dstPort=PROVIDER_SIGNALING_PORTS
# Media (confirm RTP range with your provider)
4) Allow RTP UDP src=VOICE_VLAN_SUBNET dst=VIIRTUE_MEDIA_IPS dstPort=PROVIDER_RTP_RANGE
5) Deny Any Any src=VOICE_VLAN_SUBNET dst=Any dstPort=Any (optional "voice VLAN default deny")
Notes
If Viirtue provides multiple SBC IPs, keep them as an allowlist group.
If you attempt FQDN-based firewall rules, Meraki supports FQDN destinations, but it relies on snooping DNS traffic and will not work when DNS is encrypted or not visible to the MX.
DoS and IDS/IPS tuning
Recommended baseline
Keep IDS/IPS enabled if licensing allows, but choose a ruleset aligned to your risk tolerance and performance constraints.
Meraki IDS/IPS is powered by Snort and offers rulesets: Connectivity, Balanced, and Security.
Start with Balanced for a typical SMB, then confirm VoIP traffic is unaffected.
If VoIP breaks after enabling prevention
Check the Security Center and event logs for blocked flows.
If it is a false positive, Meraki notes signatures may be allowlisted, or traffic can be trusted using “trusted traffic exclusions.”
Firmware-dependent behavior
Snort version depends on MX firmware, and Meraki warns that some Snort 2 deployments stop receiving updates after December 18, 2025, with explicit minimum firmware guidance. Treat this as an operational requirement for security posture.
QoS and traffic shaping
This is where Meraki MX deployments succeed or fail under congestion.
Dashboard path
Security & SD-WAN > Configure > SD-WAN & traffic shaping
Required baseline
Set Uplink bandwidth values to real, tested throughput.
Create a shaping rule for VoIP and give it priority.
Meraki’s traffic shaping documentation shows:
Rules are processed in order.
Rules are applied per client flow.
You can set Bandwidth limits, Priority, and DSCP tagging.
Copy/paste-ready shaping policy template:
Rule 1 (VoIP):
- Definition: VoIP & video conferencing
- Bandwidth limit: Ignore network limit
- Priority: High
- DSCP tagging: set per your design (see DSCP section)
Rule 2 (Bulk):
- Definition: Peer-to-peer OR large downloads (your environment)
- Bandwidth limit: Set a cap
- Priority: Low
- DSCP tagging: Do not change
Important Meraki behavior
Meraki reserves Realtime priority for traffic tagged to EF46 only.
Queueing behavior depends on firmware:
18.2 and above: class-based weighted fair queueing with deficit round robin ratios for priority queues
18.1 and lower: strict priority queueing ratios
DSCP marking
You need a clean, end-to-end marking strategy. Decide whether you will:
Trust endpoint markings (phones mark DSCP themselves), or
Re-mark on the MX using traffic shaping DSCP tagging, or
Both (trust internally, re-mark at egress).
DSCP values
EF (Expedited Forwarding) is DSCP 46 per the IANA DSCP registry.
If you choose to mark signaling separately, CS3 is DSCP 24 in the same registry.
Meraki-specific guidance
When you set DSCP tagging in MX traffic shaping, it applies to incoming and outgoing packets for that rule.
QoS prioritization works as intended only if upstream networking also supports QoS.
TLS inspection cautions
This matters most for:
Web softphones
Embedded click-to-call widgets
Any VoIP client using HTTPS, WSS, or TLS-backed APIs
Meraki content filtering is not full TLS decryption
Meraki states it inspects the SNI field of outbound TLS traffic and cannot classify full URLs for HTTPS because payloads are encrypted. Blocking can result in timeouts and browser errors.
Recommended baseline
If you use content filtering, avoid categorization blocks for VoIP-related domains used by softphones and integrations.
If you have any other device doing true TLS interception (secure web gateway/proxy), exempt VoIP signaling and media paths (SIP-TLS, SRTP, WebRTC), or you risk certificate trust failures and broken media negotiation.
Troubleshooting, validation, and best practices to configure a Cisco Meraki firewall
Validation checklist
Run these tests immediately after changes.
A. Network and QoS validation
Confirm voice VLAN exists and phones are actually in it (wired voice VLAN or SSID mapping).
Confirm uplink bandwidth values match reality (speed test off-hours, then set values conservatively).
Start a call and confirm DSCP marking on egress:
RTP marked EF (46) if that is your policy
Check that the MX “Realtime” queue is only used when EF46 is present (by design).
B. Call-path validation
Place test calls:
Internal extension-to-extension
External inbound DID to phone
External outbound to PSTN
Verify:
Two-way audio
No clip/robotic audio while saturating the WAN with a controlled download
C. Meraki-native monitoring
If you have Meraki Insight, add Viirtue SBC IPs and monitor VoIP MOS-style metrics. Meraki VoIP Health uses ICMP probes every second and requires provider IP addresses.
Troubleshooting matrix
Symptom | What to check first | Fastest confirming test |
|---|---|---|
One-way audio | NAT or firewall blocking RTP return, asymmetric routing on dual WAN | Packet capture during a call and verify RTP in both directions |
Choppy audio under load | Uplink bandwidth set wrong, no priority queueing | Saturate the WAN, then confirm VoIP stays stable with shaping and DSCP |
Softphone web client fails | Content filtering or L7 rule resets HTTPS | Temporarily bypass filtering for that client, then retest |
Calls drop after holds | Idle timeouts somewhere, missing keepalives | Reproduce the hold drop, then check for RTP/SIP keepalives and upstream timers |
Packet capture tips (Meraki Dashboard)
Meraki packet captures are often the quickest way to end “it’s the network” debates.
Dashboard path
Network-wide > Monitor > Packet capture
Operational notes from Meraki
Traditional packet capture data is not stored in the Meraki cloud.
When downloading a PCAP, the capture can stop after 60 seconds if no traffic is captured (even if you set a longer duration).
Useful capture filter patterns (edit placeholders)
# SIP signaling (confirm protocol/port with provider)
host <PHONE_IP> and (udp port <SIP_PORT> or tcp port <SIP_TLS_PORT>)
# RTP media (confirm RTP range with provider)
host <PHONE_IP> and udp portrange <RTP_START>-<RTP_END>
# Capture both phone and SBC
(host <PHONE_IP> and host <VIIRTUE_SBC_IP>)
What to send support
When escalating to the VoIP provider or ISP, include:
Site public IP, MX model, MX firmware train
Phone IP, voice VLAN subnet, and whether dual WAN is enabled
Exact timestamp and call direction (inbound or outbound)
Provider SBC IP(s) used (from DNS or from capture)
PCAPs from MX during the call attempt (SIP + RTP)
Whether IDS/IPS and content filtering are enabled, and which ruleset is used
Security hardening (optional)
Use these only after the baseline works.
Outbound default deny for voice VLAN, then allow only DNS/NTP and provider signaling/media (provider IP allowlist).
Keep IDS/IPS enabled, but choose rulesets that match site performance, and ensure firmware keeps signatures supported.
Avoid broad L7 blocks that can reset TLS connections needed by softphones and admin portals.
Best Way to Configure Meraki Firewall for VoIP: Final Thoughts
If you are building repeatable MSP deployments, Viirtue supports partner-first delivery for white label VoIP and operational automation through ViiBE, including quote-to-cash workflows, usage rating, and telecom tax automation. For customer-facing features, review AI voice agents, AI call summaries, and sentiment analysis.
If you are interested in becoming a Viirtue Partner, click here to schedule your introductory call.
FAQ: Best Way to Configure Meraki Firewall for VoIP
1) What is the best way to configure a Cisco Meraki firewall for VoIP?
Use a voice VLAN, keep VoIP on a single uplink if dual WAN exists, configure MX traffic shaping with priority and DSCP, and rely on stateful outbound flows instead of inbound port forwarding for cloud VoIP. Meraki MX has no SIP ALG toggle and UDP timeout is not configurable, so focus on QoS and predictable routing. (Cisco Meraki Documentation)
2) Does Meraki MX have SIP ALG?
No. Meraki states the MX is a stateful firewall that does not have ALG functionality. If a provider insists “disable SIP ALG,” check upstream routers or firewalls instead. (Cisco Meraki Documentation)
3) Do I need to open inbound SIP or RTP ports on Meraki for Viirtue cloud VoIP?
Usually no. Inbound traffic is generally allowed only as return traffic to an established outbound session. You typically only configure inbound port forwarding or 1:1 NAT if you host something on-prem that must accept inbound connections. (Cisco Meraki Documentation)
4) Can I change UDP timeout on a Meraki MX to prevent RTP drops?
No. Meraki documents the MX has a UDP timer but it cannot be changed. Solve idle-drop scenarios with endpoint keepalives or by fixing another device in the path that has a short UDP idle timeout. (Cisco Meraki Documentation)
5) How do I prioritize VoIP on Meraki MX?
Create traffic shaping rules to prioritize VoIP and set DSCP tagging if needed. Meraki supports DSCP tagging and priority settings in shaping rules, and notes correct uplink bandwidth settings are required for QoS behavior. (Cisco Meraki Documentation)
6) What DSCP values should I use for VoIP on Meraki?
EF is DSCP 46 for voice media per IANA. If you separate signaling, CS3 is DSCP 24. Many MSPs mark RTP as EF and keep signaling in a lower class. Validate end-to-end that upstream equipment honors the markings. (IANA)
7) Why do calls fail only on sites with dual WAN?
Voice flows can become unstable if signaling or RTP uses different uplinks over time. Meraki recommends ensuring voice traffic uses a particular interface via uplink preferences under traffic shaping. (Cisco Meraki Documentation)
8) How do I take a SIP/RTP packet capture on Meraki?
Use Dashboard’s Packet Capture tool and download a PCAP for Wireshark. Meraki notes packet captures are not stored in the cloud, and PCAP downloads can stop after 60 seconds of no captured traffic. Capture during an active call attempt and filter on phone IP and provider SBC IP. (Cisco Meraki Documentation)
