Alias

The PIX's alias feature is used to set up a mechanism whereby the destination IP addresses contained in packets going from one interface to another are NATed (translated). This is necessary in various situations, especially where an external DNS server is used to resolve the names for servers on the inside or DMZ networks, where an IP address is being illegally used in the private network behind the PIX, or where two enterprise networks are merged to form one network across a PIX Firewall. The alias command not only translates the destination IP addresses, but can also doctor the DNS responses passing through the PIX to comply with the translation taking place on the destination IP addresses.

The following sections discuss in detail how the alias feature works. PIX aliasing allows either of the following objectives to be achieved:

• NAT on the destination IP addresses

• "DNS doctoring" by the alias feature

NAT on the Destination IP Addresses

Normally PIX does NAT on the source IP addresses for packets going from the high security level to the low security level. However, the alias command allows NAT to occur on the destination IP addresses as well. This means that if a host on the inside network sends a packet to destination IP address A, PIX redirects that packet to destination address B after changing the destination IP address in the packet to B.

An example of using the alias command in this manner occurs when hosts located on the inside network use an external DNS server to resolve the name of a server sitting on the PIX Firewall's DMZ interface. The server is physically configured with an RFC 1918 address that is statically translated into a globally routable address on the PIX to allow access from the outside world. If a client on the private network tries to access the server and send a DNS request to the DNS server, the DNS server replies with the server's globally routable address, not its RFC 1918 address. The PIX is set up to do aliasing such that when the client on the internal network sends a packet to the globally routable IP address of the server on the DMZ, the PIX translates the destination IP address to that of the server's RFC 1918 address and forwards the packet to its DMZ interface. Another way to resolve this problem is to have separate internal and external DNS servers, but this is not always possible.

Figure 8-4 depicts how the alias feature can be used to deal with this scenario.

Figure 8-4 How the Alias Feature Does NAT on the Destination IP Addresses

Figure 8-4 How the Alias Feature Does NAT on the Destination IP Addresses

"DNS Doctoring" by the Alias Feature

The PIX's alias feature can also doctor or modify the responses, passing through the PIX Firewall, sent to a client by a DNS server. This is a very useful feature when an external DNS server is the only DNS server available to the clients sitting on the PIX's inside network.

An example of the use of this feature occurs when an RFC 1918 address server is on the PIX Firewall's inside interface. This server is accessible to the outside world via a static translation created on the PIX Firewall for the RFC 1918 address to a globally routable address. If a client tries to access this server using its name, the DNS server responds by sending back the server's globally routable address to the client. This is obviously not the desired result. Therefore, the PIX using the alias feature doctors the DNS response from the DNS server and changes the resolved address to the server's RFC 1918 address on the inside network. This way, the client can access the server using its private address. Of course, another way around this problem is to use external and internal DNS servers. However, that is not always an available option.

Figure 8-5 depicts how the alias feature can be used to deal with this scenario.

Figure 8-5 How the Alias Feature Does DNS Doctoring

Static (inside, outside) 150.1.1.1 10.10.1.1 netmask 255.255.255.255

Figure 8-5 How the Alias Feature Does DNS Doctoring

Static (inside, outside) 150.1.1.1 10.10.1.1 netmask 255.255.255.255

Another problem network administrators can run into is when they use an IP address (for one of their machines on the inside or a DMZ network) that is legally being used by a server somewhere on the Internet. This works fine as long as this machine's source address gets NATed to something else while going to the Internet. However, if one of the other machines on the private network tries to reach that Internet server using its name, the address returned by the DNS server is actually the address of the machine sitting on the local network with the duplicate address. Consequently, the machine trying to reach the Internet server sends the packet to the local machine instead of the Internet server. The alias command can be used to correct this behavior. The alias command allows the PIX Firewall the change (doctor) the address returned in the DNS response from the DNS server into a unique address not found on the local network. When the machine trying to reach the Internet server sends its packets to this new address, the PIX changes the destination address back to the Internet server's correct address and sends the packet on to the public Internet.

Figure 8-6 depicts how the alias feature deals with this scenario.

Figure 8-6 How the Alias Feature Circumvents Overlapping IP Addresses m c m c

Requesting Host Trims To Access Cisco Web Server 192.31.7.130 http://200.200.200.150

Figure 8-6 How the Alias Feature Circumvents Overlapping IP Addresses

Requesting Host Trims To Access Cisco Web Server 192.31.7.130 http://200.200.200.150

192.31.7.0 Network

arketing *

192.31.7.0 Network arketing *

Internal Web Server

Add Cisco Web Server Entry in Local DNS Server To Make Operation Transparent

The PIX Firewall can get the same functionality described here by using the outside address NAT functionality (bidirectional NAT) in the PIX Firewall (version 6.2 and later). This allows for DNS doctoring (with the use of the DNS keyword), as well as doing NAT on the source addresses for traffic going from a low-security interface to a high-security interface. The details of the actual functionality achieved, however, are the same.

0 0

Post a comment