0 Replies Latest reply on Jan 29, 2014 6:41 PM by jayh

    HHH - SIP access-list gotcha results in failed calls

    jayh Hall_of_Fame

      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 0.0.0.63 ! Subnet of our primary VoIP SBC cluster

      permit aa.bb.cc.0 0.0.0.63 ! Subnet of our secondary VoIP SBC cluster

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

      permit 192.168.100.0 0.0.0.255 ! 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 127.0.0.1 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 127.0.0.1 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.