CCNP BCMSN Exam Certification Guide (3rd Edition)

6-2. Routed Firewall Mode and Address Translation

When a firewall has IP addresses assigned to its interfaces, it acts as a router hop for packets passing through it. As well, all the traffic inspection and forwarding decisions are based on Layer 3 (IP address) parameters. This is called routed firewall mode.

NOTE

Cisco firewalls running PIX release 6.3 or earlier operate solely in routed firewall mode. Beginning with FWSM 2.2(1) and PIX 7.0, you can configure a firewall to operate in either routed or transparent firewall mode, but not both.

Each firewall interface must be connected to a different IP subnet and be assigned an IP address on that subnet. When a routed firewall is installed or inserted into a network for the first time, the network must become segmented across the firewall's interfaces. For example, where a single IP subnet used to be, the inside and outside interfaces now form the boundary of two separate subnets.

This can make the installation difficult, because some readdressing must take place. The easiest approach is to keep the original IP addressing on the firewall's inside interface, where the majority of protected hosts reside. The outside interface can take on an address from a new subnet that is shared between the firewall and the next-hop router. In other words, the outside of the firewall usually has fewer directly connected hosts to readdress to a new subnet.

Routed firewalls can also participate in IP routing by using a dynamic routing protocol such as RIP or OSPF. The firewall can coexist with other routers in the network and maintain a dynamic routing table.

In routed mode, Cisco firewalls provide security policies and traffic inspection using two basic principles:

• Address translation When a host on one firewall interface initiates a connection to a host on a different interface, the firewall must provide a way to translate the IP addresses across itself appropriately. Even if the IP addresses should appear identically on both sides of the firewall, a translation still must occur.

  One exception is when the same-security-traffic command is used to allow traffic to pass between interfaces with an identical security level. In that case, address translation can still be configured if it is needed, but it is not required. The other exception is when the no nat-control command is used. This is the default beginning with PIX 7.0. It allows hosts to initiate connections through the firewall without requiring address translation.

• Access control As soon as an address translation is established, traffic is inspected and allowed only if the appropriate interface access lists permit it.

This section covers the address translation process, which forms the basis of routed firewall mode, as relationships between inside and outside IP addresses are built as needed.

Defining Access Directions

A firewall differentiates its interfaces by providing more security to some and less security to others. Therefore, it is important to understand how the interfaces relate to each other and how access is provided as traffic moves through a firewall.

Outbound Access

Outbound access is defined as connections that are initiated from a higher-security interface toward a lower-security interface. In other words, users on a more-secure network want to connect to something on a less-secure network.

Examples of outbound access are connections from the inside (higher security) to the outside (lower security).

The firewall can limit the number of simultaneous connections that are used by an address translation, as well as how many embryonic (not fully initialized) connections can be formed.

You must configure two firewall mechanisms to allow outbound connections:

• Address translation Local (more-secure) addresses must be mapped to global (less-secure) addresses across two firewall interfaces.

• Outbound access The firewall builds only outbound connections that meet security policy requirements configured as an access list. (PIX platforms allow outbound connections to be initiated without an access list by default. The FWSM requires an access list to permit outbound connections.)

Inbound Access

Inbound access is defined as connections that are initiated from a lower-security interface toward a higher-security interface. In other words, users on a less-secure network want to connect to something on a more-secure network.

Examples of inbound access are connections from the outside to the inside.

The firewall can limit the number of simultaneous connections that are used by an address translation, as well as how many embryonic (not fully initialized) connections can be formed.

You must configure two firewall mechanisms to allow inbound connections:

• Address translation Local (more-secure) addresses must be mapped to global (less-secure) addresses across two firewall interfaces.

• Inbound access The firewall allows only inbound connections that meet security policy requirements configured as an access list. You must apply an access list to the lower-security interface to permit only the specific inbound connections that are to be allowed.

Same-Security Access

PIX 7.0 introduces the ability to configure multiple interfaces with the same level of security. In this case, it isn't easy to classify the traffic passing between same-security interfaces as inbound or outbound.

Why would you want to define two or more interfaces as having the same level of security? Perhaps the interfaces support groups of users or resources that should be allowed to freely exchange information. In other words, the user communities are equally trusted and are under the same administrative control.

