How to Disable SIP ALG: A Guide by Router Vendor

SIP ALG is the single most common cause of VoIP problems on business networks, and it has been for over a decade. It ships enabled by default on nearly every router sold, and it will keep breaking your calls until you explicitly turn it off.

The concept behind SIP ALG is reasonable: inspect SIP packets as they cross the router and rewrite the headers so they work correctly through NAT. In practice, the implementations are buggy, outdated, and they break more than they fix. Modern VoIP endpoints handle NAT traversal themselves using STUN, symmetric RTP, and outbound proxy configurations. SIP ALG interferes with these mechanisms by rewriting headers that were already correct.

For the full explanation of why SIP ALG causes problems, see SIP ALG: The Router Setting That Breaks Everything. This post is the practical companion: where the control lives on the vendors you are most likely to encounter.

How to use this guide

Menu paths and CLI syntax for these settings move between firmware releases, and the same brand often behaves differently across model families. Treat everything below as a starting point that tells you what to look for and what it is called, then confirm it against your vendor's current documentation for your exact model and firmware version. These steps have not been verified against every model and release, and any guide that claims otherwise (including an earlier version of this one) is overstating what it can know.

Two rules that matter more than any individual menu path:

• Only change the SIP ALG control itself. A recurring pattern in SIP ALG guides is to reach for some adjacent, broader setting when the ALG switch cannot be found: opening up NAT filtering, disabling packet normalization, exempting traffic from connection tracking. These are not equivalent to disabling an ALG. They generally will not stop header rewriting, and they weaken protections that apply to all your traffic. Where that substitution commonly gets suggested, this guide flags it.
• If your vendor exposes no supported SIP ALG control, that is a real answer. It means the fix lives elsewhere: your provider's NAT-traversal guidance (outbound proxy, keepalives, STUN), or putting a supported router or SBC in front of the phones. It does not mean you should improvise one.

The symptoms

Before you start changing settings, confirm that SIP ALG is likely the culprit. The classic pattern:

• One-way audio: you can hear the other party but they cannot hear you, or vice versa. This is the most common symptom. See One Way Audio: I Can Hear Them But They Can't Hear Me for a deeper dive.
• Calls fail on transfer: a call connects fine, but when transferred to another extension or external number, the audio drops or the call disconnects.
• Intermittent registration failures: phones randomly go unregistered and then re-register on their own.
• No audio in either direction: the call connects (you see it ringing and answered) but neither side can hear anything.
• Calls work on the same network but fail to external numbers: internal extension-to-extension calls are fine, but calls through a SIP trunk fail.

If you are seeing these symptoms and the phones are behind a NAT router, SIP ALG is the first thing to check.

How to prove it

The definitive test is a packet capture on both sides of the router. Capture on the LAN side (between the phone and the router) and on the WAN side (between the router and the internet). Compare the SIP INVITE messages. If the Contact header, Via header, or SDP connection address has been rewritten between the two captures, SIP ALG is active and modifying your traffic.

You can upload both captures to our PCAP analyzer to compare the SIP headers side by side without manually digging through Wireshark.

The faster test: disable SIP ALG, reboot the router, and see if the problem goes away. If it does, you have your answer.

One caution before the vendor sections: menu paths and CLI syntax vary by model and firmware release, sometimes significantly. Treat the instructions below as a map, verify them against your vendor's current documentation for your exact model and firmware version before pasting commands, and prefer the vendor's supported setting over any workaround found in a forum thread.

Ubiquiti (UniFi / EdgeRouter)

UniFi Security Gateway and UniFi Dream Machine

On the USG, which runs EdgeOS underneath, the ALG lives in the kernel's connection tracking SIP module. SSH into the gateway and run:

configure
set system conntrack modules sip disable
commit
save

Because the controller re-provisions the USG's configuration, a change made over SSH will be overwritten on the next provision; persist it through the controller's config.gateway.json mechanism (documented by Ubiquiti) so it survives.

