Cisco IOS and NX-OS Software

Table Of Contents

Cisco IOS Firewall Support for Skinny Local Traffic and CME

Contents

Prerequisites for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Restrictions for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Information About Cisco IOS Firewall Support for Skinny Local Traffic and CME

Skinny Overview

Pre-generated Session Handling

Running NAT with CME and the Cisco IOS Firewall

New Registry for Locally Generated Traffic

How to Configure Cisco IOS Firewall Support for Skinny Local Traffic and CME

Creating a Zone-Pair Between a Zone and the Self Zone

Additional References

Related Documents

Standards

MIBs

RFCs

Technical Assistance

Command Reference

Feature Information for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Cisco IOS Firewall Support for Skinny Local Traffic and CME

---

First Published: July 11, 2008

Last Updated: July 11, 2008

The Cisco IOS Firewall Support for Skinny Local Traffic and CME feature enhances the Context-Based Access Control (CBAC) functionality to support Skinny traffic that is either generated by or destined to the router. When Cisco Call Manger Express (CME) is enabled on the Cisco IOS firewall router, the CME manages both Voice over IP (VoIP) and analog phones using Skinny Client Control Protocol (SCCP) over either an intranet or the Internet with flow-around and flow-through modes of CME.

Finding Feature Information in This Module

Your Cisco IOS software release may not support all of the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To reach links to specific feature documentation in this module and to see a list of the releases in which each feature is supported, use the "Feature Information for Cisco IOS Firewall Support for Skinny Local Traffic and CME" section.

Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images

Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

Contents

•Prerequisites for Cisco IOS Firewall Support for Skinny Local Traffic and CME

•Restrictions for Cisco IOS Firewall Support for Skinny Local Traffic and CME

•Information About Cisco IOS Firewall Support for Skinny Local Traffic and CME

•How to Configure Cisco IOS Firewall Support for Skinny Local Traffic and CME

•Additional References

•Command Reference

•Feature Information for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Prerequisites for Cisco IOS Firewall Support for Skinny Local Traffic and CME

The Skinny inspection module is part of the inspection subsystem; thus, your router must be running an image that has firewall support.

Restrictions for Cisco IOS Firewall Support for Skinny Local Traffic and CME

This feature has the following restrictions:

•Skinny inspection will inspect only the SCCP sessions that have been established after the firewall is configured with Skinny inspection. That is, any SCCP sessions that were established through the firewall before the Skinny inspection was configured will not be inspected.

•This feature does not support Music on Hold (MOH) when a device other than the Call Manager (CM) is the music server. (This feature does support MOH when the CM is the music server.)

•This feature does not address either the multicast functionality of SCCP or the functionality of multiple active calls on a single Skinny client.

This feature does not support the following Skinny and firewall configurations:

•The CM and the Skinny client cannot be on three different networks that are separated at the firewall. The current firewall implementation does not inspect sessions that have devices residing on more than two distinct networks that are segregated at the firewall. That is, if there are more than two interfaces at the firewall, session inspection is not supported.

Information About Cisco IOS Firewall Support for Skinny Local Traffic and CME

To configure the Cisco IOS Firewall Support for Skinny Local Traffic and CME feature, you must understand the following concepts:

•Skinny Overview

•Pre-generated Session Handling

•Running NAT with CME and the Cisco IOS Firewall

•New Registry for Locally Generated Traffic

Skinny Overview

Skinny inspection enables voice communication between two Skinny clients by using a CM. Typically, the CM provides service to the Skinny clients on TCP Port 2000. Initially, a Skinny client connects to the CM by establishing a TCP connection; the client will also establish a TCP connection with a secondary CM, if available. After the TCP connection is established, the client will register with the primary CM, which will be used as the controlling CM until the CM reboots or there is a keepalive failure. Thus, the Skinny TCP connection between the client and the CM exists forever and is used to establish calls coming to or from the client. If a TCP connection failure is detected, the secondary CM is used. All data channels established with the previous CM remain active and will be closed after the end parties hang up the call.

The Skinny module is enhanced to inspect the locally generated or terminated Skinny control channel and to open or close pin-holes for the media channels that are originated from or destined to the Cisco IOS firewall.

With this enhancement, pass-through Skinny traffic and locally generated or terminated Skinny traffic is treated in the same way at the firewall. Both the control channels are inspected in the same way and the same set of Skinny messages are interpreted to obtain information about the possible media channels.

Table 1 lists the set of messages that are necessary for the data sessions to open and close. Skinny inspection will examine the data sessions that are deemed for opening and closing the access list pin holes.

Table 1 Skinny Data Session Messages

Skinny Inspection Message	Description
StationCloseReceiveChannelMessage	CM instructs the Skinny client (on the basis of the information in this message) to close the receiving channel.
StationOpenReceiveChannelAckMessage	Contains the IP address and port information of the Skinny client sending this message. This message also contains the status of whether or not the client is willing to receive the voice traffic.
StationStartMediaTransmissionMessage	Contains the IP address and port information of the remote Skinny client.
StationStopMediaTransmissionMessage	CM instructs the Skinny client (on the basis of the information in this message) to stop transmitting voice traffic.
StationStopSessionTransmissionMessage	CM instructs the Skinny client (on the basis of the information in this message) to end an indicated session.

