Section 6-2. Routed Firewall Mode and Address Translation

team bbl


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.

Table 6-1. Address Translation Types Supported by Cisco Firewalls

Translation Type

Application

Basic Command

Direction in Which Connections Can Be Initiated

Static NAT

Real source addresses (and ports) are translated to mapped addresses (and ports)

static

Inbound or outbound

Policy NAT

Conditionally translates real source addresses (and ports) to mapped addresses

static access-list

Inbound or outbound

Identity NAT

No translation of real source addresses

nat 0

Outbound only

NAT exemption

No translation of real source addresses matched by the access list

nat 0 access-list

Inbound or outbound

Dynamic NAT

Translates real source addresses to a pool of mapped addresses

nat id

global id address-range

Outbound only

PAT

Translates real source addresses to a single mapped address with dynamic port numbers

nat id

global id address

Outbound only


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:

FWSM 2.x

... [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

PIX 6.x

... [norandomseq] [max_conns [emb_limit]]

PIX 7.x

... [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]


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:

FWSM 2.x

Firewall(config)# timeout [conn hh:mm:ss] [udp hh:mm:ss]

PIX 6.x

Firewall(config)# timeout [conn hh:mm:ss] [udp hh:mm:ss]

PIX 7.x

Firewall(config)# timeout [conn hh:mm:ss] [udp hh:mm:ss]


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.

Figure 6-2. Static NAT Operation Across a Firewall


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

FWSM 2.x

Firewall(config)# static (real_ifc,mapped_ifc) {mapped_ip | interface} {real_ip [netmask mask]} [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# static (real_ifc,mapped_ifc) {mapped_ip | interface} {real_ip [netmask mask]} [dns] [norandomseq] [max_conns [emb_limit]]

PIX 7.x

Firewall(config)# static (real_ifc,mapped_ifc) {mapped_ip | interface} {real_ip [netmask mask]} [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]


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:

FWSM 2.x

Firewall(config)# static (real_ifc,mapped_ifc) {tcp | udp} {mapped_ip | interface} mapped_port {real_ip real_port [netmask mask]} [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# static (real_ifc,mapped_ifc) {tcp | udp} {mapped_ip | interface} mapped_port {real_ip real_port [netmask mask]} [dns] [norandomseq] [max_conns [emb_limit]]

PIX 7.x

Firewall(config)# static (real_ifc,mapped_ifc) {tcp | udp} {mapped_ip | interface} mapped_port {real_ip real_port [netmask mask]} [dns] [norandomseq] [tcp max_conns [emb_limit]] [udp udp_max_conns]


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.

Figure 6-3. Network Diagram for the Static NAT Example


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:

1.

Identify the translation policy:

 Firewall(config)# access-list acl_name permit ip real_ip real_mask   foreign_ip foreign_mask 

An access list named acl_name is used to identify traffic by source (real_ip real_mask) and destination (foreign_ip foreign_mask). When an outbound packet triggers the permit statement, a matching policy NAT static or nat command also is triggered. The real_ip address given here is the address that ultimately is translated. You can substitute the host real_ip keyword pair if the source is a single host.

You use foreign_ip and foreign_mask to define a destination host or a whole subnet on the public network. You can also substitute the host foreign_ip keyword pair if the destination is a single host.

You can repeat this access-list command to define other source/destination combinations that trigger a matching static command.

2.

(static only) Define the static command translation:

FWSM 2.x

Firewall(config)# static (real_ifc,mapped_ifc) mapped_ip access-list acl_name [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# static (real_ifc,mapped_ifc) mapped_ip access-list acl_name [dns] [norandomseq] [max_conns [emb_limit]]

PIX 7.x

Firewall(config)# static (real_ifc,mapped_ifc) mapped_ip access-list acl_name [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]


A conditional static NAT or policy NAT translation is defined across the firewall interfaces named real_ifc and mapped_ifc. Here, the mapped_ip address replaces the real_ip address matched in the access list named acl_name.

You can repeat this command to define multiple NAT policies. Each static command should reference a different access list.

3.

(nat only) Define the nat command translation.

a. Configure a global address:

FWSM 2.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip [-global_ip] [netmask global_mask]} | interface

PIX 6.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip [-global_ip] [netmask global_mask]} | interface

