Chapter 7: Using Address Translation

..... update soon ....

---------------------------------------------------------------------------------------------------------------------

6-2: Address Translation

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 must still occur.

  One exception to this 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 ASA 7.0 and FWSM 3.1(1), which allows hosts to initiate connections through the firewall without requiring address translation.

• Access control— After 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 for the routed firewall mode, as relationships between inside and outside IP addresses are built as needed.

Tip

Address translation is inherent when a firewall is configured for routed mode. Beginning with ASA 8.0, address translation can be used in transparent mode as well.

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.

Tip

By default, all firewall interfaces must be assigned a unique security level value, causing some interfaces to have more security while others have less. Beginning with ASA 7.2(1) and FWSM 2.2(1), you can use the same-security-traffic permit inter-interface to configure a firewall such that its interfaces have the same relative level of security. This command is discussed in the “Same-Security Access” section in this chapter.

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 only builds outbound connections that meet security policy requirements configured as an access list. (ASA and 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

ASA 7.0 and FWSM 2.2(1) introduced the capability to configure multiple interfaces with the same level of security. In this case, it is not easy to classify the traffic passing between same-security interfaces as inbound or outbound.

Why would you ever 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 that 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 will not be able to assign more than 100 unique security levels. Some of the interfaces will 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. To enable traffic to pass between interfaces that have the same security level, use the following global configuration command:

Firewall(config)# same-security-traffic permit inter-interface

Sometimes you might want to allow traffic to enter and exit the same firewall interface. This can be handy for VPN peers that have tunnels built to the firewall, but need traffic to pass back out to other VPN peers or other networks connected to the same interface.

Firewalls do not normally allow traffic to “hairpin” or come back out the same interface. Beginning with ASA 7.2(1) and FWSM 2.3(1), you can use the following global configuration command to permit hairpin traffic:

Firewall(config)# same-security-traffic permit intra-interface

In this case, the interface itself is considered to have the same security level in both directions, hence the intra-interface keyword.

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 does not 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 can be displayed by the show xlate command. (This command is more fully explained in Chapter 11, Section “11-3: Verifying Firewall Connectivity.”) An xlate entry must exist before inbound connections will be 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. These are known as conn entries, shown by 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 Chapter 11, Section “11-3: Verifying Firewall Connectivity.”)

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
Open table as spreadsheet

Translation Type	Application	Basic Command	Direction 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 address (and port) to a mapped address	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 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 a 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.

Tip

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, while the inside destination address is translated in the inbound direction. The outside keyword reverses this—only the addresses on the lower security interface are subject to translation. This is often called Outside NAT or Bidirectional NAT. You can also configure a firewall to allow two or more firewall interfaces to have an equal security level. In this case, no higher or lower security boundary exists between the two interfaces. Therefore, address translation does not 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 sections that follow.

Tip

Be aware that the interface names, address, and port designations have changed in the firewall command syntax related to address translation. In legacy PIX 6.3 commands, the terms local and global are relative to inside and outside interfaces, respectively. Beginning with FWSM 2.2 and ASA 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 shown in this chapter, they can be used interchangeably with local and global.

Handling Connections Through an Address Translation

Once 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 attempt to open only the legitimate connections they need. But if one connection can be initiated, multitudes more might follow, especially if some malicious intent is involved. Fortunately, Cisco firewalls have the capability to 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:

ASA, FWSM

... [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 cause firewall resources and destination host resources to become exhausted.

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

You can also define separate UDP and TCP connection limits 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). The maximum number of UDP “connections” can be set 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 is using a conn table entry.

Tip

As soon as the connection limit is reached for a host, any subsequent connection attempt is dropped. However, any connections that have already been built are subject to a connection idle timeout. If the firewall does not see any data passing over a connection for a specified time period, that connection is automatically closed. Separate idle timers are maintained for UDP and TCP connections. You can display the idle timer thresholds with the show running-config timeout command, as in the following example. The TCP idle timer is shown as conn, while 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 global configuration command: 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 0:00:00 for an unlimited time. The UDP udp timer can be set from 00:01:00 (1 minute) to 1192:59:59, or 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 has a three-way handshake (SYN-SYN/ACK-ACK) that must be completed 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 completion. 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. None of the SYN packets used to initiate the connections are ever answered by the malicious user; rather, 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 only applies to inbound connections, where outside hosts are initiating 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 on 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, then 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, while the limit is reached or exceeded, the firewall begins to intercept each new SYN packet and answers 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.

The firewall keeps track of the initial SYN packets and the SYN/ACK replies it sends by keeping a table of SYN cookies, or unique identifiers. In this fashion, the firewall acts as a connection proxy, absorbing the effects of an excessive amount 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 (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 toward 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 hijack 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 the integrity of a message. The originating host computes a hash value over the whole TCP packet, including the original ISN, and includes this within 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 will result and the packet authentication will fail. You can use the norandomseq keyword to keep the local firewall from changing the ISN, so that only one firewall is randomizing 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, 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. As well, 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 is initiating 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:

ASA, FWSM	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.3	Firewall (config)# static (real_ifc,mapped_ifc) {mapped_ip | interface} {real_ip [netmask mask]} [dns] [norandomseq] [max_conns [emb_limit]]

Open table as spreadsheet

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:

ASA, FWSM	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.3	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]]

