-
Catalyst 6500 Series Switch and Cisco 7600 Series Router Firewall Services Module Configuration Guide using ASDM, 6.1F
-
About This Guide
- Getting Started
-
Device Setup and Management
-
Using the Startup Wizard
-
Configuring Device Settings and Management
-
Configuring Interfaces
-
Configuring Security Contexts
-
Configuring Dynamic And Static Routing
-
Configuring Multicast Routing
-
Configuring DHCP and DNS
-
Configuring Failover
-
Configuring AAA Servers and User Accounts
-
Configuring Management Access
-
Configuring Logging
-
Configuring Certificates
-
-
Configuring the Firewall
-
Firewall Mode Overview
-
Adding Global Objects
-
Configuring Access Rules and EtherType Rules
-
Configuring NAT
-
Configuring Service Policy Rules
-
Configuring Application Layer Protocol Inspection
-
Configuring AAA Rules
-
Configuring Filter Rules
-
Configuring Advanced Connection Features
-
Configuring ARP Inspection and Bridging Parameters
-
- Monitoring the Firewall Services Module
-
Specifications
-
Index
-
Table Of Contents
Configuring Application Layer Protocol Inspection
When to Use Application Protocol Inspection
Configuring Application Inspection
How DNS Application Inspection Works
Verifying and Monitoring FTP Inspection
SMTP and Extended SMTP Inspection
Service Policy Field Descriptions
Rule Actions > Protocol Inspection Tab
Add/Edit DNS Traffic Class Map
Manage Regular Expression Class Maps
Add/Edit FTP Traffic Class Map
Add/Edit H.323 Traffic Class Map
Add/Edit H.323 Match Criterion
Add/Edit HTTP Traffic Class Map
Add/Edit SIP Traffic Class Map
Inspect Map Field Descriptions
Add/Edit DNS Policy Map (Security Level)
Add/Edit DNS Policy Map (Details)
Add/Edit ESMTP Policy Map (Security Level)
Add/Edit ESMTP Policy Map (Details)
Add/Edit FTP Policy Map (Security Level)
Add/Edit FTP Policy Map (Details)
Add/Edit GTP Policy Map (Security Level)
Add/Edit GTP Policy Map (Details)
Add/Edit HTTP Policy Map (Security Level)
Add/Edit HTTP Policy Map (Details)
Instant Messaging (IM) Inspect Map
Add/Edit Instant Messaging (IM) Policy Map
IPSec Pass Through Inspect Map
Add/Edit IPSec Pass Thru Policy Map (Security Level)
Add/Edit IPSec Pass Thru Policy Map (Details)
Add/Edit SCCP (Skinny) Policy Map (Security Level)
Add/Edit SCCP (Skinny) Policy Map (Details)
Add/Edit SIP Policy Map (Security Level)
Add/Edit SIP Policy Map (Details)
Configuring Application Layer Protocol Inspection
This chapter describes how to configure application layer protocol inspection. Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the FWSM to do a deep packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect overall throughput.
Several common inspection engines are enabled on the FWSM by default, but you might need to enable others depending on your network. This chapter includes the following sections:
–
When to Use Application Protocol Inspection
•
•
•
•
Inspection Engine Overview
This section includes the following topics:
•
When to Use Application Protocol Inspection
When a user establishes a connection, the FWSM checks the packet against access lists, creates an address translation, and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks. However, the fast path relies on predictable port numbers and does not perform address translations inside a packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate dynamically assigned port numbers.
Other applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the FWSM.
If you use applications like these, then you need to enable application inspection.
When you enable application inspection for a service that embeds IP addresses, the FWSM translates embedded addresses and updates any checksum or other fields that are affected by the translation.
When you enable application inspection for a service that uses dynamically assigned ports, the FWSM monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.
Inspection Limitations
See the following limitations for application protocol inspection:
•
•
Default Inspection Policy
By default, the configuration includes a policy that matches all default application inspection traffic and applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic to the default ports for each protocol. You can only apply one global policy, so if you want to alter the global policy, for example, to apply inspection to non-standard ports, or to add inspections that are not enabled by default, you need to either edit the default policy or disable it and apply a new one.
Table 23-1 lists all inspections supported, the default ports used in the default class map, and the inspection engines that are on by default, shown in bold. This table also notes any NAT limitations.
Table 23-1 Supported Application Inspection Engines
CTIQBE
TCP/2748
—
—
—
DNS over UDP
UDP/53
No NAT support is available for name resolution through WINS.
RFC 1123
No PTR records are changed.
FTP
TCP/21
—
RFC 959
—
GTP
UDP/3386
UDP/2123—
—
Requires a special license.
H.323 H.225 and RAS
TCP/1720 UDP/1718
UDP (RAS) 1718-1719No NAT on same security interfaces.
No static PAT.
ITU-T H.323, H.245, H225.0, Q.931, Q.932
—
HTTP
TCP/80
—
RFC 2616
Beware of MTU limitations stripping ActiveX and Java. If the MTU is too small to allow the Java or ActiveX tag to be included in one packet, stripping may not occur.
ICMP
—
—
—
All ICMP traffic is matched in the default class map.
ICMP ERROR
—
—
—
All ICMP traffic is matched in the default class map.
ILS (LDAP)
TCP/389
No PAT.
—
—
MGCP
UDP/2427, 2727
—
RFC 2705bis-05
—
NetBIOS Name Server over IP
UDP/137, 138 (Source ports)
—
—
NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138.
PPTP
TCP/1723
—
RFC 2637
—
RSH
TCP/514
No PAT
Berkeley UNIX
—
RTSP
TCP/554
No PAT.
No outside NAT.
RFC 2326, 2327, 1889
No handling for HTTP cloaking.
SIP
TCP/5060
UDP/5060No outside NAT.
No NAT on same security interfaces.
RFC 2543
—
SKINNY (SCCP)
TCP/2000
No outside NAT.
No NAT on same security interfaces.
—
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances.
SMTP and ESMTP
TCP/25
—
RFC 821, 1123
—
SNMP
UDP/161, 162
No NAT or PAT.
RFC 1155, 1157, 1212, 1213, 1215
v.2 RFC 1902-1908; v.3 RFC 2570-2580.
SQL*Net
TCP/1521
—
—
v.1 and v.2.
Sun RPC over UDP and TCP
UDP/111
No NAT or PAT.
—
The default rule includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new rule that matches TCP port 111 and performs Sun RPC inspection.
TFTP
UDP/69
—
RFC 1350
Payload IP addresses are not translated.
XDCMP
UDP/177
No NAT or PAT.
—
—
1 Inspection engines that are enabled by default for the default port are in bold.
2 The FWSM is in compliance with these standards, but it does not enforce compliance on packets being inspected. For example, FTP commands are supposed to be in a particular order, but the FWSM does not enforce the order.
Configuring Application Inspection
This feature uses Security Policy Rules. Service policies provide a consistent and flexible way to configure FWSM features. For example, you can use a service policy to create a timeout configuration that is specific to a particular TCP application, as opposed to one that applies to all TCP applications. See Chapter 22, "Configuring Service Policy Rules," for more information.
Inspection is enabled by default for some applications. See the "Default Inspection Policy" section for more information. Use this section to modify your inspection policy.
To configure application inspection, perform the following steps:
Step 1
Step 2
If you want to match non-standard ports, then create a new rule for the non-standard ports. See the "Default Inspection Policy" section for the standard ports for each inspection engine. You can combine multiple rules in the same service policy if desired, so you can create one rule to match certain traffic, and another to match different traffic. However, if traffic matches a rule that contains an inspection action, and then matches another rule that also has an inspection action, only the first matching rule is used.
Step 3
For a new rule, the dialog box is called Add Service Policy Rule Wizard - Rule Actions.
Step 4
Step 5
You can either choose an existing map, or create a new one. You can predefine inspect maps from the Configuration > Firewall > Objects > Inspect Maps pane. See the "Inspect Map Field Descriptions" section for detailed information of each inspect map type.
Step 6
Step 7
CTIQBE Inspection
This section describes CTIQBE application inspection. This section includes the following topics:
CTIQBE Inspection Overview
CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the FWSM.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.
Limitations and Restrictions
The following summarizes limitations that apply when using CTIQBE application inspection:
•
•
•
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
•
•
•
DCERPC Inspection
DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.
This typically involves a client querying a server called the Endpoint Mapper listening on a well known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The FWSM allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.
DCERPC inspect maps inspect for native TCP communication between the EPM and client on well known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and Port number are received from the applicable EPM response messages. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.
DNS Inspection
This section describes DNS application inspection. This section includes the following topics:
•
How DNS Application Inspection Works
The FWSM tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the FWSM. The FWSM also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
When DNS inspection is enabled, which is the default, the FWSM performs the following additional tasks:
•
Note
•
•
•
•
A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the FWSM within a limited period of time and there is no resource build-up. However, if you enter the show conn command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.
How DNS Rewrite Works
When DNS inspection is enabled, DNS rewrite provides full support for NAT of DNS messages originating from any interface.
If a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the A-record is not translated.
As long as DNS inspection remains enabled, you can configure DNS rewrite using a NAT rule.
DNS Rewrite performs two functions:
•
•
In Figure 23-1, the DNS server resides on the external (ISP) network The real address of the server (192.168.100.1) has been mapped using a static NAT rule to the ISP-assigned address (209.165.200.5). When a web client on the inside interface attempts to access the web server with the URL http://server.example.com, the host running the web client sends a DNS request to the DNS server to resolve the IP address of the web server. The FWSM translates the non-routable source address in the IP header and forwards the request to the ISP network on its outside interface. When the DNS reply is returned, the FWSM applies address translation not only to the destination address, but also to the embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result, the web client on the inside network gets the correct address for connecting to the web server on the inside network.
Figure 23-1 Translating the Address in a DNS Reply (DNS Rewrite)
DNS rewrite also works if the client making the DNS request is on a DMZ network and the DNS server is on an inside interface.
ESMTP Inspection
ESMTP inspection detects attacks, including spam, phising, malformed message attacks, buffer overflow/underflow attacks. It also provides support for application security and protocol conformance, which enforce the sanity of the ESMTP messages as well as detect several attacks, block senders/receivers, and block mail relay.
FTP Inspection
This section describes the FTP inspection engine. This section includes the following topics:
•
FTP Inspection Overview
The FTP application inspection inspects the FTP sessions and performs four tasks:
•
•
•
•
FTP application inspection prepares secondary channels for FTP data transfer. Ports for these channels are negotiated through PORT or PASV commands. The channels are allocated in response to a file upload, a file download, or a directory listing event.
Note
Using Strict FTP
Using strict FTP increases the security of protected networks by preventing web browsers from sending embedded commands in FTP requests. To enable strict FTP, click the Configure button next to FTP on the Configuration > Firewall > Service Policy Rules > Edit Service Policy Rule > Rule Actions > Protocol Inspection tab.
Note
After you enable the Strict option on an interface, FTP inspection enforces the following behavior:
•
•
•
Caution
If the strict option is enabled, each FTP command and response sequence is tracked for the following anomalous activity:
•
•
•
•
•
•
•
•
•
Verifying and Monitoring FTP Inspection
FTP application inspection generates the following log messages:
•
•
•
•
•
In conjunction with NAT, the FTP application inspection translates the IP address within the application payload. This is described in detail in RFC 959.
GTP Inspection
Note
GPRS provides uninterrupted connectivity for mobile subscribers between GSM networks and corporate networks or the Internet. The GGSN is the interface between the GPRS wireless data network and other networks. The SGSN performs mobility, data session management, and data compression (See Figure 23-2).
Figure 23-2 GPRS Tunneling Protocol
The UMTS is the commercial convergence of fixed-line telephony, mobile, Internet and computer technology. UTRAN is the networking protocol used for implementing wireless networks in this system. GTP allows multi-protocol packets to be tunneled through a UMTS/GPRS backbone between a GGSN, an SGSN and the UTRAN.
GTP does not include any inherent security or encryption of user data, but using GTP with the FWSM helps protect your network against these risks.
The SGSN is logically connected to a GGSN using GTP. GTP allows multiprotocol packets to be tunneled through the GPRS backbone between GSNs. GTP provides a tunnel control and management protocol that allows the SGSN to provide GPRS network access for a mobile station by creating, modifying, and deleting tunnels. GTP uses a tunneling mechanism to provide a service for carrying user data packets.
Note
H.323 Inspection
This section describes the H.323 application inspection. This section includes the following topics:
H.323 Inspection Overview
H.323 inspection provides support for H.323 compliant applications such as Cisco CallManager and VocalTec Gatekeeper. H.323 is a suite of protocols defined by the International Telecommunication Union for multimedia conferences over LANs. The FWSM supports H.323 through Version 4, including H.323 v3 feature Multiple Calls on One Call Signaling Channel.
With H323 inspection enabled, the FWSM supports multiple calls on the same call signaling channel, a feature introduced with H.323 Version 3. This feature reduces call setup time and reduces the use of ports on the FWSM.
The two major functions of H.323 inspection are as follows:
•
•
How H.323 Works
The H.323 collection of protocols collectively may use up to two TCP connection and four to six UDP connections. FastConnect uses only one TCP connection, and RAS uses a single UDP connection for registration, admissions, and status.
An H.323 client may initially establish a TCP connection to an H.323 server using TCP port 1720 to request Q.931 call setup. As part of the call setup process, the H.323 terminal supplies a port number to the client to use for an H.245 TCP connection. In environments where H.323 gatekeeper is in use, the initial packet is transmitted using UDP.
H.323 inspection monitors the Q.931 TCP connection to determine the H.245 port number. If the H.323 terminals are not using FastConnect, the FWSM dynamically allocates the H.245 connection based on the inspection of the H.225 messages.
Within each H.245 message, the H.323 endpoints exchange port numbers that are used for subsequent UDP data streams. H.323 inspection inspects the H.245 messages to identify these ports and dynamically creates connections for the media exchange. RTP uses the negotiated port number, while RTCP uses the next higher port number.
The H.323 control channel handles H.225 and H.245 and H.323 RAS. H.323 inspection uses the following ports.
•
•
•
You must permit traffic for the well-known H.323 port 1720 for the H.225 call signaling; however, the H.245 signaling ports are negotiated between the endpoints in the H.225 signaling. When an H.323 gatekeeper is used, the FWSM opens an H.225 connection based on inspection of the ACF message.
After inspecting the H.225 messages, the FWSM opens the H.245 channel and then inspects traffic sent over the H.245 channel as well. All H.245 messages passing through the FWSM undergo H.245 application inspection, which translates embedded IP addresses and opens the media channels negotiated in H.245 messages.
The H.323 ITU standard requires that a TPKT header, defining the length of the message, precede the H.225 and H.245, before being passed on to the reliable connection. Because the TPKT header does not necessarily need to be sent in the same TCP packet as H.225 and H.245 messages, the FWSM must remember the TPKT length to process and decode the messages properly. For each connection, the FWSM keeps a record that contains the TPKT length for the next expected message.
If the FWSM needs to perform NAT on IP addresses in messages, it changes the checksum, the UUIE length, and the TPKT, if it is included in the TCP packet with the H.225 message. If the TPKT is sent in a separate TCP packet, the FWSM proxy ACKs that TPKT and appends a new TPKT to the H.245 message with the new length.
Note
Each UDP connection with a packet going through H.323 inspection is marked as an H.323 connection and times out with the H.323 timeout as configured on the Configuration > Firewall > Advanced > Global Timeouts pane.
Limitations and Restrictions
The following are some of the known issues and limitations when using H.323 application inspection:
•
•
•
•
HTTP Inspection
Use the HTTP inspection engine to protect against specific attacks and other threats that may be associated with HTTP traffic. HTTP inspection performs several functions:
•
•
•
The latter two features are configured in conjunction with Filter rules.
The enhanced HTTP inspection feature, which is also known as an application firewall and is available when you configure an HTTP inspect map (see the "HTTP Class Map" section), can help prevent attackers from using HTTP messages for circumventing network security policy. It verifies the following for all HTTP messages:
•
•
•
Instant Messaging Inspection
The IM inspect engine lets you apply fine grained controls on the IM application to control the network usage and stop leakage of confidential data, propagation of worms, and other threats to the corporate network.
ICMP Inspection
The ICMP inspection engine allows ICMP traffic to have a "session" so it can be inspected like TCP and UDP traffic. Without the ICMP inspection engine, we recommend that you do not allow ICMP through the FWSM in an access list. Without stateful inspection, ICMP can be used to attack your network. The ICMP inspection engine ensures that there is only one response for each request, and that the sequence number is correct.
ICMP Error Inspection
When this feature is enabled, the FWSM creates translation sessions for intermediate hops that send ICMP error messages, based on the NAT configuration. The FWSM overwrites the packet with the translated IP addresses.
When disabled, the FWSM does not create translation sessions for intermediate nodes that generate ICMP error messages. ICMP error messages generated by the intermediate nodes between the inside host and the FWSM reach the outside host without consuming any additional NAT resource. This is undesirable when an outside host uses the traceroute command to trace the hops to the destination on the inside of the FWSM. When the FWSM does not translate the intermediate hops, all the intermediate hops appear with the mapped destination IP address.
The ICMP payload is scanned to retrieve the five-tuple from the original packet. Using the retrieved five-tuple, a lookup is performed to determine the original address of the client. The ICMP error inspection engine makes the following changes to the ICMP packet:
•
•
•
–
–
–
ILS Inspection
The ILS inspection engine provides NAT support for Microsoft NetMeeting, SiteServer, and Active Directory products that use LDAP to exchange directory information with an ILS server.
The FWSM supports NAT for ILS, which is used to register and locate endpoints in the ILS or SiteServer Directory. PAT cannot be supported because only IP addresses are stored by an LDAP database.
For search responses, when the LDAP server is located outside, NAT should be considered to allow internal peers to communicate locally while registered to external LDAP servers. For such search responses, xlates are searched first, and then DNAT entries to obtain the correct address. If both of these searches fail, then the address is not changed. For sites using NAT 0 (no NAT) and not expecting DNAT interaction, we recommend that the inspection engine be turned off to provide better performance.
Additional configuration may be necessary when the ILS server is located inside the FWSM border. This would require a hole for outside clients to access the LDAP server on the specified port, typically TCP 389.
Because ILS traffic only occurs on the secondary UDP channel, the TCP connection is disconnected after the TCP inactivity interval. By default, this interval is 60 minutes and can be adjusted using the Configuration > Firewall > Advanced > Global Timeouts pane.
ILS/LDAP follows a client/server model with sessions handled over a single TCP connection. Depending on the client's actions, several of these sessions may be created.
During connection negotiation time, a BIND PDU is sent from the client to the server. Once a successful BIND RESPONSE from the server is received, other operational messages may be exchanged (such as ADD, DEL, SEARCH, or MODIFY) to perform operations on the ILS Directory. The ADD REQUEST and SEARCH RESPONSE PDUs may contain IP addresses of NetMeeting peers, used by H.323 (SETUP and CONNECT messages) to establish the NetMeeting sessions. Microsoft NetMeeting v2.X and v3.X provides ILS support.
The ILS inspection performs the following operations:
•
•
•
•
•
•
•
ILS inspection has the following limitations:
•
•
•
Note
MGCP Inspection
MGCP is a master/slave protocol used to control media gateways from external call control elements called media gateway controllers or call agents. A media gateway is typically a network element that provides conversion between the audio signals carried on telephone circuits and data packets carried over the Internet or over other packet networks. Using NAT and PAT with MGCP lets you support a large number of devices on an internal network with a limited set of external (global) addresses. Examples of media gateways are:
•
•
•
MGCP messages are transmitted over UDP. A response is sent back to the source address (IP address and UDP port number) of the command, but the response may not arrive from the same address as the command was sent to. This can happen when multiple call agents are being used in a failover configuration and the call agent that received the command has passed control to a backup call agent, which then sends the response. Figure 23-3 illustrates how NAT can be used with MGCP.
Figure 23-3 Using NAT with MGCP
MGCP endpoints are physical or virtual sources and destinations for data. Media gateways contain endpoints on which the call agent can create, modify and delete connections to establish and control media sessions with other multimedia endpoints. Also, the call agent can instruct the endpoints to detect certain events and generate signals. The endpoints automatically communicate changes in service state to the call agent.
MGCP transactions are composed of a command and a mandatory response. There are eight types of commands:
•
•
•
•
•
•
•
•
The first four commands are sent by the call agent to the gateway. The Notify command is sent by the gateway to the call agent. The gateway may also send a DeleteConnection. The registration of the MGCP gateway with the call agent is achieved by the RestartInProgress command. The AuditEndpoint and the AuditConnection commands are sent by the call agent to the gateway.
All commands are composed of a Command header, optionally followed by a session description. All responses are composed of a Response header, optionally followed by a session description.
•
•
Note
NetBIOS Inspection
NetBIOS inspection is enabled by default. The NetBios inspection engine translates IP addresses in the NetBios name service (NBNS) packets according to the FWSM NAT configuration.
PPTP Inspection
PPTP is a protocol for tunneling PPP traffic. A PPTP session is composed of one TCP channel and usually two PPTP GRE tunnels. The TCP channel is the control channel used for negotiating and managing the PPTP GRE tunnels. The GRE tunnels carries PPP sessions between the two hosts.
When enabled, PPTP application inspection inspects PPTP protocol packets and dynamically creates the GRE connections and xlates necessary to permit PPTP traffic. Only Version 1, as defined in RFC 2637, is supported.
PAT is only performed for the modified version of GRE [RFC 2637] when negotiated over the PPTP TCP control channel. Port Address Translation is not performed for the unmodified version of GRE [RFC 1701, RFC 1702].
Specifically, the FWSM inspects the PPTP version announcements and the outgoing call request/response sequence. Only PPTP Version 1, as defined in RFC 2637, is inspected. Further inspection on the TCP control channel is disabled if the version announced by either side is not Version 1. In addition, the outgoing-call request and reply sequence are tracked. Connections and xlates are dynamic allocated as necessary to permit subsequent secondary GRE data traffic.
The PPTP inspection engine must be enabled for PPTP traffic to be translated by PAT. Additionally, PAT is only performed for a modified version of GRE (RFC2637) and only if it is negotiated over the PPTP TCP control channel. PAT is not performed for the unmodified version of GRE (RFC 1701 and RFC 1702).
As described in RFC 2637, the PPTP protocol is mainly used for the tunneling of PPP sessions initiated from a modem bank PAC (PPTP Access Concentrator) to the headend PNS (PPTP Network Server). When used this way, the PAC is the remote client and the PNS is the server.
However, when used for VPN by Windows, the interaction is inverted. The PNS is a remote single-user PC that initiates connection to the head-end PAC to gain access to a central network.
RSH Inspection
RSH inspection is enabled by default. The RSH protocol uses a TCP connection from the RSH client to the RSH server on TCP port 514. The client and server negotiate the TCP port number where the client listens for the STDERR output stream. RSH inspection supports NAT of the negotiated port number if necessary.
RTSP Inspection
This section describes RTSP application inspection. This section includes the following topics:
RTSP Inspection Overview
The RTSP inspection engine lets the FWSM pass RTSP packets. RTSP is used by RealAudio, RealNetworks, Apple QuickTime 4, RealPlayer, and Cisco IP/TV connections.
Note
RTSP applications use the well-known port 554 with TCP (rarely UDP) as a control channel. The FWSM only supports TCP, in conformity with RFC 2326. This TCP control channel is used to negotiate the data channels that is used to transmit audio/video traffic, depending on the transport mode that is configured on the client.
The supported RDT transports are: rtp/avp, rtp/avp/udp, x-real-rdt, x-real-rdt/udp, and x-pn-tng/udp.
The FWSM parses Setup response messages with a status code of 200. If the response message is travelling inbound, the server is outside relative to the FWSM and dynamic channels need to be opened for connections coming inbound from the server. If the response message is outbound, then the FWSM does not need to open dynamic channels.
Because RFC 2326 does not require that the client and server ports must be in the SETUP response message, the FWSM keeps state and remembers the client ports in the SETUP message. QuickTime places the client ports in the SETUP message and then the server responds with only the server ports.
RTSP inspection does not support PAT or dual-NAT. Also, the FWSM cannot recognize HTTP cloaking where RTSP messages are hidden in the HTTP messages.
Using RealPlayer
When using RealPlayer, it is important to properly configure transport mode. For the FWSM, add an Access Rule from the server to the client or vice versa. For RealPlayer, change transport mode by clicking Options>Preferences>Transport>RTSP Settings.
If using TCP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use TCP for all content check boxes. On the FWSM, there is no need to configure the inspection engine.
If using UDP mode on the RealPlayer, select the Use TCP to Connect to Server and Attempt to use UDP for static content check boxes, and for live content not available via Multicast. On the FWSM, add an inspect rtsp port command.
Restrictions and Limitations
The following restrictions apply to RTSP inspection:
•
•
•
•
•
•
SIP Inspection
This section describes SIP application inspection. This section includes the following topics:
SIP Inspection Overview
SIP, as defined by the IETF, enables call handling sessions, particularly two-party audio conferences, or "calls." SIP works with SDP for call signalling. SDP specifies the ports for the media stream. Using SIP, the FWSM can support any SIP VoIP gateways and VoIP proxy servers. SIP and SDP are defined in the following RFCs:
•
•
To support SIP calls through the FWSM, signaling messages for the media connection addresses, media ports, and embryonic connections for the media must be inspected, because while the signaling is sent over a well-known destination port (UDP/TCP 5060), the media streams are dynamically allocated. Also, SIP embeds IP addresses in the user-data portion of the IP packet. SIP inspection applies NAT for these embedded IP addresses.
The following limitations and restrictions apply when using PAT with SIP:
•
–
–
–
•
SIP Instant Messaging
Instant Messaging refers to the transfer of messages between users in near real-time. SIP supports the Chat feature on Windows XP using Windows Messenger RTC Client version 4.7.0105 only. The MESSAGE/INFO methods and 202 Accept response are used to support IM as defined in the following RFCs:
•
•
MESSAGE/INFO requests can come in at any time after registration/subscription. For example, two users can be online at any time, but not chat for hours. Therefore, the SIP inspection engine opens pinholes that time out according to the configured SIP timeout value. This value must be configured at least five minutes longer than the subscription duration. The subscription duration is defined in the Contact Expires value and is typically 30 minutes.
Because MESSAGE/INFO requests are typically sent using a dynamically allocated port other than port 5060, they are required to go through the SIP inspection engine.
Note
SIP inspection translates the SIP text-based messages, recalculates the content length for the SDP portion of the message, and recalculates the packet length and checksum. It dynamically opens media connections for ports specified in the SDP portion of the SIP message as address/ports on which the endpoint should listen.
SIP inspection has a database with indices CALL_ID/FROM/TO from the SIP payload. These indices identify the call, the source, and the destination. This database contains the media addresses and media ports found in the SDP media information fields and the media type. There can be multiple media addresses and ports for a session. The FWSM opens RTP/RTCP connections between the two endpoints using these media addresses/ports.
The well-known port 5060 must be used on the initial call setup (INVITE) message; however, subsequent messages may not have this port number. The SIP inspection engine opens signaling connection pinholes, and marks these connections as SIP connections. This is done for the messages to reach the SIP application and be translated.
As a call is set up, the SIP session is in the "transient" state until the media address and media port is received from the called endpoint in a Response message indicating the RTP port the called endpoint listens on. If there is a failure to receive the response messages within one minute, the signaling connection is torn down.
Once the final handshake is made, the call state is moved to active and the signaling connection remains until a BYE message is received.
If an inside endpoint initiates a call to an outside endpoint, a media hole is opened to the outside interface to allow RTP/RTCP UDP packets to flow to the inside endpoint media address and media port specified in the INVITE message from the inside endpoint. Unsolicited RTP/RTCP UDP packets to an inside interface does not traverse the FWSM, unless the FWSM configuration specifically allows it.
Skinny (SCCP) Inspection
This section describes SCCP application inspection. This section includes the following topics:
SCCP Inspection Overview
Skinny (SCCP) is a simplified protocol used in VoIP networks. Cisco IP Phones using SCCP can coexist in an H.323 environment. When used with Cisco CallManager, the SCCP client can interoperate with H.323 compliant terminals. Application layer functions in the FWSM recognize SCCP Version 3.3. There are 5 versions of the SCCP protocol: 2.4, 3.0.4, 3.1.1, 3.2, and 3.3.2. The FWSM supports all versions through Version 3.3.2.
The FWSM supports PAT and NAT for SCCP. PAT is necessary if you have more IP phones than global IP addresses for the IP phones to use. By supporting NAT and PAT of SCCP Signaling packets, Skinny application inspection ensures that all SCCP signalling and media packets can traverse the FWSM.
Normal traffic between Cisco CallManager and Cisco IP Phones uses SCCP and is handled by SCCP inspection without any special configuration. The FWSM also supports DHCP options 150 and 66, which it accomplishes by sending the location of a TFTP server to Cisco IP Phones and other DHCP clients. Cisco IP Phones might also include DHCP option 3 in their requests, which sets the default route.
Supporting Cisco IP Phones
In topologies where Cisco CallManager is located on the higher security interface with respect to the Cisco IP Phones, if NAT is required for the Cisco CallManager IP address, the mapping must be static as a Cisco IP Phone requires the Cisco CallManager IP address to be specified explicitly in its