In addition, Cisco firewalls have a finite number of unique security levels you can assign to interfaces. Security levels 0 to 100 can be used, representing the lowest to the highest security, respectively. On some firewall platforms, you can arbitrarily define logical firewall interfaces. If your environment needs to support more than 100 different firewall interfaces, you can't assign more than 100 unique security levels. Some of the interfaces have to be configured with identical security levels.

Same-security access has the following characteristics:

• Address translation You can choose to use or not use address translation between same-security interfaces.

• Access Where many of the firewall inspection features normally limit, filter, or inspect traffic in one direction (inbound or outbound), the same operations can occur in both directions between same-security interfaces.

  As well, traffic between same-security interfaces is inherently permitted without any requirement for access lists.

Types of Address Translation

A firewall can translate the IP addresses of hosts on one interface to identical or different addresses on another interface. This translation doesn't have to occur in the same fashion for all hosts on all interfaces. In fact, the firewall can be very flexible with address translation, depending on the needs of the hosts, their applications, or the security policies required.

As the firewall builds address translations, it maintains entries in a translation database. These are known as xlate entries, and they can be displayed using the show xlate command. (This command is more fully explained in Chapter 10, "Verifying Firewall Operation," in section 10-3, "Verifying Firewall Connectivity.") An xlate entry must exist before inbound connections are permitted to reach an inside host through an outside address.

For example, in the following output, the firewall is performing two different types of address translation. In the two lines that begin with Global, static NAT is being used. The local or inside address is always translated to the same global or outside address, regardless of what protocol or port number is being used.

In the lines that begin with PAT, Port Address Translation (PAT) is being used to allow multiple local or inside hosts to be translated to one or more global or outside addresses. The translation is performed dynamically on a per-connection basis. Each local address and port number used in a connection is translated to the global address, but with a unique global port number. The port numbers are shown in parentheses.

Firewall# show xlate 22499 in use, 24492 most used Global 10.1.1.17 Local 192.168.1.11 Global 10.1.1.16 Local 192.168.1.10 PAT Global 10.1.2.1(10476) Local 192.168.40.251(4705) PAT Global 10.1.2.1(10382) Local 192.168.48.11(3134) PAT Global 10.1.2.1(10372) Local 192.168.236.69(1716) [output omitted]

Fully initialized connections are also kept in a connection database. They are called conn entries, and they can be seen using the show conn command. Before two hosts can communicate through a firewall, an xlate entry must be created, a connection must be permitted by an access list (if one is required on an interface), and a conn entry must be created.

To continue the previous example, the following output from the show conn command displays any active connections currently being inspected by the firewall. (This command is more fully explained in section 10-3 of Chapter 10.)

Firewall# show conn UDP out 195.242.2.2:53 in 192.168.48.11:3134 idle 0:00:10 flags d TCP out 207.46.245.60:80 in 192.168.236.69:1716 idle 0:06:18 Bytes 937 flags UIO [output omitted]

The in addresses shown in these two lines correspond to the Local addresses of the last two lines in the xlate table of the previous example. Inside host 192.168.48.11 is using its UDP port 3134 to open a DNS request with outside host 195.242.2.2 on UDP port 53.

In the second line, inside host 192.168.236.69 has opened a connection to TCP port 80 on outside host 207.46.245.60. Notice that each entry in the conn table also has an idle timer and connection flags. The TCP conn entry also has a byte count, showing the total amount of data that has been sent or received over that connection.

Table 6-1 lists the types of address translation supported by Cisco firewalls, along with the respective configuration commands that can be used. Each translation type inherently allows connections to be initiated in the inbound, outbound, or both directions, as shown in the rightmost column.

The static command creates a persistent translation between a real and mapped address. This sets the stage to allow both outbound and inbound connections to be initiated. The actual xlate entries are created when the static command is entered.

In each of the nat command forms shown, the translation is used for outbound connections only, initiated by an inside host. Inbound traffic is then permitted only if it is return traffic from an outbound connection or if it is explicitly permitted by an inbound access list applied to the outside interface. One exception is NAT exemption, which allows connections to be initiated in the outbound and inbound directions.

Sometimes you might need to use a form of the nat command to translate the source addresses of outside hosts that are allowed to initiate connections. You can apply each of the nat translation processes in reverse by adding the outside keyword.