Open table as spreadsheet

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.

As an 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, while 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 only created 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 its address is not known ahead of time. In that case, you can use the interface keyword to translate the address it 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:

• 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.

• 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 only expected to initiate outbound connections; inbound connections to those hosts will not be allowed.

You can use the following 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 is also triggered. The real_ip address given here is the address that is ultimately 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:

   ASA, FWSM	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.3	Firewall(config)# static (real_ifc,mapped_ifc) mapped_ip access-list acl_name [dns] [norandomseq] [max_conns [emb_limit]]

   Open table as spreadsheet

   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.

   1. Configure a global address:

      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, and 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, as many real IP addresses could become translated to the single interface address.

   2. Configure a NAT translation:

      ASA, FWSM	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.3	Firewall(config)# nat (real_ifc) nat_id access-list acl_name [dns] [outside][norandomseq] [max_conns [emb_limit]]

      Open table as spreadsheet

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

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

      As an 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 destination of the connection. 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. Lastly, 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 is 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 will 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 you have no need to translate them on the outside.

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

ASA, FWSM	Firewall(config)# nat (real_ifc) 0 real_ip real_mask [dns] [norandomseq] [[tcp] max_conns [emb_limit]] [udp udp_max_conns]
PIX 6.3	Firewall(config)# nat (real_ifc) 0 real_ip real_mask [dns] [norandomseq] [max_conns [emb_limit]]

Open table as spreadsheet

Notice that the nat_id here is always zero. This is a special case of the translation policy, one that does not 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 is taking 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 the connections are permitted by access lists).

As soon as 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 will still be created.

If you define the same real host with a nat 0 command, that host can only initiate 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.

As an 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, as 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 will also appear as 128.163.89.199 on the outside. In fact, the whole subnet will be 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 “NAT Exemption.” 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.

Tip

Legacy PIX 6.3 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 ASA 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 is reachable 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.

You can use the following steps to configure NAT exemption:

1. Define the policy with an access list:

   ASA, FWSM	Firewall(config)# access-list acl_name [extended]permit ip local_ip local_mask foreign_ip foreign_mask
   PIX 6.3	Firewall(config)# access-list acl_name permit ip local_ip local_mask foreign_ip foreign_mask

   Open table as spreadsheet

   Local addresses that are permitted by an entry in the access list are exempted from translation. Normally, you should only configure permit statements 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:

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

   Open table as spreadsheet

   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 zero. This is a special case of the translation policy, one that does not 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.

   As an 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, no conflict exists between them regarding the translation of 192.168.1.0/24 hosts. This is because of the order that 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 created—each 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 will be used.

Figure 6-6 illustrates dynamic NAT, where Host A is initiating 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 PAT Operation Across a Firewall

Figure 6-7 illustrates dynamic PAT. Notice the procedure is almost identical to that of dynamic NAT 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 keep 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 will trigger 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 global commands that follow with the same nat_id to define more mapped addresses to use for the translation policy.

1. Define mapped addresses for NAT:

   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 are not used for translation.

   As an 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 will be 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 it is not 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:

   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
   

   Tip

   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. As soon as the connections belonging to a translation close or time out, that mapped address is released back into the pool of available addresses. If all of 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. Do not 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:

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

   Open table as spreadsheet

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

   As an 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:

   ASA, FWSM	Firewall(config)# access-list acl_name [extended] permit protocol real_ip real_mask [operator port] foreign_ip foreign_mask [operator port]
   PIX 6.3	Firewall(config)# access-list acl_name permit protocol real_ip real_mask [operator port] foreign_ip foreign_mask [operator port]

   Open table as spreadsheet

   The real source addresses will be candidates for dynamic NAT or PAT if they are matched by a permit statement in the access list. You can only use permit statements 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) and source and destination operators (eq, for example) and port numbers. These values are not used in the actual dynamic NAT or PAT operation; they are only used 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:

   ASA, FWSM	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.3	Firewall(config)# nat [(local_interface)] nat_id access-list acl_name [dns] [norandomseq] [max_conns [emb_limit]]]

   Open table as spreadsheet

   The access list named acl_name is used by the translation policy 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 will be translated using the global address pool 169.54.122.10 through 169.54.122.60. As long as these addresses are available, they will be assigned as dynamic NAT. If all of the addresses in the pool are in use, the next translation will use 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 at all. 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 will allow 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 than 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.

As soon as 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 permitted—only 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:

   ASA, FWSM

   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]

   PIX 6.3

   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]]

   Open table as spreadsheet

   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 will be translated to outside address 204.152.16.1. If the access list will be applied to the outside interface to permit inbound connections, then 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, you should refer to Section 6-3, “Controlling Access with Access Lists,” which covers ACLs in much greater detail.

   If you are 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 is not necessary to begin the name with acl_, that does provide 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:

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

   Open table as spreadsheet

   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 will be evaluated first, before the interface ACL.

Controlling Access with Medium Security Interfaces

So far, inbound and outbound access has been discussed in relation to two firewall interfaces—the inside and the outside. If your firewall has other “medium security” interfaces (security levels between 0 and 100), you face 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 than 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 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 than 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 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 some interesting implications must be considered.

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.