Translation Versus Connection
Consider this scenario: A single user on a workstation located on the internal network is
connecting to his web-based e-mail account, making an online stock purchase, researching a
new software package that he intends to buy, and backing up a database at a remote branch
office. How many connections does he have going from his workstation? It is difficult to tell
because many of these tasks require multiple connections between the source and
destination. How many translated sessions does he have going? One.
10.10.10.10
10.10.10.1
Internet
192.168.0.1
Perimeter Router
192.168.0.2
Mail
172.16.1.2
10.10.10.11
10.10.10.12
All internal nodes will be NAT to 192.168.0.10 to
192.168.0.61 and then PAT to 192.168.0.62.
All devices on the DMZ segment will have a static
translation to 192.168.0.3 (mail) .4 (web) .5(DNS).
Web
172.16.1.3
DNS
172.16.1.4
Translation Versus Connection 127
Most configurations create a single translated session, and from that session, the user can
create multiple connections. It is possible to create multiple translated sessions. This
normally occurs when the internal node is accessing resources via different network segments
all attached to the firewall (such as outside, DMZ1, DMZ2, and so on).
Translation occurs at the network layer (Layer 3) of the OSI reference model and deals only
with packets. Connections, however, deal with the transport layer (Layer 4). Therefore,
connections can be considered a subset of a single translation. It is possible to troubleshoot
both translation and connection issues. It is recommended that you verify translation before
attempting to troubleshoot a connection problem because the connection cannot be
established if the translation has not occurred.
The argument or keyword used to troubleshoot translations is xlate. You can see the
translation table by using the command show xlate, or you can clear the table with clear
xlate. Any time you make a change to the translation table, it is a good idea to use clear xlate.
This forces the translation slots to drop, and the Cisco Security Appliance rebuilds the
translation table. If you do not run the clear xlate command, the system does not drop the
translation slots until they time out, which is 3 hours by default. The following commands
can make a change to the translation table:
■ nat—Identifies the internal address that should be translated.
■ global—Identifies the external address or addresses to which internal addresses translate.
■ static—Allows external users to connect to specific addresses and have the Security
Appliance redirect that connection specific internal/DMZ address. The static command
also can be used for port redirection.
■ route—Provides routing functionality for traffic that is traversing the PIX Firewall.
■ alias—Was used to translate addresses between overlapping networks but now is used
infrequently because of the recent improvements in the functionality of the nat and static
commands.
■ conduit—Configures the firewall to apply specific rules based on conduits to the traffic.
Conduits are not commonly used because of the increased performance and functionality
of ACLs.
Table 5-3 documents the options and arguments that are available with the show xlate and
clear xlate commands. Table 5-4 lists the translation flags.
Table 5-3 show/clear xlate Command Options
Command Option Description
detail If specified, displays the translation type and interface
information
[global | local ip1[-ip2] [netmask mask] Displays active translations by global IP address or local
IP address using the network mask to qualify the IP
address
interface if1 [,if2] [,ifn] Displays active translations by interface
lport | gport port [-port] Displays active translations by local and global ports
state Displays active translations by state (use the translation
flags listed in Table 5-4)
Table 5-4 Translation Flags
Flag Description
s Static translation slot
d Dumps the translation slot on the next cleaning cycle
r Port map translation (PAT)
n No randomization of TCP sequence number
o Outside address translations
i Inside address translations
D DNS A Resource Record rewrite
I Identity translation from nat0
If you cannot clear xlate, it is possible (but not preferred) to clear the translation table by
doing a reload or by rebooting the PIX Firewall.
The command used to troubleshoot connections is show conn. This command displays the
number and status of all active TCP connections for the specific options selected. Table 5-5
lists the many options for the show conn command. Table 5-6 lists the connection flags.
Table 5-5 show conn Command Options
Command Option Description
count Displays the number of used connections (its accuracy
depends on the volume and type of traffic)
detail Displays the specified translation type and interface
information
foreign | local ip [-ip2] netmask mask Displays active connections by foreign or local IP address
and qualifies connections by network mask
fport | lport port1 [-port2] Displays foreign or local active connections by port
protocol tcp | udp | protocol Displays active connections by protocol type
state Displays active connections by their current state (see
Table 5-6)
Table 5-6 Connection Flags
Flag Description
U Up
f Inside FIN
F Outside FIN
r Inside acknowledged FIN
R Outside acknowledged FIN
s Awaiting outside SYN
S Awaiting inside SYN
M SMTP data
T TCP SIP connection
I Inbound data
O Outbound data
q SQL*Net data
d Dump
continues
Support
It is not necessary to configure DNS support on Cisco Security Appliance. By default, the
Security Appliance identifies each outbound DNS request and allows only a single response
to that request. The internal host can query several DNS servers for a response, and the
Security Appliance allows the outbound queries. However, the Security Appliance allows
only the first response to pass through the firewall. All subsequent responses to the original
query are dropped.
PIX Version 6.3(2) includes a DNS fixup protocol that enables you to configure a maximum
packet length for connections to UDP port 53. The default value is 512 bytes. If you
configure the DNS fixup protocol, the Security Appliance drops all connections to UDP port
53 that exceed the configured maximum length. The command for this configuration is
fixup protocol dns [maximum length <512-65535>]
P Inside back connection
E Outside back connection
G Group
a Awaiting outside ACK to SYN
A Awaiting inside ACK to SYN
B Initial SYN from outside
R RPC
H H.323
T UDP SIP connection
m SIP media connection
t SIP transient connection
D DNS
Table 5-6