NOTE

In all forms of inside address translation (without the outside keyword), only the pertinent addresses on the higher-security interface are subject to translation. In other words, the inside source address is translated in the outbound direction, and the inside destination address is translated in the inbound direction.

The outside keyword reverses thisonly the addresses on the lower-security interface are subject to translation. This is often called outside NAT or bidirectional NAT.

Beginning with PIX 7.0, you can configure a firewall to allow two or more firewall interfaces to have an equal security level. In this case, there is no higher- or lower-security boundary between the two interfaces. Therefore, address translation doesn't apply between them.

If you configure several address translation operations, you might have some overlap between them. For example, the same local address might appear in more than one NAT definition. To resolve any ambiguity, the firewall evaluates the various types of NAT in the following order before creating an xlate entry:

1. NAT exemptions (nat 0 access-list commands)

2. Policy NAT (static access-list commands)

3. Static NAT (static commands without port numbers)

4. Static PAT (static commands with port numbers)

5. Policy NAT (nat nat_id access-list commands)

6. Dynamic NAT and PAT (nat nat_id commands)

If multiple commands of the same translation type are configured, they are evaluated in sequential order until the first match occurs.

Each type of address translation is described in more detail in the following sections.

NOTE

Be aware that the interface names, address, and port designations have changed in the firewall command syntax related to address translation. In PIX 6.x commands, the terms local and global are relative to inside and outside interfaces, respectively.

Beginning with FWSM 2.2 and PIX 7.0, address translation is configured using the terms real and mapped, referring to parameters before and after translation, respectively. Although real and mapped are used in this chapter, they can be used interchangeably with local and global.

Handling Connections Through an Address Translation

As soon as an address translation is set up across two firewall interfaces, hosts have the potential to open connections through the firewall. Hopefully, hosts that are permitted to traverse the firewall will be on their good behavior and will attempt to open only the legitimate connections they need. But if one connection can be initiated, multitudes more might follow, especially if malicious intent is involved. Fortunately, Cisco firewalls can enforce connection limits on hosts passing through.

Both the static and nat commands have parameters that can be configured to define connection limits. You can use the following parameter syntax, which can be found in each form of the static and nat commands presented in this chapter:

UDP and TCP Connection Limits

By default, a firewall allows an unlimited number of outbound connections to be opened across an address translation. If this situation is abused, it is possible to open so many connections that firewall resources and destination host resources become exhausted.

On all firewall platforms, you can limit this to max_conns (1 to 65535 simultaneous connections; the default is 0, or unlimited). This becomes the combined total of UDP and TCP connections that are initiated from the inside hosts using the address translation.

Beginning with FWSM and PIX 7.0, UDP and TCP connections can be limited separately for each host using the address translation. You can specify the maximum number of TCP connections with the tcp keyword followed by max_conns (1 to 65535 simultaneous connections; 0 for unlimited). You can set the maximum number of UDP "connections" with the udp keyword followed by udp_max_conns (1 to 65535; 0 for unlimited). Because UDP is a connectionless protocol, the firewall views each unique pair of host addresses and unique UDP port numbers as a separate connection that uses a conn table entry.

TIP

As soon as the connection limit for a host is reached, any subsequent connection attempt is dropped. However, any connections that have already been built are subject to a connection idle timeout. If the firewall doesn't see any data passing over a connection for a specified time period, that connection is closed automatically.

Separate idle timers are maintained for UDP and TCP connections. You can display the idle timer thresholds with the show timeout (FWSM and PIX 6.x) or show running-config timeout command, as shown in the following example. The TCP idle timer is shown as conn, and the UDP idle timer is udp:

Firewall# show running-config timeout timeout xlate 0:06:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02 sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute Firewall#

You can set the idle timers with the following configuration command:

You can set the TCP conn timer from 00:05:00 (5 minutes) to 1192:59:59 or set it to 0:00:00 for an unlimited time. You can set the UDP udp timer from 00:01:00 (1 minute) to 1192:59:59 or set it to 0:00:00 for an unlimited time. The TCP and UDP timers default to 1 hour and 2 minutes, respectively.

Limiting Embryonic Connections

