SIP through a Cisco ASA 5500 with NAT

With the growth of the Foundation has come numerous necessary upgrades from Office IT, in order to support more users. One of the most noticeable (and more appreciated by the staff) is upgrading the internet connection. Some groups can get away with bare minimum internet connectivity, but we simply cannot since most everyone needs a decent Internet connection for their work (imagine how hard it would be for the Ops engineers to work, if they couldn’t SSH). When I started this summer, the San Francisco office had three bonded T1’s, for a total of 4.5 megabits/second of bandwidth. Recently, we completed an upgrade to a 100 megabit fiber connection along with a replacement firewall, the Cisco ASA 5510.
The Cisco ASA 5500 series was recommended by our ISP and is fairly standard as Firewall/Router units go. Getting the new unit online and powering our network isn’t complicated. It follows Cisco standards. The real “fun” with the unit was something discovered a few days later… remote users were no longer able to receive VoIP calls. Our phone system is powered by Asterisk and the remote users use a variety of hard and softphone clients, but nothing “special”. I’ve dealt with the issue of SIP and NATspreviously and know what to do, so it shouldn’t have been that big of an issue. It was odd, in that the users could register with Asterisk, make calls out but then Asterisk would “lose” them and not allow inbound calls to them.
It took me more time to find the problem than I would have cared for, but eventually I isolated the problem. As noted on one stray Cisco support forum post from 3 years ago, the issue could in fact be Cisco’s own SIP inspection. There are a number of different types of inspects that basically track where data is coming from and going to through the firewall. They then make sure the data gets to where it was trying to go. All the inspects are common and benign… except SIP in our case. The “inspect sip” clause of our configuration which was supposed to make SIP work, in fact broke it. Once that was removed, our remote users were back in business (and more importantly, with a sizable pipe).