CUBE - Binding Media & Signaling for SIP Best Practices Question

Jeremy Combs · ‎08-24-2011

I have a burning question that I've needed help on for years now regarding properly binding media and signaling for SIP in CUBE. Growing up in the Cisco world I've always been told and followed the best practice of binding media and signalling for H323, MGCP, CME and SRST to a loopback on the router and some features simply won't work unless you bind to a loopback. This has worked great until I came across utilizing CUBE for SIP integration with CUCM and a PSTN provider such as AT&T, Verizon or Global Crossing. What's my issue? I can no longer bind my traffic to that loopback address and have a succesful CUBE integration with an external entity or with CUCM. You ask how that's an issue? When I bind to that loopback address which has an internal non public routable IP address CUBE sends out of all interfaces that Loopback interface as the source address so when my SIP traffic gets sent to the PSTN provider they have no way of getting back to that router but obviously it works for talking to CUCM. I thought, simple, that's what NAT is for for the outside connection! I disocvered the hard way that CUBE and NAT are not friends and supported together due to CUBE doing a very basic form of NAT with the address-hiding command. I thought "Cool, address-hiding should be doing this for me!" and no, it is simply following what you tell it by binding all traffic to the specified interface in voice service voip - sip. So my question is simple: What is best practice and the correct way for binding traffic in CUBE for interaction with CUCM and an external PSTN Provider? I've spent hours on Google and Cisco documentation and cannot find a good answer other than this from the SIP Configuration Guide and CUBE Configuration Guide:

When you configure SIP on a router, the ports on all its interfaces are open by default. This makes the router vulnerable to malicious attackers who can execute toll fraud across the gateway if the router has a public IP address and a public switched telephone network (PSTN) connection. To eliminate the threat, you should bind an interface to private IP address that is not accessible by untrusted hosts. In addition, you should protect any public or untrusted interface by configuring a firewall or an access control list (ACL) to prevent unwanted traffic from traversing the router.

Let me stop those who think 'throw an ASA in front of it' or 'don't bind it to a specific interface' is an answer and can throw an argument for why 'no' to both of those answers. I think the answer is a new feature in 15.1(2)T that allws you to apply a voice class for binding SIP and assigning it to the appropriate dial peers but I'd like to hear everyone's input.

dkemp · ‎08-25-2011

Jeremy,

Sorry but my answer is put an ASA in front of it. I have used CUBE for almost 6 years now using SIP carriers, from a security point of view I would never expose the external CUBE interface directly to the "dirty" internet.

In my case I have always had dedicated VPN's for VoIP to the carrier but I still run it thru an ASA for security assurance. I have in the past during bug been asked to test loopback binding method's by TAC, none of them have ever worked....

I dont know about the specific voice class feature in your reference, I would say "voice source-groups" may be something you can use to lock down a carriers source signalling IP, I use these but not for security enforcement but I guess they could be extended for that use. These will not get you over any control plane vunerabilities of the device though with an exposed interface..

Maybe post your reason for not using a seperate security device (ASA or border router with ACL's?) is not an option so an alternative can be offered?

cheers

Dave

Jeremy Combs · ‎08-25-2011

Dave, I use Zone Based Firewall on the CUBE to secure it. The other item is my customers use private connections to the provider's SBC, some with private IP addressing so they are not exposed to the dirty Internet. Adding an ASA in front adds a level of unnecessary troubleshooting especially with NAT when you have an ISR fully capable of protecting itself with a properly configured ZBF.

dkemp · ‎08-25-2011

Jeremy,

OK, that explains a few things. Not sure why the address hiding is not then your option? This would match whatever the exit interface's IP is to the carriers. This works for a single carrier(single exit interface), I have not tested having multiple exit interfaces to confirm this works though (expect it does). Are you saying it does not work for multiple exit interfaces?

Does the setup work when not using a loopback for media binding?

Do you have a dedicated "inside" interface that routes to/from CUCM and seperate exit interfaces to providers?

Are you using SCCP on the same CUBE, (ie transcoding / mtp /conf bridge) is this causing the binding issue?

cheers

Dave

twilson217 · ‎03-12-2013

FYI, I just ran into this problem and my solution is to bind traffic on the dial-peer instead of under voice service voip. For instance, here are my dial-peers:

dial-peer voice 1 voip

session protocol sipv2

session target sip-server

incoming called-number 9T

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface Vlan241

voice-class sip bind media source-interface Vlan241

dtmf-relay rtp-nte

no vad

dial-peer voice 11 voip

destination-pattern 757[2-9]......

session protocol sipv2

session target ipv4:192.168.1.200

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface Vlan241

voice-class sip bind media source-interface Vlan241

dtmf-relay rtp-nte

no vad

dial-peer voice 21 voip

translation-profile outgoing strip9

destination-pattern 9[2-9]..[2-9]......

session protocol sipv2

session target sip-server

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface FastEthernet4

voice-class sip bind media source-interface FastEthernet4

dtmf-relay rtp-nte

no vad

dial-peer voice 22 voip

translation-profile outgoing strip9

destination-pattern 91[2-9]..[2-9]......

session protocol sipv2

session target sip-server

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface FastEthernet4

voice-class sip bind media source-interface FastEthernet4

dtmf-relay rtp-nte

no vad

dial-peer voice 12 voip

destination-pattern 804[2-9]......

session protocol sipv2

session target ipv4:192.168.1.200

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface Vlan241

voice-class sip bind media source-interface Vlan241

dtmf-relay rtp-nte

no vad

dial-peer voice 2 voip

session protocol sipv2

session target sip-server

incoming called-number 757[2-9]......

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface FastEthernet4

voice-class sip bind media source-interface FastEthernet4

dtmf-relay rtp-nte

no vad

dial-peer voice 3 voip

session protocol sipv2

session target sip-server

incoming called-number 804[2-9]......

voice-class codec 1

voice-class sip dtmf-relay force rtp-nte

voice-class sip bind control source-interface FastEthernet4

voice-class sip bind media source-interface FastEthernet4

dtmf-relay rtp-nte

no vad