Pre-generated Session Handling

When two phones register with the CME running on Cisco IOS firewall, there are two control channels terminated on the CME box. These two control channels are TCP connections and are inspected by the Firewall Skinny module. When pinholes are opened for the media traffic, there are a total of four pre-gen sessions created, two for each control session.

With the flow-through mode of operation of CME, the four pre-generated sessions are converted to two active sessions. The same number of active sessions is retained as there are two media sessions, one from each phone terminating on CME.

With the flow-around mode of operation of CME, the CME is bypassed as there is a direct connection between the two phones. In this mode, there are two possible scenarios:

•When both phones are on the same side of the CME, there is no exchange of media packets between the two phones. However, exchange of media packets is possible with pass-through traffic. In this case, the pre-gen sessions will time-out as the media traffic will not reach the router itself.

•When both phones are located on either side of the CME, the media traffic goes through the CME box. The four pre-gen sessions that are created are converted to one active session. Instead of creating four pre-gen sessions, only two pre-gen sessions are created. These two pre-gen sessions are converted to one active session when we see the media traffic.

Running NAT with CME and the Cisco IOS Firewall

In typical deployments, both Cisco IOS firewall and Network Address Translator (NAT) will be running on the same router. When CME is also running, typically in the case of Integrated Services Router (ISR), some complexities and limitations exist.

If two Skinny phones are registered to CME that is on the Cisco IOS firewall with NAT. When Phone 1 attempts to communicate with Phone 2, the IP and port (mostly private IP) of Phone 1 will be exchanged with Phone 2 over the already established TCP connection.

If NAT is configured on the outside interface to translate all the private addresses to the router's global address. Some private addresses are exchanged over a TCP connection between the router and the remote phone. If NAT is able to translate the addresses in such flows where one endpoint is the router itself, then there will not be any issues because of NAT and CME running on the same box. If not, the following scenarios are possible:

•In flow-through mode of operation, the voice data channels, Real-time Transport Protocol (RTP) stream over User Datagram Protocol (UDP), from Phone 1 and Phone 2 both terminate on CME. So, there will be one RTP over UDP connection from Phone 1 to the CME and a second from Phone 2 to the CME. The CME relays the voice data over the two channels. In this case, there should not be any problem with NAT running on the CME box, as the connection is terminated on the router from Phone 2 and the address used for that connection is the global address of the router.

•In flow-around mode of operation, there is a direct connection (RTP over UDP) between Phone1 and Phone 2 for carrying voice data traffic. If NAT does not translate the private IP of Phone 1, then the voice data channel will not be established successfully as the private IP of Phone 1 is shared in the control channel. In such a scenario, the running of CME with NAT breaks down.

New Registry for Locally Generated Traffic

A new registry is created in the Skinny local media traffic path. This path differs from the regular switching path code, where all the controlling and pass-through media traffic is inspected. The Skinny module sends the locally generated traffic using "fastsend" Application Program Interface (API) which does not put the packet in the regular switching path, but sends it directly (to Layer 2 drivers). This new registry resets the timeouts for the media channels and also reports the number of Skinny media sessions that are established such as the output of show commands.

---

Note The above API is only used to update the Firewall sessions when the media channel is active. Firewall will not attempt to protect the CME box based on the nonexistence of pre-gen. Therefore, the firewall will not drop media packets for which there is no pre-gen/active session. The MTP module in CME protects itself by dropping the packets that do not match the source IP and source port numbers.

---

How to Configure Cisco IOS Firewall Support for Skinny Local Traffic and CME

To configure a Cisco IOS Firewall for Skinny Local Traffic and CME, perform the following tasks:

•Creating a Zone-Pair Between a Zone and the Self Zone

Creating a Zone-Pair Between a Zone and the Self Zone

To inspect the traffic that is destined to the router or the traffic originating from the router, we need to create a zone-pair between a zone (containing the incoming/outgoing interface) and the self zone.

SUMMARY STEPS

1. enable

2. configure terminal

3. parameter-map type inspect type parameter-map-name

4. alert {on | off}

5. audit-trail {on | off}

6. class-map type inspect protocol-name [match-any | match-all] class-map-name

7. policy-map type inspect policy-map-name

8. class type inspect class-map-name

9. zone security zone-name

10. zone security zone-name

11. zone-pair security zone-pair-name {source source-zone-name | self} destination [self | destination-zone-name]

12. service-policy type inspect policy-map-name

13. interface type number

14. zone-member security zone_name

DETAILED STEPS

	Command or Action	Purpose
