Embedded Addressing Information

Probably one of the main problems of address translation is that it breaks certain applications?specifically, those that embed and use addressing information in packet payloads. I talked about this problem with reflexive ACLs in Chapter 8, "Reflexive Access Lists," and CBAC in Chapter 9, "Context-Based Access Control." CBAC has some mechanisms to deal with supported applications to handle a stateful firewall function. CBAC looks for the setup of additional connections by examining the control connection and then adds these extra connections, as appropriate, to its state table. However, if you are using address translation, CBAC does not actually perform the translation. Therefore, if you are using private addresses inside your network, you must use address translation. Your Cisco IOS also must translate embedded address information in packet payloads for applications that have this tendency.

Actually, many applications and protocols embed addressing information in data payloads. This is a small list:

  • DNS replies and zone transfers

  • Routing updates

  • IGMP messages for multicasting

  • DHCP and BootP

  • Some HTML code

  • NetBIOS resolution

  • Many NetBIOS applications

  • Most multimedia applications

  • SQL Server connections

As you can see from this list, quite a few applications exhibit this behavior.

Problem with Embedding Addressing Information

Consider a simple example to see how embedding addressing information in packet payloads can cause connection problems. In Figure 12-1, an external client wants to access data on an Oracle database server using SQL Server for the connection. The network in which the database servers are located uses private addresses.

Figure 12-1. Embedded Address Example

[View full size image]
graphics/12fig01.gif


In this example, the data is distributed between two servers. Initially, the external user established a SQL Server connection to 192.1.1.1, the top database server. The router performs the address translation to the internal address that the server is using. When the Oracle server examines the data that the user wants, it realizes that it is on the other internal server, 10.0.0.2. The Oracle server sends back this IP address to the external user in the packet payload (the TCP data portion of the TCP segment). The external user's application then tries to establish a connection to the correct database server, 10.0.0.2.

The problem with this example is that when the router performs address translation, it looks only at the IP header, as well as the TCP and UDP headers (if PAT is being performed). Therefore, the router does not realize that an embedded address (10.0.0.2) needs to be translated in the reply that the top Oracle server sends to the external user. In this example, the external user needs to receive the address of 192.1.1.2 to establish the connection to the second server.

Supported Protocols and Applications

The Cisco IOS can look for embedded addressing information in packet payloads when it performs address translation. The Cisco IOS can examine embedded addressing information for a connection, compare this with the information that it has in its address translation table, and make the appropriate changes. However, not all applications are supported. By default, when the Cisco IOS is configured for address translation, it performs address translation on any packet header information, including the source and destination addresses in the IP header and the port numbers in the TCP and UDP headers. Beyond this point, the Cisco IOS might experience issues with address translation.

However, because many applications embed addressing information in packet payloads, the Cisco IOS supports some applications. On the Cisco IOS, this sometimes is referred to as Application Layer Gateway (ALG) address translation support. Table 12-1 lists the applications that the Cisco IOS examines for embedded addressing information. Cisco constantly is adding applications and protocols to this list.

Table 12-1. ALG Address Translation Support

Protocol or Application

Explanation

ICMP

Supports both NAT and PAT. With PAT, because ICMP does not have port numbers, the Cisco IOS uses sequential numbers to associate ICMP traffic with a particular inside device.

FTP

Examines the PORT and PASV commands in the TCP port 21 connection.

NetBIOS

Supports datagram, name, and session service connection examinations.

RealAudio

Examines additional connection setup requests for both embedded address and port information.

CuSeeMe

Examines additional connection setup requests for both embedded address and port information.

StreamWorks

Examines additional connection setup requests for both embedded address and port information.

DNS

Examines DNS replies and translates A and PTR addressing information (discussed in Chapter 11 concerning overlapping addresses). In this instance, if the DNS server is internal and responds with a local instead of a global address, and if the router has a matching static entry in its translation table, the router appropriately translates the addressing information in the DNS reply.

NetMeeting

Supports H.323v2 for NetMeeting 2.x and 3.x, and H.323v1 for 2.x; also supports NetMeeting Directory through Internet Locator Server (ILS), which is used to find other NetMeeting users.

GRE

Examines Generic Route Encapsulation (GRE) tunnel packets, and performs the necessary translation of encapsulated packets.

H.323v2

Examines Alerting, CommunicationModeCommand, Communication-ModeResponse, Facility, FastConnect, OpenLogicalChannel, OpenLogicalChannelAck, Progress, and Setup messages in the control connection. In Cisco IOS 12.2(2)T, it also can examine H.323v2 RAS connections.

H.323v3 and v4

As of Cisco IOS 12.3(1), supports interoperability with H.323v3 and v4, but does not examine any new message types introduced in these new versions.

SIP

Supports SIP as of Cisco IOS 12.2(8)T.

Skinny (SCCP)

Supports Skinny as of 12.1(5)T.

VDOLive

Examines additional connection setup requests for both embedded address and port information.

Vxtreme

Examines additional connection setup requests for both embedded address and port information.


Nonstandard Port Numbers

When examining supported applications for embedded addressing information, the Cisco IOS examines these applications only on their well-known port numbers. For example, the Cisco IOS examines TCP port 21 for FTP. This presents a problem, however, if FTP or other applications are using nonstandard port numbers. For example, you might be using 2021 instead of 21 for FTP. In this example, the Cisco IOS, by default, is not examining port 2021, so it will not translate embedded addressing information on this connection.

Given this issue, the Cisco IOS enables you to specify additional ports that the Cisco IOS should examine for their associated applications. This process, commonly called IP NAT Service, is similar to what PAM does for CBAC, as discussed in Chapter 9. However, whereas PAM is used for stateful connection inspection, IP NAT Service is used to examine supported application connections for embedded addressing information and then appropriately translating this information.

IP NAT Service Configuration

To configure IP NAT Service to examine nonstandard port numbers, us the ip nat service command. Here's the syntax of this command:






Router(config)# ip nat service list ACL_#_or_name ftp tcp port port_#

Router(config)# ip nat service sip tcp | udp port port_#

Router(config)# ip nat service skinny tcp port port_#


For FTP, you first must specify the number or name of a standard ACL. This ACL contains the IP address of the FTP server that has the local address to be translated. This is followed by the nonstandard port number that the FTP server is using.

NOTE

If your FTP server is using the default port as well as a nonstandard port, you must configure IP NAT Service for both ports. The address listed in the ACL also must be the inside local address of the server.


Support for nonstandard ports for SIP was added in Cisco IOS 12.2(8)T, allowing the Cisco IOS to listen on SIP messages. The default port number is 5060. Support for Skinny was added in Cisco IOS 12.1(5)T, which listens on Skinny messages on TCP port 2000. You must change this if your CallManager platform is listening on a different port than the default.

NOTE

Unfortunately, as you can see from the previous syntax, IP NAT Service supports only FTP, SIP, and Skinny. Therefore, the Cisco IOS cannot inspect any other application on a nonstandard port number. However, configuring CBAC on your router allows the Cisco IOS to perform address translation for other connection types.


IP NAT Service Example

Example 12-1 shows a sample of using IP NAT Service with FTP.

Example 12-1. Using IP NAT Service with FTP

Router(config)# ip nat service list 1 ftp tcp port 21

Router(config)# ip nat service list 1 ftp tcp port 2021

Router(config)# access-list 1 permit 10.0.0.1


In Example 12-1, the FTP server (10.0.0.1) is using both TCP ports 21 and 2021.