PIX 7.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip [-global_ip] [netmask global_mask]} | interface


Global IP addresses are used as mapped or translated addresses. They are defined as a single address (global_ip) or a range of addresses (global_ip-global_ip). The global definition must be identified with a NAT ID nat_id (1 to 2,147,483,647), which is linked to nat commands with the same value.

The destination or mapped interface is given as mapped_ifc (outside, for example), complete with surrounding parentheses. Therefore, NAT occurs for traffic that matches a policy and also exits this interface.

You can specify a subnet mask as global_mask so that the firewall automatically excludes the network and broadcast addresses from the range of global addresses given. You can also use the interface keyword to use the mapped interface's IP address as the global address. In this case, the translation is performed using PAT, because many real IP addresses could become translated to the single interface address.

b. Configure a NAT translation:

FWSM 2.x

Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside] [[tcp] max_conns [emb_limit]] [norandomseq] [udp udp_max_conns]

PIX 6.x

Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside][norandomseq] [max_conns [emb_limit]]

PIX 7.x

Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside] [[tcp] max_conns [emb_limit]] [norandomseq] [udp udp_max_conns]


Define the NAT translation to occur at the local or real interface named real_ifc (inside, for example). The address translation uses mapped addresses defined in global commands using the same NAT ID nat_id as given here.

The translation occurs only if the extended access list acl_name matches a permit statement. You can match against source and destination addresses and port numbers.

For example, suppose two hosts reside on the inside of a firewall, using private IP addresses 192.168.100.100 and 192.168.100.170. Outbound connections from Host A should appear as different global addresses, depending on the connection's destination. The inside network interfaces with several different external business partners, each expecting Host A to reside in a different address space. This is a good application for policy NAT, also called conditional NAT.

If Host A opens a connection to the 10.10.0.0/16 network, it should appear as global address 192.168.254.10. If Host A opens a connection to the 10.50.0.0/16 network, it should appear as 192.168.254.50. Last, if Host A opens a connection to any other destination, it should appear as global address 192.168.254.100. Figure 6-4 shows a network diagram for this scenario.

Figure 6-4. Network Diagram for the Policy NAT Example


First, policy NAT using static commands are considered. The policy NAT entries could be configured with the following commands:

 Firewall(config)# access-list hostApolicy10 permit ip host   192.168.100.100 10.10.0.0 255.255.0.0 Firewall(config)# static (inside,outside) 192.168.254.10 access-list   hostApolicy10 0 0 Firewall(config)# access-list hostApolicy50 permit ip host   192.168.100.100 10.50.0.0 255.255.0.0 Firewall(config)# static (inside,outside) 192.168.254.50 access-list   hostApolicy50 0 0 Firewall(config)# static (inside,outside) 192.168.254.100   192.168.100.100 netmask 255.255.255.255 0 0 

If ACL hostApolicy10 matches and permits traffic, Host A is translated to 192.168.254.10. If ACL hostApolicy50 matches and permits traffic, Host A is translated to 192.168.254.50.

You might be inclined to define a third policy access list that denies the other two conditions and then permits everything else. However, policy NAT does not accept an access list that contains deny statements; the idea is to permit the traffic where you need a translation. Instead, you can use a regular static NAT (without an access list) to define the third condition. Now the inside address 192.168.100.100 has been defined in three different address translation commands. This works because the more-specific static translations (policy NAT) are evaluated first, followed by regular static NAT.

Finally, policy NAT with nat commands is used. You could use the following configuration commands:

 Firewall(config)# access-list hostApolicy10 permit ip host   192.168.100.100 10.10.0.0 255.255.0.0 Firewall(config)# global (outside) 1 192.168.254.10  255.255.255.255 Firewall(config)# nat (inside) 1 access-list hostApolicy10 Firewall(config)# access-list hostApolicy50 permit ip host   192.168.100.100 10.50.0.0 255.255.0.0 Firewall(config)# global (outside) 2 192.168.254.50 255.255.255.255 Firewall(config)# nat (inside) 2 access-list hostApolicy50 Firewall(config)# access-list hostApolicy100 permit ip host   192.168.100.100 any Firewall(config)# global (outside) 3 192.168.254.100 255.255.255.255 Firewall(config)# nat (inside) 3 access-list hostApolicy100 

