Static Translations

The PIX static command creates a persistent, one-to-one address translation rule to add to the xlate table. This entry is called a static translation slot or xlate. In its simplest form, the command maps a local IP address to a global IP address. This is often referred to as a static NAT translation.

Static address mappings are created to provide outside access to shared resources, such as web servers. These shared resources must be available to outside users or servers without an originating request from within the more secure interfaces of the firewall. Static mappings shouldn’t normally be used with user hosts because their mappings should be added on in an as-needed basis by standard NAT translations. The NAT translations exist only for the time needed and then are removed from the xlate table. Static mappings, on the other hand, stay in the xlate table permanently.

The command syntax includes the interfaces, highest then lowest, followed by the addresses that are reversed to be lowest then highest. Figure 19-10 shows an example of a DMZ server that needs to be accessed from the outside. The next lines show the basic syntax, followed by a simple example translating a protected server—192.168.2.3—to be accessible from the outside as 10.1.1.7. Yes, in real life, this wouldn’t be another private address.

Figure 19-10: Protected DMZ server that must be accessed from the outside

Pix(config)# static (hi_interface, lo_interface) lo_ip_address hi_ip_address
Pix(config)# static (dmz, outside) 10.1.1.7 192.168.2.3

Remember the following about static mappings:

After changing or removing a static command statement, use the clear xlate command to make sure the xlate table entries are valid.
Static mappings always take precedence over mappings created using the NAT command.
Never use an address in a global address pool for static mapping.

Static Alone Is Not Enough

Note that the xlate table translation created by the static command, by itself, won’t allow outside traffic to access the server. While the static command created a valid global address that could be used, ASA blocks traffic from lower security areas to higher. Enabling the inbound traffic by creating an access-list is still necessary. The static command creates the mapping and the access list allows users to use the static command mapping. The additional lines required to finish the previous example might look like this:

Pix(config)# static (static, outside) 10.1.1.7 192.168.2.3
Pix(config)# access-list acl_server permit tcp any host 10.1.1.7
Pix(config)# access-group acl_server in interface outsidePix(config)# clear xlate

The access list command is covered in the section “Access Control Lists,” and it won’t be included in the remaining static command examples, but remember, the static command is only part of the solution.

Static Command Options

The static command creates a persistent or permanent one-to-one address translation entry in the xlate table. When the translation is between a local IP address and a global IP address, it’s called static NAT. When the translation is between local and global ports, it is called static PAT. The Static Command options might not all be supported on all PIX Firewall OS versions. The following Syntax options are from version 6.2.

Static NAT

Use the following form of the static command to perform one-to-one address translation. Use the no form of the command to remove the static translation.

Pix(config)# static [(hi_interface, lo_interface)] global_ip local_ip [netmask mask] [norandomseq] [max_conn [em_limit]]
Pix(config)# no static [(hi_interface, lo_interface)] global_ip local_ip [netmask mask] [norandomseq] [max_conn [em_limit]]

hi_interface	The higher security-level interface between the two.
lo_interface	The lower security-level interface between the two.
global_ip	The real global address the local_ip is translated to.
local_ip	The internal address to be mapped.
netmask	The key word required before defining a network mask.
mask	This network mask applies to both the global_ip and local_ip addresses. Use 255.255.255.255 for host addresses. For a network or subnet address, use the appropriate mask, for example, 255.255.255.240.
norandomseq	Turns off the randomized TCP/IP packet’s sequence number feature for this translation because another firewall is also randomizing sequence numbers and the two together are scrambling the data. Opens a security hole in the firewall.
max_conn	Maximum simultaneous connections permitted through the static. Default is 0, which allows unlimited connections.
em_limit	The embryonic or half-open TCP connection limit. Setting this limit can prevent a common type of DoS attack. Default is 0, which allows unlimited connections.

Mapping a Range of Static Translations

While the Netmask Mask option is relatively common to see using 255.255.255.255 for host translations, it might not be obvious that using another mask would define multiple translations. The resulting range of static translations is known as net statics. In the following example, the addresses 192.168.2.33 to 192.168.2.46 will be translated to 10.1.1.33 to 10.1.1.46. Figure 19-11 shows a pool of shared servers in the DMZ that need to be mapped to global addresses.

Pix(config)# static (inside,outside) 10.1.1.32 192.168.2.32 netmask 255.255.255.240
Pix(config)# clear xlate

Figure 19-11: Pool of DMZ servers that need to be mapped to global IP addresses

