SIP through a Cisco ASA 5500 with NAT

Translate this post

The Cisco ASA 5510 Series Adaptive Security Appliances

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).

Archive notice: This is an archived post from, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

Inline Feedbacks
View all comments

We use the same firewall (ASA 5510) and have had similar problems with the default inspection rules and VOIP. We had to apply the following config changes: policy-map global_policy class inspection_default no inspect h323 h225 no inspect h323 ras This allowed our VOIP trunks between offices to keep a call going longer than a minute or two. With Cisco being such a big name in networking, I’m often disappointed with broken things like these default inspection rules. Still have to say that once the correct config is set, our Cisco devices are very reliable and performance is good. Any suggestions… Read more »

I think part of the problem is that Cisco isn’t exactly clear on WHAT “inspect” does (on a more than 3 sentences basis). Sometimes it works (like ICMP) and sometimes it doesn’t (SIP). Obviously it _has_ to work for someone…somewhere… else why would Cisco bother?
As for QoS, haven’t gotten that far unfortunately. When I do, I’ll try to remember to do something about it.

Disable SIP ALG and make sure 1:1 NAT is being followed. VoIP is PAT-based and needs the same port being registered on from the Public IP to translate to the private IP. Can’t have translated into because some standard SIP policy that comes with the hardware which is aware SIP is port 5060-5065 wants to try the first available SIP port. Also, what you’re experiencing sounds like a UDP timeout. Make sure UDP is open from 1024 – 65536 because different SIP providers utilize different ranges regardless of whatever # RFC specified 16384-32768 ports to be used for… Read more »

As for QoS, stick with dfsp ef and traffic shaping. Unless of course, you have a nice MPLS network.