Traffic passing from host 192.168.100.100 to the 10.10.0.0/16 subnet, for example, matches the permit statement in access list hostApolicy10, which triggers the nat command with ID 1. This causes the inside host address to be translated to the address defined in global ID 1, 192.168.254.10.

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:

FWSM 2.x

Firewall(config)# nat (real_ifc) 0 real_ip real_mask [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# nat (real_ifc) 0 real_ip real_mask [dns] [norandomseq] [max_conns [emb_limit]]

PIX 7.x

Firewall(config)# nat (real_ifc) 0 real_ip real_mask [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]


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.

Figure 6-5. Network Diagram for the Static Identity NAT Example


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:

1.

Define the policy with an access list:

FWSM 2.x

Firewall(config)# access-list acl_name [extended] permit ip local_ip local_mask foreign_ip foreign_mask

PIX 6.x

Firewall(config)# access-list acl_name permit ip local_ip local_mask foreign_ip foreign_mask

PIX 7.x

Firewall(config)# access-list acl_name [extended] permit ip local_ip local_mask foreign_ip foreign_mask


Local addresses that are permitted by an entry in the access list are exempted from translation. Normally, you should configure permit statements only as a part of the NAT exemption access list. (Although deny statements are allowed, you would really be defining conditions to deny when NAT should be denied!)

In addition, only the ip protocol is allowed in the access list. NAT exemption is evaluated based on source and destination addresses, not on IP protocols or port numbers.

2.

Add the access list to the policy:

FWSM 2.x

Firewall(config)# nat (real_ifc) 0 access-list acl_name [dns] [outside] [[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# nat (real_ifc) 0 access-list acl_name [dns] [outside] [max_conns [emb_limit] [norandomseq]]

PIX 7.x

Firewall(config)# nat (real_ifc) 0 access-list acl_name [dns] [outside] [[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]


Packets permitted by the access list named acl_name are exempted from translation. In other words, those packets are passed on out a different firewall interface with the original real address unchanged.

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.

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, a firewall is configured to use PAT on all outbound traffic. However, inside addresses in the 192.168.1.0/24 subnet should not be translated when connections are initiated to the 192.168.77.0/24 and 192.168.100.0/24 subnets. The following commands can be used to configure both PAT and NAT exemption:

 Firewall(config)# nat (inside) 1 0 0 Firewall(config)# global (outside) 1 interface Firewall(config)# access-list exempt1 permit ip 192.168.1.0 255.255.255.0   192.168.77.0 255.255.255.0 Firewall(config)# access-list exempt1 permit ip 192.168.1.0 255.255.255.0   192.168.100.0 255.255.255.0 Firewall(config)# nat (inside) 0 access-list exempt1 

Although two different address translation methods are configured, there is no conflict between them regarding the translation of 192.168.1.0/24 hosts. This is because of the order in which NAT operations are performed. NAT exemption is always evaluated before any other translation type.

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-6. Dynamic NAT Operation Across a Firewall


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.

Figure 6-7. Dynamic PAT Operation Across a Firewall


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.

1.

Define mapped addresses for NAT:

FWSM 2.x

Firewall(config)# global (mapped_ifc) nat_id global_ip[-global_ip] [netmask global_mask]

PIX 6.x

Firewall(config)# global (mapped_ifc) nat_id global_ip[-global_ip] [netmask global_mask]

PIX 7.x

Firewall(config)# global (mapped_ifc) nat_id global_ip[-global_ip] [netmask global_mask]


You can use mapped addresses that are located on the firewall interface named mapped_ifc (outside, for example) for address translation. You can define a single global_ip address or a range of addresses as the starting and ending addresses global_ip-global_ip. A subnet mask can be given with the netmask keyword, where global_mask matches the mask in use on the global IP subnet. If the mask is given, it is used to determine and reserve the network and broadcast addresses so that they aren't used for translation.

For example, the following command can be used to configure 10.1.2.1 through 10.1.2.254 as global (mapped) addresses on the outside interface for NAT ID 1. These addresses are used for translation triggered by the corresponding NAT policy for NAT ID 1, with the nat 1 command.

 Firewall(config)# global (outside) 1 10.1.2.1-10.1.2.254 netmask  255.255.255.0 