On UDM and UDM Pro running UniFi OS, whether a supported SIP ALG setting exists (and where it lives) depends on your UniFi OS and UniFi Network application versions, so check Ubiquiti's current documentation for your firmware. One thing not to do: forum threads circulate raw iptables NOTRACK rules for UDP port 5060 as a do-it-yourself ALG disable. Do not use them. NOTRACK exempts matching packets from connection tracking entirely, which is not the same thing as disabling ALG inspection: it can break NAT and stateful firewalling for exactly the traffic you are trying to fix, and the rules silently vanish on firmware upgrades. If your firmware exposes no supported control, the reliable paths are your VoIP provider's NAT-traversal guidance (outbound proxy, keepalives), a supported router or SBC in front of the phones, or Ubiquiti support.

EdgeRouter

SSH in or use the CLI tab in the EdgeRouter web interface (EdgeOS documented command):

configure
set system conntrack modules sip disable
commit
save

Then reboot the router. The conntrack SIP module is what performs ALG inspection. Disabling it stops the packet mangling.

Fortinet (FortiGate)

FortiGate firewalls have SIP ALG enabled by default through the SIP Application Layer Gateway and the SIP session helper.

In the FortiGate CLI:

config system settings
    set sip-helper disable
    set sip-nat-trace disable
    set default-voip-alg-mode kernel-helper-based
end

config system session-helper
    show

Find the entry for SIP (port 5060) and delete it:

config system session-helper
    delete <id>
end

Replace <id> with the number shown next to the SIP entry. Then reboot. Some FortiOS versions also require disabling the SIP inspection profile in the firewall policy if one is applied:

config firewall policy
    edit <policy_id>
        set voip-profile ""
    next
end

SonicWall

SonicWall firewalls have "Consistent NAT" and "SIP Transformations" that act as SIP ALG.

In the web management interface:

1. Navigate to Voice > Settings (on older firmware: VoIP > Settings)
2. Uncheck Enable SIP Transformations (this is the ALG control)
3. Under Network > NAT Policies, verify there are no NAT policies specifically manipulating SIP traffic
4. Apply and reboot

Separately from the ALG, SonicWall's Consistent NAT option (Network > Firewall > Advanced) changes how the appliance maps source ports for UDP, which some VoIP deployments prefer. It is a NAT behaviour setting, not an ALG control, so change it deliberately and on its own, not as a substitute for step 2 if you cannot find that setting.

On Gen 7 SonicWall (SonicOS 7.x), the path is Policy > Security Services > VoIP and the setting is Enable SIP ALG.

Netgear

Most Netgear consumer and prosumer routers have SIP ALG buried in the settings.

In the web interface:

1. Navigate to Advanced > WAN Setup (or Advanced > Setup > WAN Setup)
2. Look for a Disable SIP ALG checkbox; check it to disable
3. Apply and reboot

On Netgear Nighthawk and Orbi models, the setting is usually under Advanced > WAN Setup > Disable SIP ALG.

Do not substitute the NAT Filtering setting for this. Some guides suggest switching NAT Filtering from Secured to Open when no SIP ALG checkbox is present. That is a different control: it broadly relaxes which inbound traffic the router accepts, weakening your firewall posture, and it does not stop ALG inspection from rewriting SIP headers. If your model exposes no SIP ALG control, treat it as a model without one and use the fallbacks at the end of this guide.

TP-Link

Consumer routers (Archer series)

1. Log into the router admin (usually 192.168.0.1 or tplinkwifi.net)
2. Navigate to Advanced > NAT Forwarding > ALG
3. Uncheck SIP ALG (and H.323 ALG if present)
4. Save and reboot

Omada (managed)

In the Omada controller:

1. Go to Settings > Network > Service (or Gateway > ALG depending on firmware)
2. Disable SIP ALG
3. Apply

Cisco (Meraki, ISR, ASA)

Meraki MX