The PIX Firewall won’t allow inbound traffic translations that would result in IP addresses identified as either network or broadcast addresses. When the static command is used with the Netmask Mask netmask mask option, the PIX Firewall uses the global IP address and mask to determine network and/or broadcast addresses. If a global IP address is a network or broadcast as defined by the mask, the PIX won’t allow the xlate table entry. In the previous example, 10.1.1.32 (network) and 10.1.1.47 (broadcast) weren’t allowed.

Static PAT

Use the following form of the static command to perform one-to-one port translation. Use the no form of the command to remove the static translation.

Pix(config)# static [(hi_interface, lo_interface)] {tcp | udp}{global_ip | interface}
global_port local_ip local_port [netmask mask][max_conn] [em_limit] [norandomseq]
Pix(config)# no static [(hi_interface, lo_interface)] {tcp | udp}{global_ip | interface}
global_port local_ip local_port [netmask mask][max_conn] [em_limit] [norandomseq]

global_ip	The real global address the local_ip is translated to
global_port	The real global port the local_port is translated to
interface	Overload the global address from interface
local_ip	The internal address to be mapped
local_port	The internally assigned port to be mapped

In the following example, outside FTP requests to the translated global address 10.1.1.7 are translated to the internal FTP server at 192.168.1.5.

Pix(config)# static (inside, outside) tcp 10.1.1.7 ftp 192.168.1.5 ftp

No Translation Required

If real global addresses are used in one or more of the DMZs, then translating those addresses isn’t necessary. In this case, use the following form of static command where the interface IP addresses are the same to literally translate the address to itself. Use the no form of the command to remove the xlate entry.

Pix(config)# static (hi_interface, lo_interface) ip_address ip_address
Pix(config)# static (dmz, outside) 10.1.1.7 10.1.1.7
Pix(config)# static (dmz, outside) 10.1.1.32 10.1.1.32 netmask 255.255.255.240
Pix(config)# clear xlate

The first example translated a single server to itself, while the second example used a network ID and a subnet mask to define a block of addresses to be mapped to themselves. Figure 19-12 shows the pool of DMZ servers mapped in the previous example.

Figure 19-12: A pool of DMZ servers that already have global IP addresses

TCP Intercept Feature

Since version 5.3 of the PIX OS, PIX Firewalls offer a TCP intercept feature. This feature allows the PIX Firewall to step in as a form of proxy for a server being buried by embryonic TCP session requests.

To use the TCP intercept feature, the Embryonic Connection Limit (the previous em_limit ) option must be configured to something larger than the default 0. Leaving the embryonic connection limit set to 0 directs the PIX Firewall to pass through all new TCP session requests. If the destination server doesn’t have TCP SYN attack protection, and most OSs offer only limited protection, then the system’s embryonic connection table overloads and all traffic stops. This is a common component of many DoS attacks.

The following example leaves the maximum connection setting unrestricted (0), but sets the embryonic connection limit to 100.

Pix(config)# static (inside, outside) 10.1.1.7 192.168.1.3 0 100

Note

The previous example is intended for demonstration purposes only and shouldn’t be considered a model for use. Setting either the maximum connections or the maximum embryonic connections can have serious repercussions for the server. Too-high values can provide no protection, while too-low values could unnecessarily restrict access to the device. The actual limits should be set based on the server’s performance capabilities. SYN attacks are addressed in the next chapter.

Once the embryonic connection limit is reached, and until the count falls below this limit, every SYN packet (new session request) bound for the mapped server (192.168.1.3) is intercepted by the PIX Firewall. The PIX then responds on behalf of the server with a SYN/ACK (Step 2) packet attempting to complete the connection. The PIX creates a state table entry with the pertinent information from the received packet. The original packet is dropped and the PIX waits for the client’s acknowledgment.

If the expected ACK is received (Step 3), completing the three-way handshake, a copy of the client’s SYN packet is sent to the local server, and the TCP three-way handshake is performed between the PIX Firewall and the server. If this three-way handshake is completed successfully, then the connection between the client and the server resumes as normal.

If, for any reason, the client doesn’t respond during the connection phase, then PIX Firewall retransmits the necessary segment using exponential back-offs, just as the server would and, eventually, discards the information.

Prior to version 5.3, if the embryonic connection limit was configured and the level was exceeded, the PIX Firewall simply dropped all new connection attempts. While this might have been better than nothing, the result was that the server was no longer available, which could have been the purpose of the attack.

Static Translations