TIP

The global addresses can be located on the IP subnet assigned to the firewall interface, although this isn't required. You can also use other addresses, as long as devices on the outside network can route those addresses back to the firewall interface.

2.

Define one or more mapped addresses for PAT:

FWSM 2.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip | interface}

PIX 6.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip | interface}

PIX 7.x

Firewall(config)# global (mapped_ifc) nat_id {global_ip | interface}


You can also specify single mapped addresses for PAT, where many real addresses are translated to or "hide behind" a single mapped address. To do this, use the global command with a single global_ip address. You can repeat the command to define other single mapped addresses to use for PAT. As soon as one mapped address is exhausted of its port numbers, the next mapped PAT address is used.

For example, the following commands set aside three mapped addresses for dynamic PAT usage in NAT group 2:

 Firewall(config)# global (outside) 2 130.65.77.24 Firewall(config)# global (outside) 2 130.65.77.25 Firewall(config)# global (outside) 2 130.65.77.26 

You can also use the interface keyword to use the IP address of the interface itself as a PAT address. This is handy when the firewall requests a dynamic IP address from a service provider and the address is not known ahead of time. The following command shows an example, where the outside interface address is added to the list of mapped PAT addresses in NAT group 2:

 Firewall(config)# global (outside) 2 interface 

NOTE

If a range of mapped addresses is defined, the firewall uses these addresses first to create new address translations. These are used only for dynamic NAT, where a single local address is translated to a single mapped address. After the connections belonging to a translation close or time out, that mapped address is released back into the pool of available addresses.

If all the dynamic NAT mapped addresses are in use, the firewall begins creating translations based on any single dynamic PAT mapped addresses that are defined.

3.

Define a translation policy.

Outbound address translation occurs when a packet is sent from a real interface that has a nat policy to a mapped interface that has a global definition. The nat and global definitions must match by having the same nat_id index.

In the translation policy nat commands, the real firewall interface is named real_ifc. Don't forget the parentheses, as in (inside).

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 translated or mapped address.

The following command syntax defines a translation policy:

FWSM 2.x

Firewall(config)# nat (real_ifc) nat_id real_ip [mask [dns] [outside][[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# nat (real_ifc) nat_id real_ip [mask [dns] [outside] [[norandomseq] [max_conns [emb_limit]]]

PIX 7.x

Firewall(config)# nat (real_ifc) nat_id real_ip [mask [dns] [outside][[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]


The real address is defined as real_ip, which can be a single IP address or a subnet address with a subnet mask.

For example, the following command can be used to trigger dynamic NAT or PAT when inside addresses in the 192.168.100.0/24 subnet initiate outbound connections. This NAT policy uses NAT ID 1; the corresponding global command must also use NAT ID 1.

 Firewall(config)# nat (inside) 1 192.168.100.0 255.255.255.0 

You can also use an access list to trigger the dynamic NAT or PAT translation. This allows the translation to be conditional as well as dynamic. First, define an access list with the following command:

FWSM 2.x

Firewall(config)# access-list acl_name permit protocol real_ip real_mask [operator port] foreign_ip foreign_mask [operator port]

PIX 6.x

Firewall(config)# access-list acl_name permit protocol real_ip real_mask [operator port] foreign_ip foreign_mask [operator port]

PIX 7.x

Firewall(config)# access-list acl_name [extend] permit protocol real_ip real_mask [operator port] foreign_ip foreign_mask [operator port]


The real source addresses are candidates for dynamic NAT or PAT if they are matched by a permit statement in the access list. You can use permit statements only when you configure the access list.

However, you can be specific in the access list by specifying an IP protocol (tcp or udp, for example), source and destination operators (eq, for example), and port numbers. These values aren't used in the actual dynamic NAT or PAT operation; they are used only to define the traffic that triggers the translation.

As soon as the access list is configured, add it to the translation policy with the following command syntax:

FWSM 2.x

Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside][[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]

PIX 6.x

Firewall(config)# nat [(local_interface)] nat_id access-list acl_name [dns] [norandomseq] [max_conns [emb_limit]]]

PIX 7.x

Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside][[tcp] max_conns [emb_limit] [norandomseq]] [udp udp_max_conns]