By default, a firewall allows an unlimited number of TCP connections to be initiated to a target host across an address translation. Recall that a TCP connection must complete a three-way handshake (SYN-SYN/ACK-ACK) between two hosts before the connection can be established. If the handshake sequence is not yet completed, the connection is called an embryonic (initialized but not yet formed) connection.

An embryonic connection can result from a handshake that is delayed or lost. Therefore, under normal conditions, hosts maintain the initiated connection while they wait for the handshake to complete. A malicious user can also abuse this by attempting to initiate multitudes of embryonic connections to a target host as a denial-of-service attack. The malicious user never answers any of the SYN packets used to initiate the connections. Instead, the idea is to overwhelm the target with too many potential connections while it waits for the originator to answer with the handshake.

A firewall can limit the number of embryonic TCP connections initiated to a host across a translated address. This applies only to inbound connections, where outside hosts initiate TCP connections to inside hosts.

Until this limit is reached, the firewall inspects each SYN packet, adds a new conn table entry (marked as embryonic), and forwards the SYN to the destination host. If the inside host replies with a SYN/ACK, followed by an ACK from the outside host to complete the TCP connection handshake, the firewall updates its conn table entry (marked as open connections) and allows the connection to form. If the three-way handshake is not completed within 30 seconds, the firewall deletes the connection entry because of the "SYN timeout."

However, when the limit is reached or exceeded, the firewall begins to intercept each new SYN packet and answer on behalf of the target inside host. This is not added as an entry in the firewall's conn table. Instead, an "empty" SYN/ACK packet is returned to the outside host, as if the inside host had sent it. If the originating host actually replies with an ACK, the handshake is completed between the firewall and the inside host, and the connection is built.

In this fashion, the firewall acts as a connection proxy, absorbing the effects of an excessive number of TCP connection requests.

For address translation with the static command, this applies only to inbound connections aimed at higher-security interfaces. The limit, emb_limit (0 to 65535), defaults to 0 (an unlimited number of embryonic connections) and is ignored for outbound connections.

The opposite is true for the same embryonic connection limit emb_limit parameter in the nat command, which is applied to outbound connections aimed at lower-security interfaces. Here, you can limit the potential for denial-of-service attacks initiated by inside hosts.

TCP Initial Sequence Numbers

By default, when the firewall creates new outbound TCP connections, it assigns a randomized TCP initial sequence number (ISN). This is useful to prevent outside users from being able to predict or guess the sequence number and hijacking a connection.

Normally, hosts provide their own random ISNs when they initiate new TCP connections. However, the TCP/IP protocol stack in some operating systems has a weak implementation of this, allowing the ISN to be predicted. The firewall maintains the original ISN for use with the originating host and overwrites this value for use with the destination host. Therefore, neither the originating nor target host is aware that the ISN has been altered or further randomized.

Sometimes this additional ISN operation interferes with a protocol that is passing through a firewall. For example, some protocols such as BGP use a packet authentication method such as MD5 to preserve a message's integrity. The originating host computes a hash value over the whole TCP packet, including the original ISN, and includes this in the packet payload. To authenticate the message, the receiving host should be able to recompute the hash and get the same value.

However, if the ISN has been randomized after the original hash value was computed, a different hash value results, and the packet authentication fails. You can use the norandomseq keyword to keep the local firewall from changing the ISN so that only one firewall randomizes it.

TIP

You should always depend on the additional security provided by a firewall's ISN randomization unless you notice that it is creating problems with a protocol or application. Only then should you consider using the nondefault norandomseq setting to disable the randomization.

Static NAT

Static NAT can be used when an internal or real host needs to have the same mapped address for every outbound connection that is initiated. Inbound connections can also be initiated to the internal host if they are permitted by security policies.

Address translation occurs on a one-to-one persistent basis. Each static translation that is configured causes a static xlate entry to be created. Figure 6-2 illustrates static NAT operation during an outbound connection. Inside Host A initiates a connection to outside Host B. Notice that only the real (local) IP address is being translated, as the source address in the outbound direction, and as the destination address in the inbound direction for return traffic.

You can use the following command to configure a static NAT entry:

A static NAT entry is created across the firewall interfaces named real_ifc (inside, for example) and mapped_ifc (outside, for example). The real IP address real_ip is translated to the mapped IP address mapped_ip only when the firewall needs to forward a packet between the real_ifc and mapped_ifc interfaces. The addresses can be a single IP address (use netmask 255.255.255.255) or an entire IP subnet address (use netmask with the correct subnet mask). By default, if the netmask keyword is omitted, a host mask is assumed.