Meraki does not expose a traditional SIP ALG toggle. That means there is no ALG to disable here, so if SIP is misbehaving through an MX, you are looking for a different cause rather than a hidden ALG switch. Content filtering and IPS are the usual candidates:

1. In the Meraki dashboard, go to Security & SD-WAN > Firewall
2. Ensure UDP 5060 and your RTP range (typically 10000-20000) are allowed outbound
3. Under Threat Protection, check whether SIP traffic is being flagged or dropped by IDS/IPS
4. Confirm with your VoIP provider whether their platform expects a specific NAT or keepalive behaviour on this path

If none of that resolves it, consult Meraki's current documentation for your MX model and firmware rather than applying a control borrowed from another vendor.

Cisco ISR (IOS)

no ip nat service sip udp port 5060
no ip nat service sip tcp port 5060

Save the config and reload.

Cisco ASA

policy-map global_policy
 class inspection_default
  no inspect sip

Then write memory and reload.

Mikrotik (RouterOS)

Mikrotik routers have a SIP helper in the connection tracking module.

In the terminal:

/ip firewall service-port set sip disabled=yes

Or in WinBox: IP > Firewall > Service Ports, find sip, and disable it.

pfSense / OPNsense

pfSense has no SIP ALG to disable. What it does have is outbound NAT that randomizes source ports by default, which some SIP endpoints and providers cope with poorly, a different problem with a different fix:

1. Navigate to Firewall > NAT > Outbound
2. If using Automatic Outbound NAT, switch to Hybrid or Manual so you can add your own rule
3. Create a rule for your VoIP subnet with Static Port enabled, which stops the source port being rewritten

OPNsense: same approach, same path (Firewall > NAT > Outbound).

Leave Firewall Scrub alone. Scrub is packet normalization (it reassembles fragments and sanitizes malformed packets), and disabling it is sometimes suggested as a SIP fix. It is not an ALG control, disabling it will not stop header rewriting (there is none happening here), and it removes a protection that applies to all your traffic, not just SIP. If static port does not resolve the issue, the cause is somewhere other than pfSense's packet filter.

ISP-provided routers

If you are using a router provided by your ISP (AT&T BGW, Comcast xFi, Verizon Fios), SIP ALG may be enabled and the setting may not be exposed in the consumer interface.

Your options:

1. Check for an advanced settings page. Some ISP gateways expose more options (sometimes including SIP ALG) in an advanced or technician-level settings area that is not linked from the main interface. Check your ISP's documentation for your gateway model rather than relying on URLs from forum posts, which change between firmware revisions.
2. Enable IP Passthrough / Bridge Mode. Put the ISP router in bridge mode and use your own router behind it. This bypasses the ISP router's NAT and ALG entirely.
3. Call the ISP. Some ISPs can disable SIP ALG remotely. Worth asking, though success varies.

Bridge mode is the most reliable option. It also gives you control over your firewall, NAT, and QoS settings, which matters for VoIP quality.

After disabling SIP ALG

After disabling SIP ALG on any router:

1. Reboot the router. Settings changes to NAT helpers and connection tracking modules typically require a reboot to take full effect.
2. Restart your phones or PBX. Force a fresh SIP registration so the new (unmangled) headers are used.
3. Test calls. Make a call to an external number. Test a transfer. Test a call on hold. These are the scenarios most affected by SIP ALG.
4. Run a VoIP quality test. Use our VoIP quality test to verify that media (RTP) is flowing correctly in both directions with acceptable jitter and packet loss.

If the problems persist after disabling SIP ALG, the issue may be elsewhere: double NAT, restrictive firewall rules, or a network quality problem. See How to Tell Where the Problem Actually Is for a systematic troubleshooting approach.

For the full technical explanation of why SIP ALG causes these problems, see SIP ALG: The Router Setting That Breaks Everything. For help reading the SIP traces that reveal ALG mangling, see Reading a SIP Trace: Practical Troubleshooting.