-
Cisco Security Appliance Command Line Configuration Guide, Version 8.0
-
Index
-
About This Guide
-
Getting Started and General Information
-
Introduction to the Security Appliance
-
Getting Started
-
Enabling Multiple Context Mode
-
Configuring Interfaces for the Cisco ASA 5505 Adaptive Security Appliance
-
Configuring Ethernet Settings and Subinterfaces
-
Adding and Managing Security Contexts
-
Configuring Interface Parameters
-
Configuring Basic Settings
-
Configuring IP Routing
-
Configuring Multicast Routing
-
Configuring DHCP, DDNS, and WCCP Services
-
Configuring IPv6
-
Configuring AAA Servers and the Local Database
-
Configuring Failover
-
Using Modular Policy Framework
-
-
Configuring the Firewall
-
Firewall Mode Overview
-
Identifying Traffic With Access Lists
-
Configuring NAT
-
Permitting or Denying Network Access
-
Applying AAA for Network Access
-
Applying Filtering Services
-
Managing AIP SSM and CSC SSM
-
Preventing Network Attacks
-
Applying QoS Policies
-
Applying Application Layer Protocol Inspection
-
Configuring Cisco Unified Communications Support
-
Configuring ARP Inspection and Bridging Parameters in Transparent Mode
-
-
Configuring VPN
-
Configuring IPSec and ISAKMP
-
Configuring L2TP over IPSec
-
Setting General VPN Parameters
-
Configuring Tunnel Groups, Group Policies, and Users
-
Configuring IP Addresses for VPN
-
Configuring Remote Access VPNs
-
Configuring Network Admission Control
-
Configuring Easy VPN on the ASA 5505
-
Configuring the PPPoE Client
-
Configuring LAN-to-LAN VPNs
-
Configuring Clientless SSL VPN
-
Configuring AnyConnect VPN Client Connections
-
Configuring Certificates
-
- System Administration
- Reference
-
Glossary
-
Table Of Contents
Configuring Application Layer Protocol Inspection
When to Use Application Protocol Inspection
Configuring Application Inspection
Verifying and Monitoring CTIQBE Inspection
Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
How DNS Application Inspection Works
Using the Static Command for DNS Rewrite
Using the Alias Command for DNS Rewrite
Configuring DNS Rewrite with Two NAT Zones
DNS Rewrite with Three NAT Zones
Configuring DNS Rewrite with Three NAT Zones
Verifying and Monitoring DNS Inspection
Configuring a DNS Inspection Policy Map for Additional Inspection Control
Configuring an ESMTP Inspection Policy Map for Additional Inspection Control
Configuring an FTP Inspection Policy Map for Additional Inspection Control
Verifying and Monitoring FTP Inspection
Configuring a GTP Inspection Policy Map for Additional Inspection Control
Verifying and Monitoring GTP Inspection
Configuring an H.323 Inspection Policy Map for Additional Inspection Control
Configuring H.323 and H.225 Timeout Values
Verifying and Monitoring H.323 Inspection
Configuring an HTTP Inspection Policy Map for Additional Inspection Control
Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control
Configuring an MGCP Inspection Policy Map for Additional Inspection Control
Configuring MGCP Timeout Values
Verifying and Monitoring MGCP Inspection
Configuring MMP Inspection for a TLS Proxy
Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control
Configuring a RADIUS Inspection Policy Map for Additional Inspection Control
Configuring an RTSP Inspection Policy Map for Additional Inspection Control
Configuring a SIP Inspection Policy Map for Additional Inspection Control
Configuring SIP Timeout Values
Verifying and Monitoring SIP Inspection
Verifying and Monitoring SCCP Inspection
Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control
SMTP and Extended SMTP Inspection
Verifying and Monitoring Sun RPC Inspection
Configuring a SIP Inspection Policy Map for Additional Inspection Control
Configuring Application Layer Protocol Inspection
This chapter describes how to configure application layer protocol inspection. Inspection engines are required for services that embed IP addressing information in the user data packet or that open secondary channels on dynamically assigned ports. These protocols require the security appliance to do a deep packet inspection instead of passing the packet through the fast path (see the "Stateful Inspection Overview" section on page 1-14 for more information about the fast path). As a result, inspection engines can affect overall throughput.
Several common inspection engines are enabled on the security appliance by default, but you might need to enable others depending on your network. This chapter includes the following sections:
–
When to Use Application Protocol Inspection
•
•
Inspection Engine Overview
This section includes the following topics:
•
When to Use Application Protocol Inspection
When a user establishes a connection, the security appliance checks the packet against access lists, creates an address translation, and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks. However, the fast path relies on predictable port numbers and does not perform address translations inside a packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate dynamically assigned port numbers.
Other applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the security appliance.
If you use applications like these, then you need to enable application inspection.
When you enable application inspection for a service that embeds IP addresses, the security appliance translates embedded addresses and updates any checksum or other fields that are affected by the translation.
When you enable application inspection for a service that uses dynamically assigned ports, the security appliance monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.
Inspection Limitations
See the following limitations for application protocol inspection:
•
•
Default Inspection Policy
By default, the configuration includes a policy that matches all default application inspection traffic and applies inspection to the traffic on all interfaces (a global policy). Default application inspection traffic includes traffic to the default ports for each protocol. You can only apply one global policy, so if you want to alter the global policy, for example, to apply inspection to non-standard ports, or to add inspections that are not enabled by default, you need to either edit the default policy or disable it and apply a new one.
Table 25-1 lists all inspections supported, the default ports used in the default class map, and the inspection engines that are on by default, shown in bold. This table also notes any NAT limitations.
Table 25-1 Supported Application Inspection Engines
CTIQBE
TCP/2748
—
—
—
DNS over UDP
UDP/53
No NAT support is available for name resolution through WINS.
RFC 1123
No PTR records are changed.
FTP
TCP/21
—
RFC 959
—
GTP
UDP/3386
UDP/2123—
—
Requires a special license.
H.323 H.225 and RAS
TCP/1720 UDP/1718
UDP (RAS) 1718-1719No NAT on same security interfaces.
No static PAT.
ITU-T H.323, H.245, H225.0, Q.931, Q.932
—
HTTP
TCP/80
—
RFC 2616
Beware of MTU limitations stripping ActiveX and Java. If the MTU is too small to allow the Java or ActiveX tag to be included in one packet, stripping may not occur.
ICMP
—
—
—
All ICMP traffic is matched in the default class map.
ICMP ERROR
—
—
—
All ICMP traffic is matched in the default class map.
ILS (LDAP)
TCP/389
No PAT.
—
—
MGCP
UDP/2427, 2727
—
RFC 2705bis-05
—
MMP
TCP/TLS 5443
There are no embedded NAT or secondary connections.
—
—
NetBIOS Name Server over IP
UDP/137, 138 (Source ports)
—
—
NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138.
PPTP
TCP/1723
—
RFC 2637
—
RADIUS Accounting
1646
—
RFC 2865
—
RSH
TCP/514
No PAT
Berkeley UNIX
—
RTSP
TCP/554
No PAT.
No outside NAT.
RFC 2326, 2327, 1889
No handling for HTTP cloaking.
SIP
TCP/5060
UDP/5060No outside NAT.
No NAT on same security interfaces.
RFC 3261
—
SKINNY (SCCP)
TCP/2000
No outside NAT.
No NAT on same security interfaces.
—
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances.
SMTP and ESMTP
TCP/25
—
RFC 821, 1123
—
SNMP
UDP/161, 162
No NAT or PAT.
RFC 1155, 1157, 1212, 1213, 1215
v.2 RFC 1902-1908; v.3 RFC 2570-2580.
SQL*Net
TCP/1521
—
—
v.1 and v.2.
Sun RPC over UDP and TCP
UDP/111
No NAT or PAT.
—
The default class map includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new class map that matches TCP port 111, add the class to the policy, and then apply the inspect sunrpc command to that class.
TFTP
UDP/69
—
RFC 1350
Payload IP addresses are not translated.
XDCMP
UDP/177
No NAT or PAT.
—
—
1 Inspection engines that are enabled by default for the default port are in bold.
2 The security appliance is in compliance with these standards, but it does not enforce compliance on packets being inspected. For example, FTP commands are supposed to be in a particular order, but the security appliance does not enforce the order.
The default policy configuration includes the following commands:
class-map inspection_defaultmatch default-inspection-trafficpolicy-map type inspect dns preset_dns_mapparametersmessage-length maximum 512policy-map global_policyclass inspection_defaultinspect dns preset_dns_mapinspect ftpinspect h323 h225inspect h323 rasinspect rshinspect rtspinspect esmtpinspect sqlnetinspect skinnyinspect sunrpcinspect xdmcpinspect sipinspect netbiosinspect tftpservice-policy global_policy globalConfiguring Application Inspection
This feature uses Modular Policy Framework, so that implementing application inspection consists of identifying traffic, applying inspections to the traffic, and activating inspections on an interface. For some applications, you can perform special actions when you enable inspection. See Chapter 15, "Using Modular Policy Framework," for more information.
Inspection is enabled by default for some applications. See the "Default Inspection Policy" section for more information. Use this section to modify your inspection policy.
To configure application inspection, perform the following steps:
Step 1
The default Layer 3/4 class map for through traffic is called "inspection_default." It matches traffic using a special match command, match default-inspection-traffic, to match the default ports for each application protocol.
You can specify a match access-list command along with the match default-inspection-traffic command to narrow the matched traffic to specific IP addresses. Because the match default-inspection-traffic command specifies the ports to match, any ports in the access list are ignored.
If you want to match non-standard ports, then create a new class map for the non-standard ports. See the "Default Inspection Policy" section for the standard ports for each inspection engine. You can combine multiple class maps in the same policy if desired, so you can create one class map to match certain traffic, and another to match different traffic. However, if traffic matches a class map that contains an inspection command, and then matches another class map that also has an inspection command, only the first matching class is used. For example, SNMP matches the inspection_default class. To enable SNMP inspection, enable SNMP inspection for the default class in Step 5. Do not add another class that matches SNMP.
For example, to limit inspection to traffic from 10.1.1.0 to 192.168.1.0 using the default class map, enter the following commands:
hostname(config)# access-list inspect extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0hostname(config)# class-map inspection_defaulthostname(config-cmap)# match access-list inspectView the entire class map using the following command:
hostname(config-cmap)# show running-config class-map inspection_default!class-map inspection_defaultmatch default-inspection-trafficmatch access-list inspect!To inspect FTP traffic on port 21 as well as 1056 (a non-standard port), create an access list that specifies the ports, and assign it to a new class map:
hostname(config)# access-list ftp_inspect extended permit tcp any any eq 21hostname(config)# access-list ftp_inspect extended permit tcp any any eq 1056hostname(config)# class-map new_inspectionhostname(config-cmap)# match access-list ftp_inspectStep 2
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Step 3
hostname(config)# policy-map namehostname(config-pmap)#The default policy map is called "global_policy." This policy map includes the default inspections listed in the "Default Inspection Policy" section. If you want to modify the default policy (for example, to add or delete an inspection, or to identify an additional class map for your actions), then enter global_policy as the name.
Step 4
hostname(config-pmap)# class class_map_namehostname(config-pmap-c)#If you are editing the default policy map, it includes the inspection_default class map. You can edit the actions for this class by entering inspection_default as the name. To add an additional class map to this policy map, identify a different name. You can combine multiple class maps in the same policy if desired, so you can create one class map to match certain traffic, and another to match different traffic. However, if traffic matches a class map that contains an inspection command, and then matches another class map that also has an inspection command, only the first matching class is used. For example, SNMP matches the inspection_default class map.To enable SNMP inspection, enable SNMP inspection for the default class in Step 5. Do not add another class that matches SNMP.
Step 5
hostname(config-pmap-c)# inspect protocolThe protocol is one of the following values:
Table 25-2 Protocol Keywords
ctiqbe
—
dcerpc [map_name]
If you added a DCERPC inspection policy map according to "Configuring a DCERPC Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
dns [map_name]
If you added a DNS inspection policy map according to "Configuring a DNS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command. The default DNS inspection policy map name is "preset_dns_map." The default inspection policy map sets the maximum DNS packet length to 512 bytes.
esmtp [map_name]
If you added an ESMTP inspection policy map according to "Configuring an ESMTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
ftp [strict [map_name]]
Use the strict keyword to increase the security of protected networks by preventing web browsers from sending embedded commands in FTP requests. See the "Using the strict Option" section for more information.
If you added an FTP inspection policy map according to "Configuring an FTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
gtp [map_name]
If you added a GTP inspection policy map according to the "Configuring a GTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 h225 [map_name]
If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
h323 ras [map_name]
If you added an H323 inspection policy map according to "Configuring an H.323 Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
http [map_name]
If you added an HTTP inspection policy map according to the "Configuring an HTTP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
icmp
—
icmp error
—
ils
—
im [map_name]
If you added an Instant Messaging inspection policy map according to "Configuring an Instant Messaging Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
mgcp [map_name]
If you added an MGCP inspection policy map according to "Configuring an MGCP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
mmp tls-proxy [name]
—
netbios [map_name]
If you added a NetBIOS inspection policy map according to "Configuring a NetBIOS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
pptp
—
radius-accounting [map_name]
The radius-accounting keyword is only available for a management class map. See the "Creating a Layer 3/4 Class Map for Management Traffic" section on page 15-7 for more information about creating a management class map.
If you added a RADIUS accounting inspection policy map according to "Configuring a RADIUS Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
rsh
—
rtsp [map_name]
If you added a NetBIOS inspection policy map according to "Configuring an RTSP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
sip [map_name]
If you added a SIP inspection policy map according to "Configuring a SIP Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
skinny [map_name]
If you added a Skinny inspection policy map according to "Configuring a Skinny (SCCP) Inspection Policy Map for Additional Inspection Control" section, identify the map name in this command.
snmp [map_name]
If you added an SNMP inspection policy map according to "SNMP Inspection" section, identify the map name in this command.
sqlnet
—
sunrpc
The default class map includes UDP port 111; if you want to enable Sun RPC inspection for TCP port 111, you need to create a new class map that matches TCP port 111, add the class to the policy, and then apply the inspect sunrpc command to that class.
tftp
—
xdmcp
—
Step 6
hostname(config)# service-policy policymap_name {global | interface interface_name}Where global applies the policy map to all interfaces, and interface applies the policy to one interface. By default, the default policy map, "global_policy," is applied globally. Only one global policy is allowed. You can override the global policy on an interface by applying a service policy to that interface. You can only apply one policy map to each interface.
CTIQBE Inspection
This section describes CTIQBE application inspection. This section includes the following topics:
•
CTIQBE Inspection Overview
CTIQBE protocol inspection supports NAT, PAT, and bidirectional NAT. This enables Cisco IP SoftPhone and other Cisco TAPI/JTAPI applications to work successfully with Cisco CallManager for call setup across the security appliance.
TAPI and JTAPI are used by many Cisco VoIP applications. CTIQBE is used by Cisco TSP to communicate with Cisco CallManager.
Limitations and Restrictions
The following summarizes limitations that apply when using CTIQBE application inspection:
•
•
•
The following summarizes special considerations when using CTIQBE application inspection in specific scenarios:
•
•
•
Verifying and Monitoring CTIQBE Inspection
The show ctiqbe command displays information regarding the CTIQBE sessions established across the security appliance. It shows information about the media connections allocated by the CTIQBE inspection engine.
The following is sample output from the show ctiqbe command under the following conditions. There is only one active CTIQBE session setup across the security appliance. It is established between an internal CTI device (for example, a Cisco IP SoftPhone) at local address 10.0.0.99 and an external Cisco CallManager at 172.29.1.77, where TCP port 2748 is the Cisco CallManager. The heartbeat interval for the session is 120 seconds.
hostname# # show ctiqbeTotal: 1LOCAL FOREIGN STATE HEARTBEAT---------------------------------------------------------------1 10.0.0.99/1117 172.29.1.77/2748 1 120----------------------------------------------RTP/RTCP: PAT xlates: mapped to 172.29.1.99(1028 - 1029)----------------------------------------------MEDIA: Device ID 27 Call ID 0Foreign 172.29.1.99 (1028 - 1029)Local 172.29.1.88 (26822 - 26823)----------------------------------------------The CTI device has already registered with the CallManager. The device internal address and RTP listening port is PATed to 172.29.1.99 UDP port 1028. Its RTCP listening port is PATed to UDP 1029.
The line beginning with RTP/RTCP: PAT xlates: appears only if an internal CTI device has registered with an external CallManager and the CTI device address and ports are PATed to that external interface. This line does not appear if the CallManager is located on an internal interface, or if the internal CTI device address and ports are translated to the same external interface that is used by the CallManager.
The output indicates a call has been established between this CTI device and another phone at 172.29.1.88. The RTP and RTCP listening ports of the other phone are UDP 26822 and 26823. The other phone locates on the same interface as the CallManager because the security appliance does not maintain a CTIQBE session record associated with the second phone and CallManager. The active call leg on the CTI device side can be identified with Device ID 27 and Call ID 0.
The following is sample output from the show xlate debug command for these CTIBQE connections:
hostname# show xlate debug3 in use, 3 most usedFlags: D - DNS, d - dump, I - identity, i - inside, n - no random,r - portmap, s - staticTCP PAT from inside:10.0.0.99/1117 to outside:172.29.1.99/1025 flags ri idle 0:00:22 timeout 0:00:30UDP PAT from inside:10.0.0.99/16908 to outside:172.29.1.99/1028 flags ri idle 0:00:00 timeout 0:04:10UDP PAT from inside:10.0.0.99/16909 to outside:172.29.1.99/1029 flags ri idle 0:00:23 timeout 0:04:10The show conn state ctiqbe command displays the status of CTIQBE connections. In the output, the media connections allocated by the CTIQBE inspection engine are denoted by a `C' flag. The following is sample output from the show conn state ctiqbe command:
hostname# show conn state ctiqbe1 in use, 10 most usedhostname# show conn state ctiqbe detail1 in use, 10 most usedFlags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,B - initial SYN from outside, C - CTIQBE media, D - DNS, d - dump,E - outside back connection, F - outside FIN, f - inside FIN,G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,i - incomplete, J - GTP, j - GTP data, k - Skinny media,M - SMTP data, m - SIP media, O - outbound data, P - inside back connection,q - SQL*Net data, R - outside acknowledged FIN,R - UDP RPC, r - inside acknowledged FIN, S - awaiting inside SYN,s - awaiting outside SYN, T - SIP, t - SIP transient, U - upDCERPC Inspection
This section describes the DCERPC inspection engine. This section includes the following topics:
•
DCERPC Overview
DCERPC is a protocol widely used by Microsoft distributed client and server applications that allows software clients to execute programs on a server remotely.
This typically involves a client querying a server called the Endpoint Mapper listening on a well known port number for the dynamically allocated network information of a required service. The client then sets up a secondary connection to the server instance providing the service. The security appliance allows the appropriate port number and network address and also applies NAT, if needed, for the secondary connection.
DCERPC inspect maps inspect for native TCP communication between the EPM and client on well known TCP port 135. Map and lookup operations of the EPM are supported for clients. Client and server can be located in any security zone. The embedded server IP address and Port number are received from the applicable EPM response messages. Since a client may attempt multiple connections to the server port returned by EPM, multiple use of pinholes are allowed, which have user configurable timeouts.
Configuring a DCERPC Inspection Policy Map for Additional Inspection Control
To specify additional DCERPC inspection parameters, create a DCERPC inspection policy map. You can then apply the inspection policy map when you enable DCERPC inspection according to the "Configuring Application Inspection" section.
To create a DCERPC inspection policy map, perform the following steps:
Step 1
hostname(config)# policy-map type inspect dcerpc policy_map_namehostname(config-pmap)#Where the policy_map_name is the name of the policy map. The CLI enters policy-map configuration mode.
Step 2
hostname(config-pmap)# description stringStep 3
a.
hostname(config-pmap)# parametershostname(config-pmap-p)#b.
hostname(config-pmap-p)# timeout pinhole hh:mm:ssWhere the hh:mm:ss argument is the timeout for pinhole connections. Value is between 0:0:1 and 1193:0:0.
c.
hostname(config-pmap-p)# endpoint-mapper [epm-service-only] [lookup-operation [timeout hh:mm:ss]]Where the hh:mm:ss argument is the timeout for pinholes generated from the lookup operation. If no timeout is configured for the lookup operation, the timeout pinhole command or the default is used. The epm-service-only keyword enforces endpoint mapper service during binding so that only its service traffic is processed. The lookup-operation keyword enables the lookup operation of the endpoint mapper service.
The following example shows how to define a DCERPC inspection policy map with the timeout configured for DCERPC pinholes.
hostname(config)# policy-map type inspect dcerpc dcerpc_maphostname(config-pmap)# timeout pinhole 0:10:00hostname(config)# class-map dcerpchostname(config-cmap)# match port tcp eq 135hostname(config)# policy-map global-policyhostname(config-pmap)# class dcerpchostname(config-pmap-c)# inspect msrpc dcerpc-maphostname(config)# service-policy global-policy globalDNS Inspection
This section describes DNS application inspection. This section includes the following topics:
•
•
How DNS Application Inspection Works
The security appliance tears down the DNS session associated with a DNS query as soon as the DNS reply is forwarded by the security appliance. The security appliance also monitors the message exchange to ensure that the ID of the DNS reply matches the ID of the DNS query.
When DNS inspection is enabled, which is the default, the security appliance performs the following additional tasks:
•
Note
•
Note
•
•
•
A single connection is created for multiple DNS sessions, as long as they are between the same two hosts, and the sessions have the same 5-tuple (source/destination IP address, source/destination port, and protocol). DNS identification is tracked by app_id, and the idle timer for each app_id runs independently.
Because the app_id expires independently, a legitimate DNS response can only pass through the security appliance within a limited period of time and there is no resource build-up. However, if you enter the show conn command, you will see the idle timer of a DNS connection being reset by a new DNS session. This is due to the nature of the shared DNS connection and is by design.
How DNS Rewrite Works
When DNS inspection is enabled, DNS rewrite provides full support for NAT of DNS messages originating from any interface.
If a client on an inside network requests DNS resolution of an inside address from a DNS server on an outside interface, the DNS A-record is translated correctly. If the DNS inspection engine is disabled, the A-record is not translated.
As long as DNS inspection remains enabled, you can configure DNS rewrite using the alias, static, or nat commands. For details about the configuration required see the "Configuring DNS Rewrite" section.
DNS Rewrite performs two functions:
•
•
In Figure 25-1, the DNS server resides on the external (ISP) network The real address of the server (192.168.100.1) has been mapped using the static command to the ISP-assigned address (209.165.200.5). When a web client on the inside interface attempts to access the web server with the URL http://server.example.com, the host running the web client sends a DNS request to the DNS server to resolve the IP address of the web server. The security appliance translates the non-routable source address in the IP header and forwards the request to the ISP network on its outside interface. When the DNS reply is returned, the security appliance applies address translation not only to the destination address, but also to the embedded IP address of the web server, which is contained in the A-record in the DNS reply. As a result, the web client on the inside network gets the correct address for connecting to the web server on the inside network. For configuration instructions for scenarios similar to this one, see the "Configuring DNS Rewrite with Two NAT Zones" section.
Figure 25-1 Translating the Address in a DNS Reply (DNS Rewrite)
DNS rewrite also works if the client making the DNS request is on a DMZ network and the DNS server is on an inside interface. For an illustration and configuration instructions for this scenario, see the "DNS Rewrite with Three NAT Zones" section.
Configuring DNS Rewrite
You configure DNS rewrite using the alias, static, or nat commands. The alias and static command can be used interchangeably; however, we recommend using the static command for new deployments because it is more precise and unambiguous. Also, DNS rewrite is optional when using the static command.
This section describes how to use the alias and static commands to configure DNS rewrite. It provides configuration procedures for using the static command in a simple scenario and in a more complex scenario. Using the nat command is similar to using the static command except that DNS Rewrite is based on dynamic translation instead of a static mapping.
This section includes the following topics:
•
•
•
•
•
For detailed syntax and additional functions for the alias, nat, and static command, see the appropriate command page in the Cisco Security Appliance Command Reference.
Using the Static Command for DNS Rewrite
The static command causes addresses on an IP network residing on a specific interface to be translated into addresses on another IP network on a different interface. The syntax for this command is as follows:
hostname(config)# static (real_ifc,mapped_ifc) mapped-address real-address dnsThe following example specifies that the address 192.168.100.10 on the inside interface is translated into 209.165.200.5 on the outside interface:
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.10 dns
Note
Using the Alias Command for DNS Rewrite
The alias command causes the security appliance to translate addresses on an IP network residing on any interface into addresses on another IP network connected through a different interface. The syntax for this command is as follows:
hostname(config)# alias (interface_name) mapped-address real-addressThe following example specifies that the real address (192.168.100.10) on any interface except the inside interface will be translated to the mapped address (209.165.200.225) on the inside interface. Notice that the location of 192.168.100.10 is not precisely defined.
hostname(config)# alias (inside) 209.165.200.225 192.168.100.10
Note
Configuring DNS Rewrite with Two NAT Zones
To implement a DNS Rewrite scenario similar to the one shown in Figure 25-1, perform the following steps:
Step 1
hostname(config)# static (real_ifc,mapped_ifc) mapped-address real-address netmask 255.255.255.255 dnswhere the arguments are as follows:
•
•
•
•
Step 2
hostname(config)# access-list acl-name extended permit tcp any host mapped-address eq portwhere the arguments are as follows:
acl-name—The name you give the access list.
mapped-address—The translated IP address of the web server.
port—The TCP port that the web server listens to for HTTP requests.
Step 3
hostname(config)# access-group acl-name in interface mapped_ifcStep 4
Step 5
domain-qualified-hostname. IN A mapped-addresswhere domain-qualified-hostname is the hostname with a domain suffix, as in server.example.com. The period after the hostname is important. mapped-address is the translated IP address of the web server.
The following example configures the security appliance for the scenario shown in Figure 25-1. It assumes DNS inspection is already enabled.
hostname(config)# static (inside,outside) 209.165.200.225 192.168.100.1 netmask 255.255.255.255 dnshostname(config)# access-list 101 permit tcp any host 209.165.200.225 eq wwwhostname(config)# access-group 101 in interface outsideThis configuration requires the following A-record on the DNS server:
server.example.com. IN A 209.165.200.225DNS Rewrite with Three NAT Zones
Figure 25-2 provides a more complex scenario to illustrate how DNS inspection allows NAT to operate transparently with a DNS server with minimal configuration. For configuration instructions for scenarios like this one, see the "Configuring DNS Rewrite with Three NAT Zones" section.
Figure 25-2 DNS Rewrite with Three NAT Zones
In Figure 25-2, a web server, server.example.com, has the real address 192.168.100.10 on the DMZ interface of the security appliance. A web client with the IP address 10.10.10.25 is on the inside interface and a public DNS server is on the outside interface. The site NAT policies are as follows:
•
•
•