This command causes the address translation to be carried out regardless of the IP protocol or port number being used. If you need a static translation only for a specific UDP or TCP port number, you can define a static PAT entry with the following command:

Now the firewall translates the real_ip and real_port to the mapped_ip and mapped_port values.

The firewall can inspect and alter DNS packets if the dns keyword is added. If the real address is found in the packet, it is rewritten with the mapped address.

For example, consider two hosts that reside on the inside of a firewall, using private IP addresses 192.168.100.100 and 192.168.100.170. Outbound connections from these hosts should appear as 169.65.41.100 and 169.65.41.170, respectively. Because the hosts must always receive the same mapped addresses, static NAT should be used. Figure 6-3 shows a network diagram for this scenario.

The static NAT entries could be configured with the following commands:

Firewall(config)# static (inside,outside) 169.65.41.100 192.168.100.100 netmask 255.255.255.255 0 0 Firewall(config)# static (inside,outside) 169.65.41.170 192.168.100.170 netmask 255.255.255.255 0 0

The netmask is given as a host mask (255.255.255.255), because each translation is applied to a single host address.

To extend this example further, suppose inbound SMTP and HTTP connections to 169.65.41.100 could be sent to two separate inside hosts, each handling one of the two types of connections. Static PAT is a good solution for this scenario. With the following commands, SMTP connections are translated to inside host 192.168.100.100, and HTTP connections are translated to 192.168.100.200. An access list is also applied to the outside interface to permit inbound SMTP and HTTP connections.

Firewall(config)# static (inside,outside) tcp 169.65.41.100 smtp 192.168.100.100 smtp netmask 255.255.255.255 0 0 Firewall(config)# static (inside,outside) tcp 169.65.41.100 www 192.168.100.200 www netmask 255.255.255.255 0 0 Firewall(config)# access-list acl_outside permit tcp any host 169.65.41.100 eq smtp Firewall(config)# access-list acl_outside permit tcp any host 169.65.41.100 eq www Firewall(config)# access-group acl_outside in interface outside

TIP

Notice that the order of the two addresses is reversed from the order of the two interfaces, implying that the IP addresses should be different. If an inside host has an IP address that can appear on the outside without being translated, you can enter real_ip and mapped_ip as the same address.

However, you should do that only if you intend to permit inbound connections to that address. A static NAT defined with identical addresses creates an xlate entry that can allow hosts on the outside to access the inside host.

If no address translation is needed, a better solution is to use identity NAT (the nat 0 command) or NAT exemption (the nat 0 access-list command).

If inbound connections are not needed, you should define an identity NAT. Xlate entries are created only when connections are initiated from the inside, offering a more secure solution. If inbound and outbound connections should be allowed to initiate, NAT exemption is the better choice.

You can also configure a static NAT entry based on the mapped (global) firewall interface, even if you don't know its address ahead of time. In that case, you can use the interface keyword to translate the address pulled from a DHCP server. For example, the following command translates the outside interface address to the inside host address 192.168.100.100. No matter what IP address the outside interface has, the translation takes place with the correct value:

Firewall(config)# static (inside,outside) interface 192.168.100.100 netmask 255.255.255.255

Policy NAT

You can use policy NAT when real addresses need to be translated to several different mapped addresses, depending on a policy decision. An access list is used to trigger the address translation only when a match is permitted. Policy NAT can be configured in two ways:

• As a conditional static command, where inside real addresses are translated to predictable mapped addresses, depending on the outcome of an access list. This form of translation can be used if inbound connections are expected and permitted to the inside hosts.

• As a conditional nat command, where inside real addresses are translated to different mapped addresses defined in global commands, depending on the outcome of an access list. Use this form if the inside hosts are expected to initiate only outbound connections; inbound connections to those hosts are not allowed.

Follow these steps to configure a policy NAT:

Identity NAT

Identity NAT can be used when the real host and the mapped address are identical. In other words, the same IP subnet appears on both sides of the firewall. This is useful if you have registered IP addresses on the inside and there is no need to translate them on the outside.

