An ALG (Application Layer Gateway) is a security component, commonly found in a router or firewall device, that is supposed to enhance the ability for certain protocols to traverse NAT. A more complete discussion can be found here and here.
While ostensibly a SIP ALG is designed to enhance SIP and make the notoriously problematic NAT traversal issues easier to deal with, the simple fact of the matter is that most SIP ALG's are horribly broken. Brian K West has described them as "evil" - which is not really an understatement if you've ever been burned by one. Most routers that have SIP ALG's come with them enabled by default, which means that it's up to the user or admin to dig into the configuration to disable them. The following sections contain instructions and links to more information about various devices that have SIP ALG's and how to disable them. Also, be mindful of the fact that some manufacturers have created devices whose SIP ALG's cannot be disabled. AVOID THEM LIKE THE PLAGUE. (I'm talking to you, Netgear.)
The simple solution to this is to use encrypted communications. Since TLS packets cannot be read nor modified by the router, SIP ALGs will never be able to mangle encrypted calls. yet another reason go encrypted.
For encrypted calls you will always need to support NAT traversal on the SIP client itself.
Even if you're only making unencrypted calls using SIP ALG it is far better to get your phone or edge router correctly to handle that NAT on its own for all calls from the very start. That way you won't experience problems if you switch to TLS encrypted calls; or need to make configuration changes when switching between unencrypted and encrypted calls.
Following are some specific instructions on how to disable SIP ALG on various consumer– and business–grade routers. Please add any devices that you know of in the comment section at the bottom of the page. Also, if you know of some devices that cannot disable their built-in SIP ALG please list or link to them there.
iptables has two loadable modules (nf_conntrack_sip and nf_nat_sip) for processing SIP packets. nf_nat_sip contains all the SIP ALG functionality. To unload the ALG use the following command:
modprobe -r nf_nat_sip
The nf_conntrack_sip module tracks open connections, e.g. for automatically opening RTP ports; it does not perform ALG and does not modify the packets, and so can safely be left loaded.
This may also work on Linux-based routers without an option if you gain command line access (e.g. Netgear), although it may not persist on reboot.
If you use a firewall product that acts as a front-end to iptables, you may need to reconfigure that product to prevent it loading nf_nat_sip.
I have UVerse from AT&T and my VoIP calls were horrible until I realized that I had this device. I found the instructions found at the Verizon on-line support site to be quite simple and accurate. The Verizon site has actual screen shots. For those of you who don't need a picture, these are the steps:
This router can cause Authentication to fail with UDP. There is no web option to disable ALG, so you have to do the following:
Disable SIP ALG as follows:
under "Advanced"->"Firewall Settings"->"Application Level Gateway (ALG) Configuration", clear the "SIP" checkbox.
These routers will function as expected for a period of time, then for no apparent reason cause certain SIP endpoints to fail to authenticate. Using TCP over SIP has resolved the issue in my cases. To disable SIP ALG from the web interface:
Some have reported that using SIP over TCP can avoid SIP ALG issues. FS user Moc reports that SIP over TCP has helped him deal with multiple issues with SonicWall routers. Give it a try before you throw money down on a new piece of hardware.
Keep in mind, though, that this will only work as long as vendor products are only inspecting for SIP over UDP. Sooner or later they may extend that to TCP as well. After all, there's nothing stopping them.
The only "sure fire" and universal way to defeat SIP ALGs is to use TLS. Not only does it usually run over a different port (5061) it appears just like another TLS data stream and because it's encrypted the router has no chance of modifying the payload of the packets. When in doubt, use TLS. If you're planning on doing a large SIP deployment and your devices support it, use TLS. You'll save yourself a lot of time and hassle.