cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Announcements
Walkthrough Wednesdays
1281
Views
0
Helpful
3
Replies
MrStinch01
Beginner

SIP trunk security to Telecom provider that uses DNS

I have setup a SIP trunk for our office in Germany. Deutsche Telekom insisted we had to move off ISDN, as they are replacing it with SIP. I used the following guide as help me https://www.cisco.com/c/dam/en/us/solutions/collateral/enterprise/interoperability-portal/connecting-unified-communication-manager.pdf

 

Our setup has 1 Cisco router and is used for routing over our MPLS network, , IWAN, and now the SIP connection.  It is a 4331 running 16.03.07. I had to route 217.0.0.0/16 out the SIP port to get calls working. So I want to secure this connection to only trust Deutsche Telekom. Ideally I would use vrf for the SIP trunk so its routing is separate.

 

My Interface is configure as:-

interface GigabitEthernet0/1/1

description Deutsche Telecom Interface

ip address 192.x.x.2 255.255.255.0

negotiation auto

 

SIP-UA config:-

sip-ua

credentials number +49*********90 username 55************** password 7

********************* realm sip-trunk.telekom.de

authentication username 55************** password 7 *********************

no remote-party-id

timers expires 900000

timers register 100

timers dns registrar-cache ttl

registrar dns:sip-trunk.telekom.de expires 240 tcp auth-realm siptrunk.telekom.de

sip-server dns:sip-trunk.telekom.de

no transport udp

connection-reuse

 

How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?

For vrf, do I need to reload the router to get the once I have created the vrf definition to activate the new route group? I could not seem to get vrf working when I last tried to apply it to the SIP interface.

 

Many Thanks,

Mike

 

 

 

1 ACCEPTED SOLUTION

Accepted Solutions
Terry Cheema
Advocate

Hi Mike,

 

"How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?"

Extended ACLs have a hostname parameter you can use but as far as I know it just does a name look up the first time you configure the ACLs and resolves it to an IP address and saves to the configuration. So unless this has changed, this serves you no good. You still have to manually re-enter the command to update the IP.

 

You can use VRFs. ISR4Ks even support multi-vrf feature. That means you can configure the provider facing interfacing in a separate vrf say VRF-SP and CUCM facing interface in a different vrf say VRF-CUCM. You dont need any route leaking, CUBE will provide the bridging for the voice calls. In this case Cisco do recommend you reload the router after you make any changes with the VRF configuration. Multi-vrf has some limitations, as listed below. If you don't need to use these features listed in limitations, multi-vrf CUBE with the SP and Corporate facing interfaces configured in a separate VRF is the best way to segregate the IP between the corporate and SP network. 

 

The document refereed below has the config guide as well explains the dial-peer matching as well for the multi-vrf setup.

 

Ref: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html#id_10047 

 

Restrictions

  • Supports only SIP-SIP calls.

  • Cisco Unified Communications Manager Express (Unified CME) and CUBE co-located with VRF is not supported.

  • Cisco Unified Survivability Remote Site Telephony (Unified SRST) and CUBE co-location is not supported prior to Cisco IOS XE Fuji 16.7.1 Release.

  • Multi-VRF call across CUBE is supported in Flow-through mode only.

  • IPv6 on VRF is not supported.

  • SDP pass-through is not supported prior to IOS Release 15.6(3)M and IOS XE Denali 16.3.1.

  • Calls are not supported when incoming dial-peer matched is default dial-peer (dial-peer 0).

  • Media Anti-trombone is not supported with VRF.

  • Cisco UC Services API with VRF is not supported.

  • Multi-VRF is not supported on TDM-SIP gateway.

  • VRF aware matching is applicable only for inbound dial-peer matching and not for outbound dial-peer matching.

  • Invoking TCL scripts via a dial-peer is not supported with the Multi-VRF feature.

  • Multi-VRF using global routing table or default routing table (VRF 0) with virtual interfaces is not supported on ISR-G2 (2900 and 3900 series) routers.

  • SCCP based media resources are not supported with VRF feature.

Recommendations

  • For new deployments, we recommend a reboot of the router once all VRFs' are configured under interfaces.

  • No VRF Route leaks are required on CUBE to bridge VoIP calls across different VRFs.

  • High Availability(HA) with VRF is supported where VRF IDs are check-pointed in the event of fail-over. Ensure that same VRF configuration exists in both the HA boxes.

  • Whenever destination server group is used with VRF, ensure that the server group should have the session targets, belonging to the same network as that of sip bind on the dial-peer, where the server-group is configured. This is because, dial-peer bind is mandatory with VRF and only one sip bind can be configured on any given dial-peer.

  • If there are no VRF configuration changes at interface level, then reload of the router is not required.