You can use the following command to configure an identity NAT:

Notice that the nat_id here is always 0. This is a special case of the translation policy, one that doesn't require a corresponding global command.

Recall that the static command can also set up an identity NAT, where the real address appears unchanged on the mapped side. In other words, no real NAT takes place.

What is the difference between using static and using nat 0 if both prevent NAT from occurring? When the static command defines an identity NAT, connections involving the real address can be initiated in both directions through the firewall (assuming that the connections are permitted by access lists).

After the static command is entered, the firewall creates static xlate entries when the real hosts attempt outbound connections that are permitted through the firewall. Likewise, it is also possible for outside hosts to reach the real hosts in the inbound direction, because the xlate entries are still created.

If you define the same real host with a nat 0 command, that host can initiate only outbound connections. No inbound connections are allowed. Therefore, the nat 0 command sets up a one-way path without translating the real address.

As a last note, you should avoid configuring both static and nat 0 commands for the same real addresses. It might seem logical to define both to prevent NAT from occurring, but the two methods are really mutually exclusive.

For example, consider two hosts that reside on the inside of a firewall. The inside network uses a publicly registered IP subnet of 128.163.89.0/24. For this reason, no address translation is necessary, because the inside hosts can appear on the outside with publicly routable addresses.

An identity NAT can be used in this case. For example, Host A at 128.163.89.199 on the inside also appears as 128.163.89.199 on the outside. In fact, the whole subnet is defined in a similar manner. Figure 6-5 shows a network diagram for this scenario.

If both outbound and inbound connections should be possible, you should consider using the nat 0 access-list command to define a NAT exemption. This is discussed fully in the next section. The NAT exemption entries for the whole subnet could be configured as follows:

Firewall(config)# access-list ExemptList permit ip 128.163.89.0 255.255.255.0 any Firewall(config)# nat (outside) 0 access-list ExemptList

You should also configure the appropriate access lists to permit the inbound and outbound connections for this subnet.

NOTE

PIX 6.x platforms create xlate entries for each individual host contained in the identity NAT subnet. For large subnets, the number of static xlate entries can grow quite large. Beginning with PIX 7.0, the firewall builds a single xlate entry representing an entire subnet.

To configure the identity NAT for outbound use only, you could use the following command:

Firewall(config)# nat (inside) 0 128.163.89.0 255.255.255.0

The subnet mask, given as 255.255.255.0, defines the extent of the addresses that have identity translation entries. It also allows the firewall to prevent translations from being built for the network (128.163.89.0) and broadcast (128.163.89.255) addresses.

NAT Exemption

Sometimes you might have specific real (local) IP addresses that need to bypass NAT and appear untranslated. This might be needed only for individual IP addresses or for unique traffic flows. NAT exemption is similar to an identity NAT, where the real and mapped IP addresses are identical. However, NAT exemption uses an access list to define a policy for bypassing translation.

Unlike identity NAT, which allows connections to be initiated only in the outbound direction, NAT exemption allows connections to be initiated in either the inbound or outbound direction.

NAT exemption is most often used in conjunction with VPN connections. Inside addresses might normally be translated for all outbound connections through a firewall. If a remote network can be reached through a VPN tunnel, the inside hosts might need to reach remote VPN hosts without being translated. NAT exemption provides the policy mechanism to conditionally prevent the address translation.

Follow these steps to configure NAT exemption:

Dynamic Address Translation (NAT or PAT)

Dynamic address translation can be used to allow hosts with real addresses to share or "hide behind" one or more common mapped addresses. Address translation occurs on a many-to-one basis in a dynamic fashion. This can be accomplished in two ways:

• Dynamic NAT Inside host addresses are translated to values pulled from a pool of mapped addresses. Each inside address gets exclusive use of the mapped address it is assigned for the duration of any active connections. As soon as all of a host's connections are closed, that mapped address is returned to the pool.

  This means that all inside hosts must compete for the use of the mapped addresses. If the mapped address pool is too small, some hosts could be denied because their translations could not be set up.