The translation policy uses the access list named acl_name to identify packets to be translated. For example, the following commands cause dynamic translation with NAT ID 1 to be used when inside hosts in 192.168.1.0/24 initiate connections to the 10.1.0.0/16 network, as matched by access list FlowA. When the same inside hosts initiate connections to the 10.2.0.0/16 network, matched by access list FlowB, NAT ID 2 is used.

 Firewall(config)# access-list FlowA permit ip 192.168.1.0 255.255.255.0   10.1.0.0 255.255.0.0 Firewall(config)# access-list FlowB permit ip 192.168.1.0 255.255.255.0   10.2.0.0 255.255.0.0 Firewall(config)# global (outside) 1 interface Firewall(config)# global (outside) 2 interface Firewall(config)# nat (inside) 1 access-list FlowA Firewall(config)# nat (inside) 2 access-list FlowB 

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.

Figure 6-8. Network Diagram for the Dynamic NAT and PAT Example


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:

1.

Use an access list to permit allowed traffic:

FWSM 2.x

[View full width]

 Firewall(config)# access-list acl_id [extended]  {permit | deny}    {protocol | object-group protocol_obj_group}    {source_addr  source_mask | object-group  network_obj_group}    [operator sport | object-group service_obj_group]    {destination_addr destination_mask | object-group    network_obj_group}    [operator dport | object-group service_obj_group]    [log [[disable | default] | [level]]] [interval  secs]] 

PIX 6.x

[View full width]

 Firewall(config)# access-list acl_id [line  line-num] {permit | deny}    {protocol | object-group protocol_obj_group}    {source_addr  source_mask | object-group  network_obj_group}    [operator sport | object-group service_obj_group]    {destination_addr destination_mask |  object-group network_obj_group}    [operator dport | object-group service_obj_group]    [log [[disable | default] | [level]]] [interval  secs]] 

PIX 7.x

[View full width]

 Firewall(config)# access-list acl_id [line  line-num] [extended] {permit | deny}    {protocol | object-group protocol_obj_group}    {source_addr  source_mask | object-group  network_obj_group}    [operator sport | object-group service_obj_group]    {destination_addr destination_mask |  object-group network_obj_group}    [operator dport | object-group service_obj_group]    [log [[disable | default] | [level]]] [interval  secs]]    [time-range name] [inactive] 


Be aware that any source and destination addresses you specify are relative to any address translation that occurs on the interface where the access list is applied.

For example, suppose inside address 192.168.1.1 is translated to outside address 204.152.16.1. If the access list will be applied to the outside interface to permit inbound connections, you should use destination address 204.152.16.1, because the host is known by that address on the outside.

Likewise, if the access list will be applied to the inside interface to limit outbound traffic, you should use source address 192.168.1.1.

To configure the access list named acl_id, refer to section 6-3, which covers ACLs in much greater detail.

If you will be creating several access lists, you might consider assigning them meaningful names. For example, an ACL that will control access on the outside interface could be named acl_outside. Although it isn't necessary to begin the name with acl_, doing so provides a handy clue that an ACL is being referenced when you look through a large firewall configuration.

2.

Apply the access list to a firewall interface:

FWSM 2.x

Firewall(config)# access-group acl_id {in | out} interface interface_name [per-user-override]

PIX 6.x

Firewall(config)# access-group acl_id in interface interface_name [per-user-override]

PIX 7.x

Firewall(config)# access-group acl_id {in | out} interface interface_name [per-user-override]


The access list named acl_id is applied to the interface named interface_name (inside, for example). The access list evaluates or filters traffic only in the direction specified: in (traffic arriving on the interface) or out (traffic leaving the interface).

If you use downloadable access lists from a RADIUS server, you can add the per-user-override keyword. This allows any downloaded ACLs to override the ACL applied to the interface. In other words, the per-user downloaded ACLs are evaluated first, before the interface ACL.

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.

Figure 6-9. Outbound Access on a Firewall with Three Interfaces


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.

Figure 6-10. Inbound Access on a Firewall with Three Interfaces


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.

    team bbl



    Cisco ASA and PIX Firewall Handbook
    CCNP BCMSN Exam Certification Guide (3rd Edition)
    ISBN: 1587051583
    EAN: 2147483647
    Year: 2003
    Pages: 120
    Authors: David Hucaby

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net