Bypassing Broken SIP ALG Implementations

The SIP protocol is commonly used for IP telephone communications. Unfortunately it’s notorious for having issues with NAT traversal. Even some major vendors can’t seem to get it right. [Stephen] had this problem with his Cisco WRVS4400N router. After a bit of troubleshooting, he was able to come up with a workaround that others may find useful.

The router had built in SIP ALG functionality, but it just didn’t work. [Stephen] was trying to route SIP traffic from a phone to an Asterisk PBX system behind the router. The router just couldn’t properly handle these packets regardless of whether SIP ALG was enabled or disabled.

[Stephen] first tried to change the SIP port on the external VOIP phone from the default of 5060 to something else. Then he setup port forwarding on the router to the Asterisk box to forward the traffic to the Asterisk system on the original port. This sort of worked. The calls would go through but they would eventually drop after about 20 seconds.

The only thing that [Stephen] could get to work completely was to change the SIP port in Asterisk’s sip.conf file using the “bindport” directive. He changed it to some random unused high port number. Then he setup port forwarding on the router to forward incoming UDP packets on that port to the Asterisk system. This worked fine, but now all of the original phones behind the router stopped working because they were configured to use the default port of 5060.

Rather than re-configure all of the phones in the organization, [Stephen] made one change on the Asterisk system. He setup an iptables rule to forward all incoming traffic on UDP port 5060 to the new SIP port. Now all of the phones are working with minimal changes across the organization. It’s a lot of hassle to go through just because the router couldn’t handle SIP correctly, but it gets the job done.

15 thoughts on “Bypassing Broken SIP ALG Implementations

    1. That’s the easy way…. or better yet, replace the router with pfsense. For a lot of phones, one can use a cheap outdated redundant dual-nic server (tons on ebay for < $200) and pfsense. These will easily handle a sizable call center and have a lot of nice features like working qos, url blocking (YouTube, etc), and load balancing multiple Internet connections.

      1. psfense, ipcop, endian.. the list is of firewall distros is extensive, but the idea is the same…. old server… a bunch of NICs, firewall distro… careful setup… sleep easier at night.

    2. Hi, OP here. That doesn’t work because if the server thinks its local port is 5060, it’ll communicate that port back to the endpoint and the endpoint will try to use 5060, which doesn’t work. SIP is an ugly mess.

  1. Working as a network tech that does a lot of VoIP deployements, I get this type of problem on a daily basis, its extremly frustrating and every single router/firewall has some implementation of SIP ALG that breaks sip in one way or another. There is a post on voipinfo that outlines what each router is doing and how its breaking the traffic.

    Our go to method is a pfsense alix 2d3 device which is predictable and reliable.

  2. Has it ever occur to you guys that it is the fault of SIP that it is embedding IP addresses in its protocol that is causing all the trouble?

    I mean when SIP is invented, NAT is roaming the earth already. Why on earth was SIP not made itself compatible with NAT? By compatible, I mean without the need of any ALG. There are plenty of ways out there to obtain a your external IP and there are also plenty of ways to keep the session alive with NAT and get voice call initiated successfully without ALG involved.

    1. OP here. I don’t recall which version of Asterisk this was – probably 2.2 or 2.8, I think. In any case, that feature was not available on the customer’s production PBX and I wasn’t at liberty to upgrade. Real world problems.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.