Showing results for 
Show  only  | Search instead for 
Did you mean: 
Honored Contributor
Honored Contributor

HHH - SIP access-list gotcha results in failed calls

This information may be helpful to those applying a SIP access-list to deter friendly (and vicious) scanners and fraud attempts.  Also applicable to 31xx and other AOS voice platforms.

We have dozens of TA9xx devices at customer premises in a variety of scenarios and have implemented a policy similar to the following on them:

ip access-list standard sip-access

permit xx.yy.zz.0 ! Subnet of our primary VoIP SBC cluster

permit ! Subnet of our secondary VoIP SBC cluster

permit host ww.xx.yy.zz ! N-command monitoring host

permit ! Private voice subnet behind NAT of TA9xx

ip sip access-class sip-access in

This does a good job of keeping the bad guys from knocking at the door, and basically just works in most cases.

Here's the gotcha...

In a few cases, customers with Cisco SIP phones and customers with Trixbox (Asterisk clone) SIP devices on the inside network report inability to place calls, inability to receive calls, or other strange issues.  One Trixbox user couldn't make outbound calls unless he had received an inbound call within the previous two minutes.

Sniffing and debugging reveals that these corner cases are due to the endpoint doing some relatively unusual spoofing of the source of the UDP SIP packets sent from the device.

Some Cisco phones source the UDP from which makes no sense.  The internal SIP payload IP is correct.

The Trixbox sources its IP from the outside WAN IP of the TA900.  Very strange, as it's on the inside behind NAT.

We had to add host entries to the SIP ACL for and the outside IP of the device in order to make these endpoints behave.  Totally not an Adtran issue but buggy implementation on the part of the endpoint manufacturers.  It's probably some form of badly-implemented NAT traversal mechanism.

I hope others find this helpful.  We've been aggressive in locking down SIP access as the bad guys are pretty aggressively scanning most of the public Internet looking for vulnerable hosts.  I strongly suggest that you lock down your devices.

Labels (3)