Configuring VRF

Note

We recommend you NOT to modify VRF settings on the interfaces in a live network as it requires CUBE reload to resume VRF functionality.


This section provides the generic configuration steps for creating a VRF. For detailed configuration steps specific to your network scenario (Multi-VRF and Multi-VRF with HA), refer to Configuration Examples section.

View solution in original post

3 REPLIES 3
Terry Cheema
Advocate

Hi Mike,

 

"How do I trust only 'sip-trunk.telekom.de' and create an access list without an IP address?"

Extended ACLs have a hostname parameter you can use but as far as I know it just does a name look up the first time you configure the ACLs and resolves it to an IP address and saves to the configuration. So unless this has changed, this serves you no good. You still have to manually re-enter the command to update the IP.

 

You can use VRFs. ISR4Ks even support multi-vrf feature. That means you can configure the provider facing interfacing in a separate vrf say VRF-SP and CUCM facing interface in a different vrf say VRF-CUCM. You dont need any route leaking, CUBE will provide the bridging for the voice calls. In this case Cisco do recommend you reload the router after you make any changes with the VRF configuration. Multi-vrf has some limitations, as listed below. If you don't need to use these features listed in limitations, multi-vrf CUBE with the SP and Corporate facing interfaces configured in a separate VRF is the best way to segregate the IP between the corporate and SP network. 

 

The document refereed below has the config guide as well explains the dial-peer matching as well for the multi-vrf setup.

 

Ref: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/cube/configuration/cube-book/voi-cube-multi-vrf.html#id_10047 

 

Restrictions

  • Supports only SIP-SIP calls.

  • Cisco Unified Communications Manager Express (Unified CME) and CUBE co-located with VRF is not supported.

  • Cisco Unified Survivability Remote Site Telephony (Unified SRST) and CUBE co-location is not supported prior to Cisco IOS XE Fuji 16.7.1 Release.

  • Multi-VRF call across CUBE is supported in Flow-through mode only.

  • IPv6 on VRF is not supported.

  • SDP pass-through is not supported prior to IOS Release 15.6(3)M and IOS XE Denali 16.3.1.

  • Calls are not supported when incoming dial-peer matched is default dial-peer (dial-peer 0).

  • Media Anti-trombone is not supported with VRF.

  • Cisco UC Services API with VRF is not supported.

  • Multi-VRF is not supported on TDM-SIP gateway.

  • VRF aware matching is applicable only for inbound dial-peer matching and not for outbound dial-peer matching.

  • Invoking TCL scripts via a dial-peer is not supported with the Multi-VRF feature.

  • Multi-VRF using global routing table or default routing table (VRF 0) with virtual interfaces is not supported on ISR-G2 (2900 and 3900 series) routers.

  • SCCP based media resources are not supported with VRF feature.

Recommendations

  • For new deployments, we recommend a reboot of the router once all VRFs' are configured under interfaces.

  • No VRF Route leaks are required on CUBE to bridge VoIP calls across different VRFs.

  • High Availability(HA) with VRF is supported where VRF IDs are check-pointed in the event of fail-over. Ensure that same VRF configuration exists in both the HA boxes.

  • Whenever destination server group is used with VRF, ensure that the server group should have the session targets, belonging to the same network as that of sip bind on the dial-peer, where the server-group is configured. This is because, dial-peer bind is mandatory with VRF and only one sip bind can be configured on any given dial-peer.

  • If there are no VRF configuration changes at interface level, then reload of the router is not required.

Configuring VRF

Note

We recommend you NOT to modify VRF settings on the interfaces in a live network as it requires CUBE reload to resume VRF functionality.


This section provides the generic configuration steps for creating a VRF. For detailed configuration steps specific to your network scenario (Multi-VRF and Multi-VRF with HA), refer to Configuration Examples section.

View solution in original post

Thanks for the plain English answer. I will organise the reboot, as that sounds like why my vrf did not work last time. I have also added under the sip-ua config 'permit hostname dns:sip-trunk.telekom.de' to further help with the security.

Hi mike,

Same situation for me and i need to secure the connection. What you done? 

Content for Community-Ad

Spotlight Awards 2021