Step 1	enable Example: Router> enable	Enables privileged EXEC mode. •Enter your password if prompted.
Step 2	configure terminal Example: Router# configure terminal	Enters global configuration mode.
Step 3	parameter-map type inspect parameter-map-name Example: Router(config)# parameter-map type inspect insp-pmap	Configures an inspect parameter map for connecting thresholds, timeouts, and other parameters pertaining to the inspect action. Enters parameter-map type inspect configuration mode.
Step 4	alert {on | off} Example: Router(config-profile)# alert on	(Optional) Turns on and off Cisco IOS stateful packet inspection alert messages that are displayed on the console.
Step 5	audit-trail {on | off} Example: Router(config-profile)# audit-trail on	(Optional) Turns audit trail messages on or off.
Step 6	class-map type inspect protocol-name [match-any | match-all] class-map-name Example: Router(config-profile)# class-map type inspect skinnycmap match protocol skinny	Creates a class map for the Skinny protocol so that you can enter match criteria. Enters class-map configuration mode.
Step 7	policy-map type inspect policy-map-name Example: Router(config-profile)# policy-map type inspect skinnypmap	Creates a policy map so that you can enter match criteria. Enters policy map configuration mode.
Step 8	class type inspect class-map-name Example: Router(config-profile)# class type inspect skinnycmap	Specifies the name of the class on which an action is to be performed. The value of the class-map-name argument must match the appropriate class name specified via the class-map type inspect command.
Step 9	zone security name Example: Router(config-profile)# zone security z1	Creates a zone for phone 1. Enters global configuration mode.
Step 10	zone security name Example: Router(config-profile)# zone security z2	Creates a zone for phone 2.
Step 11	zone-pair security zone-pair-name {source source-zone-name | self} destination [self | destination-zone-name] Example: Router(config)# zone-pair security z1-self source z1 destination self	Creates a zone-pair. Enters security zone-pair configuration mode.
Step 12	service-policy type inspect policy-map-name Example: Router(config-sec-zone-pair)# service-policy type inspect skinnypmap	Attaches a firewall policy map to the destination zone-pair. If a policy is not configured between a pair of zones, traffic is dropped by default. Enters global configuration mode.
Step 13	interface type number Example: Router(config)# interface FastEthernet4/1	Specifies the type of interface to be configured and the port, connector, or interface card number.
Step 14	zone-member security zone_name Example: Router(config-sec-zone-pair)# zone-member security z1	Specifies the name of the security zone to which an interface is attached.

---

Note This CLI is only meant for supporting the Skinny traffic with IOS Firewall and CME on the same box. For supporting the pass-through Skinny traffic, we have to use the existing CLI and an example with the above zones and policy-map is:

---

zone-pair security zp3 source z1 destination z2

 service-policy type inspect skinnypmap

Additional References

The following sections provide references related to the Cisco IOS Firewall Support for Skinny Local Traffic and CME feature.

Related Documents

Related Topic	Document Title
Firewall Support of SCCP	The chapter "Firewall Support of Skinny Client Control Protocol (SCCP)" in the Cisco IOS Security Configuration Guide, Release 12.3(1)

Standards

Standard	Title
None	—

MIBs

MIB	MIBs Link
None	To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL: http://www.cisco.com/go/mibs

RFCs

RFC	Title
None	—

Technical Assistance

Description

Link

The Cisco Support website provides extensive online resources, including documentation and tools for troubleshooting and resolving technical issues with Cisco products and technologies. To receive security and technical information about your products, you can subscribe to various services, such as the Product Alert Tool (accessed from Field Notices), the Cisco Technical Services Newsletter, and Really Simple Syndication (RSS) Feeds. Access to most tools on the Cisco Support website requires a Cisco.com user ID and password.

http://www.cisco.com/techsupport

Command Reference

The following commands are introduced or modified in the feature or features documented in this module. For information about these commands, see the Cisco IOS Security Command Reference at http://www.cisco.com/en/US/docs/ios/security/command/reference/sec_book.html. For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.

•class-map type inspect

•class type inspect

•interface

•parameter-map type inspect

•policy-map type inspect

•service-policy type inspect

•zone-member security

•zone-pair security

Feature Information for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Table 2 lists the release history for this feature.

Not all commands may be available in your Cisco IOS software release. For release information about a specific command, see the command reference documentation.

Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.

---

Note Table 2 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.

---

Table 2 Feature Information for Cisco IOS Firewall Support for Skinny Local Traffic and CME

Feature Name	Releases	Feature Information
IOS Firewall Support for Skinny Local Traffic & CME	12.4(20)T	The Cisco IOS Firewall Support for Skinny Local Traffic and CME feature enhances the Context-Based Access Control (CBAC) functionality to support `router generated/destined to router' Skinny traffic. When CME is enabled on the IOS Firewall Router, it manages both Voice over IP (VoIP) and analog phones using Skinny Client Control Protocol (SCCP) over intranet/internet with flow-around and flow-through modes of CME. The following commands were introduced or modified: class-map type inspect, class type inspect, interface, parameter-map type inspect, policy-map type inspect, service-policy type inspect, zone-member security, zone-pair security

CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.

All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0805R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2008 Cisco Systems, Inc. All rights reserved.