• Dynamic PAT Inside host addresses are translated to a single mapped address. This is possible because the inside port numbers can be translated to a dynamically assigned port number used with the mapped address.

  Because port numbers are used as part of the translation, each dynamic PAT entry can support only a single connection (protocol and port number) from a single inside host. In other words, if one inside host initiates two outbound connections, two PAT entries are createdeach using a unique port number with the mapped address.

  When a connection is closed, its dynamic PAT entry is deleted after 30 seconds. The mapped port number becomes available for use again.

  Each mapped address has the potential to provide up to 65,535 dynamic PAT entries for a single IP protocol (UDP or TCP, for example), because that many unique port numbers are available. Additional mapped addresses can be used, adding 65,535 more port numbers to the pool. As soon as the port numbers from one mapped address have been exhausted, the next configured mapped address is used.

Figure 6-6 illustrates dynamic NAT, where Host A initiates a connection to Host B. Notice that the real-ip is translated to mapped-ip-n, which is one of a possible pool of mapped addresses. The real-port is not translated, however, because it is still unique to the mapped address. For return traffic, the firewall must translate the destination address back to the original real-ip.

Figure 6-7 illustrates dynamic PAT. Notice that the procedure is almost identical to that of dynamic NAT, shown in Figure 6-6. The difference is that a dynamic mapped-port value is used rather than a dynamic mapped-ip. The combination of mapped IP and port numbers keeps the connection unique so that it can be translated back to the real address and port for return traffic.

For dynamic translation (either NAT or PAT), you configure the mapped addresses that can be used, along with the translation policy that triggers the translation.

Mapped addresses are defined in groups, where nat_id (1 to 2,147,483,647) is a group index that corresponds to a matching translation policy. You can repeat the following global commands with the same nat_id to define more mapped addresses to use for the translation policy.

Dynamic NAT and PAT Example

A firewall connects to the outside network using IP address 169.54.122.1 255.255.255.128. The rest of that subnet is available for the firewall to use as dynamic NAT and/or PAT addresses. Several different IP subnets are on the inside of the firewall: 172.16.0.0/16, 172.17.0.0/16, and various others. (The firewall must have route commands defined or dynamic routing information to reach these inside networks, because they are not directly connected to it. Those commands are not shown here.)

Several different NAT and PAT definitions are needed in this scenario, as shown in Figure 6-8. Hosts on the inside network 172.16.0.0 255.255.0.0 are allowed to make outbound connections and are translated using the global address pool 169.54.122.10 through 169.54.122.60. As long as these addresses are available, they are assigned as dynamic NAT. If all the addresses in the pool are in use, the next translation uses global address 169.54.122.61 for dynamic PAT. These are configured as nat/global group ID 1.

A similar translation arrangement is needed for inside network 172.17.0.0 255.255.0.0. These use global pool 169.54.122.65 through 169.54.122.125 for NAT and global address 169.54.122.126 for PAT. These are configured as nat/global group ID 2.

For other inside networks, a default translation arrangement uses the firewall's outside interface address for dynamic PAT. The nat/global group ID 3 performs this function.

One other exception must be made to the address translation mechanism: When inside host 172.16.1.41 opens outbound connections to the 192.168.200.0/24 network, its address should not be translated. This is configured using nat group 0, as a NAT exemption identified by access list acl_no_nat.

Finally, an access list is applied to the inside interface, controlling the outbound traffic. By default, the firewall allows outbound traffic from that interface even if no access list exists. The decision is made to use an access list, only to prevent hosts on the inside from spoofing source IP addresses that are different from the inside subnets. Access list acl_inside is used for this purpose.

TIP

You can also use the ip verify reverse-path interface inside command to enable reverse-path forwarding lookups. This feature verifies that each packet's source address did indeed come from a subnet that the firewall expects to be located on the source interface. In effect, spoofed addresses are detected. This command is covered in more detail in Chapter 3, "Building Connectivity."

You can configure the firewall for this scenario with the following commands:

Firewall(config)# global (outside) 1 169.54.122.10-169.54.122.60 netmask 255.255.255.128 Firewall(config)# global (outside) 1 169.54.122.61 Firewall(config)# nat (inside) 1 172.16.0.0 255.255.0.0 0 0 Firewall(config)# global (outside) 2 169.54.122.65-169.54.122.125 netmask 255.255.255.128 Firewall(config)# global (outside) 2 169.54.122.126 Firewall(config)# nat (inside) 2 172.17.0.0 255.255.0.0 0 0 Firewall(config)# global (outside) 3 interface Firewall(config)# nat (inside) 3 access-list nat_0 0 0 0 Firewall(config)# access-list acl_no_nat permit ip host 172.16.1.41 192.168.200.0 255.255.255.0 Firewall(config)# nat (inside) 0 access-list acl_no_nat Firewall(config)# access-list acl_inside permit ip 172.16.0.0 255.240.0.0 any Firewall(config)# access-list acl_inside permit ip 192.168.69.0 255.255.255.0 any Firewall(config)# access-list acl_inside deny ip any any Firewall(config)# access-group acl_inside in interface inside

Controlling Traffic

A host on one firewall interface is allowed to create any type of connection to a host on a different firewall interface as long as an address translation can be made (if required) and any relevant interface access lists permit it.

After address translation methods have been configured between pairs of firewall interfaces, you must also configure and apply access lists to the appropriate interfaces.

You can configure and use an access list to limit the types of traffic in a specific direction. When the ACL permits traffic, connections are allowed to pass; when it denies traffic, those packets are dropped at the firewall.

In addition, when an xlate entry is created for a new connection and the interface access lists permit the initial traffic, the return traffic specific to that connection is also permittedonly because the firewall has built the proper xlate and conn entries for it.

You can use the following sequence of steps to configure an access list:

Controlling Access with Medium-Security Interfaces

So far, inbound and outbound access have been discussed in relation to two firewall interfacesthe inside and the outside. If your firewall has other "medium-security" interfaces (security levels between 0 and 100), there are some additional considerations. These interfaces are usually used as demilitarized zone (DMZ) networks, where services are made available to the public networks while offering a certain level of security. DMZ networks are then isolated from the highest-security inside networks, although their services can be accessed from the inside.

Outbound access from a medium-security interface to a lower one is really no different from the inside interface. You still need to configure the following:

• Address translation with the static command or with the global and nat commands. This allows hosts on the DMZ to appear on the outside with a valid address.

• An access list applied to the medium-security interface. This allows hosts on the DMZ to be permitted to initiate inbound connections toward the inside interface. The same access list also controls outbound connections from the DMZ.

Figure 6-9 shows how outbound access can be configured on a firewall with three interfaces. Basically, you need to consider each interface separately and decide which other lower-security interfaces will be involved in the outbound connections. For those interface pairs, configure address translation (if required) and make sure that any interface access lists allow the outbound connections.

You should also consider inbound connections, made from a lower-security interface toward a higher-security DMZ interface. This could include connections from the outside interface toward a DMZ interface, or from a DMZ toward the inside interface.

Inbound access into a medium-security interface is really no different from access into the inside interface. You still need to configure address translation (if required) so that hosts on the higher-security interface appear as a mapped address on the lower-security interface.

An access list should also be applied to the interface with the lowest security level of the connection. For example, if an outside host is allowed to connect to a DMZ host, an ACL applied to the outside interface must permit the inbound connection.

Similarly, if a DMZ host is allowed to connect to an inside host, an ACL must be applied to the DMZ interface that permits the inbound connection. The ACL must be applied to the interface closest to the source of inbound connections.

Figure 6-10 shows how inbound access can be configured on a firewall with three interfaces. Basically, you need to consider each interface separately and decide which other higher-security interfaces will accept inbound connections from it. For those interface pairs, configure address translation (if required) and make sure that any interface access lists allow only specific inbound connections.

An access list must be applied to each lower-security interface so that specific inbound connections are permitted. This sounds straightforward, but there are some interesting implications to consider.

In Figure 6-10, for example, the outside interface can accept inbound connections that are destined for the dmz network, as well as for the inside network. Therefore, the access list applied to the outside interface should be configured to permit the necessary connections to the global addresses of the DMZ hosts as well as the inside hosts.

Now consider the dmz interface. Hosts on the dmz network might initiate inbound connections to the inside interface. Therefore, the access list applied to the dmz interface should be configured to permit inbound traffic to the global addresses of the inside hosts.

Suppose DMZ hosts are also allowed to initiate outbound connections toward the outside network. The access list applied to the dmz interface must also be configured to permit these outbound connections, in addition to any inbound traffic toward the inside. It is easy to forget that access lists applied to medium-security interfaces should permit traffic destined for several locations.