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 ASA to do a deep packet inspection instead of passing the packet through the fast path. As a result, inspection engines can affect overall throughput. Several common inspection engines are enabled on the ASA by default, but you might need to enable others depending on your network.
The following topics explain application inspection in more detail.
When to Use Application Protocol Inspection
When a user establishes a connection, the ASA checks the packet against ACLs, 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 ASA.
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 ASA 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 ASA monitors sessions to identify the dynamic port assignments, and permits data exchange on these ports for the duration of the specific session.
Inspection Policy Maps
You can configure special actions for many application inspections using an inspection policy map. These maps are optional: you can enable inspection for a protocol that supports inspection policy maps without configuring a map. These maps are needed only if you want something other than the default inspection actions.
An inspection policy map consists of one or more of the following elements. The exact options available for an inspection policy map depends on the application.
-
Traffic matching criteria—You match application traffic to criteria specific to the application, such as a URL string, for which you then enable actions.
For some traffic matching criteria, you use regular expressions to match text inside a packet. Be sure to create and test the regular expressions before you configure the policy map, either singly or grouped together in a regular expression class map.
-
Inspection class map—Some inspection policy maps let you use an inspection class map to include multiple traffic matching criteria. You then identify the inspection class map in the inspection policy map and enable actions for the class as a whole. The difference between creating a class map and defining the traffic match directly in the inspection policy map is that you can create more complex match criteria and you can reuse class maps. However, you cannot set different actions for different matches.
-
Parameters—Parameters affect the behavior of the inspection engine.
The following topics provide more details.
Replacing an In-Use Inspection Policy Map
If you have an inspection enabled with a policy map in a service policy, replacing the policy map is a two-step process. First, you must remove the inspection from the service policy and apply changes. Then, you add it back, select the new policy map name, and again apply changes.
How Multiple Traffic Classes are Handled
You can specify multiple inspection class maps or direct matches in the inspection policy map.
If a packet matches multiple different classes or direct matches, then the order in which the ASA applies the actions is determined by internal ASA rules, and not by the order they are added to the inspection policy map. The internal rules are determined by the application type and the logical progression of parsing a packet, and are not user-configurable. For example for HTTP traffic, parsing a Request Method field precedes parsing the Header Host Length field; an action for the Request Method field occurs before the action for the Header Host Length field.
If an action drops a packet, then no further actions are performed in the inspection policy map. For example, if the first action is to reset the connection, then it will never match any further match criteria. If the first action is to log the packet, then a second action, such as resetting the connection, can occur.
If a packet matches multiple match criteria that are the same, then they are matched in the order they appear in the policy map.
A class map is determined to be the same type as another class map or direct match based on the lowest priority match option in the class map (the priority is based on the internal rules). If a class map has the same type of lowest priority match option as another class map, then the class maps are matched according to the order they are added to the policy map. If the lowest priority match for each class map is different, then the class map with the higher priority match option is matched first.
Guidelines for Application Inspection
Failover
State information for multimedia sessions that require inspection are not passed over the state link for stateful failover. The exceptions are GTP, M3UA, and SIP, which are replicated over the state link. You must configure strict application server process (ASP) state checking in M3UA inspection to get stateful failover.
Clustering
The following inspections are not supported in clustering:
-
CTIQBE
-
H323, H225, and RAS
-
IPsec passthrough
-
MGCP
-
MMP
-
RTSP
-
SCCP (Skinny)
-
WAAS
IPv6
Supports IPv6 for the following inspections:
-
Diameter
-
DNS over UDP
-
FTP
-
GTP
-
HTTP
-
ICMP
-
IPsec pass-through
-
IPv6
-
M3UA
-
SCCP (Skinny)
-
SCTP
-
SIP
-
SMTP
-
VXLAN
Supports NAT64 for the following inspections:
-
DNS over UDP
-
FTP
-
HTTP
-
ICMP
-
SCTP
Additional Guidelines
-
Some inspection engines do not support PAT, NAT, outside NAT, or NAT between same security interfaces. For more information about NAT support, see Default Inspections and NAT Limitations.
-
For all the application inspections, the ASA limits the number of simultaneous, active data connections to 200 connections. For example, if an FTP client opens multiple secondary connections, the FTP inspection engine allows only 200 active connections and the 201 connection is dropped and the adaptive security appliance generates a system error message.
-
Inspected protocols are subject to advanced TCP-state tracking, and the TCP state of these connections is not automatically replicated. While these connections are replicated to the standby unit, there is a best-effort attempt to re-establish a TCP state.
-
If the system determines that a TCP connection requires inspection, the system clears all TCP options except for the MSS and selective-acknowledgment (SACK) options on the packets before inspecting them. Other options are cleared even if you allow them in a TCP map applied to the connections.
-
TCP/UDP Traffic directed to the ASA (to an interface) is inspected by default. However, ICMP traffic directed to an interface is never inspected, even if you enable ICMP inspection. Thus, a ping (echo request) to an interface can fail under specific circumstances, such as when the echo request comes from a source that the ASA can reach through a backup default route.
Defaults for Application Inspection
The following topics explain the default operations for application inspection.
Default Inspections and NAT Limitations
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.
The following table 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. In this table:
-
Inspection engines that are enabled by default for the default port are in bold.
-
The ASA is in compliance with the indicated 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 ASA does not enforce the order.
Application |
Default Protocol, Port |
NAT Limitations |
Standards |
Comments |
---|---|---|---|---|
CTIQBE |
TCP/2748 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
— |
DCERPC |
TCP/135 |
No NAT64. |
— |
— |
Diameter |
TCP/3868 TCP/5868 (for TCP/TLS) SCTP/3868 |
No NAT/PAT. |
RFC 6733 |
Requires the Carrier license. |
DNS over UDP DNS over TCP |
UDP/53 UDP/443 TCP/53 |
No NAT support is available for name resolution through WINS. |
RFC 1123 |
You must enable DNS/TCP inspection in the DNS inspection policy map to inspect DNS over TCP. UDP/443 is used for Cisco Umbrella DNScrypt sessions only. |
FTP |
TCP/21 |
(Clustering) No static PAT. |
RFC 959 |
— |
GTP |
UDP/3386 (GTPv0) UDP/2123 (GTPv1+) |
No extended PAT. No NAT. |
— |
Requires the Carrier license. |
H.323 H.225 and RAS |
TCP/1720 UDP/1718 UDP (RAS) 1718-1719 |
(Clustering) No static PAT. No extended PAT. No NAT on same security interfaces. No NAT64. |
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 |
ICMP |
— |
— |
ICMP traffic directed to an ASA interface is never inspected. |
ICMP ERROR |
ICMP |
— |
— |
— |
ILS (LDAP) |
TCP/389 |
No extended PAT. No NAT64. |
— |
— |
Instant Messaging (IM) |
Varies by client |
No extended PAT. No NAT64. |
RFC 3860 |
— |
IP Options |
RSVP |
No NAT64. |
RFC 791, RFC 2113 |
— |
IPsec Pass Through |
UDP/500 |
No PAT. No NAT64. |
— |
— |
IPv6 |
— |
No NAT64. |
RFC 2460 |
— |
LISP |
— |
No NAT or PAT. |
— |
— |
M3UA |
SCTP/2905 |
No NAT or PAT for embedded addresses. |
RFC 4666 |
Requires the Carrier license. |
MGCP |
UDP/2427, 2727 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
RFC 2705bis-05 |
— |
MMP |
TCP/5443 |
No extended PAT. No NAT64. |
— |
— |
NetBIOS Name Server over IP |
UDP/137, 138 (Source ports) |
No extended PAT. No NAT64. |
— |
NetBIOS is supported by performing NAT of the packets for NBNS UDP port 137 and NBDS UDP port 138. |
PPTP |
TCP/1723 |
No NAT64. (Clustering) No static PAT. |
RFC 2637 |
— |
RADIUS Accounting |
UDP/1646 |
No NAT64. |
RFC 2865 |
— |
RSH |
TCP/514 |
No PAT. No NAT64. (Clustering) No static PAT. |
Berkeley UNIX |
— |
RTSP |
TCP/554 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
RFC 2326, 2327, 1889 |
No handling for HTTP cloaking. |
SCTP |
SCTP |
— |
RFC 4960 |
Requires the Carrier license. Although you can do static network object NAT on SCTP traffic (no dyamic NAT/PAT), the inspection engine is not used for NAT. |
SIP |
TCP/5060 UDP/5060 |
No NAT/PAT on interfaces with the same, or lower to higher, security levels. No extended PAT. No NAT64 or NAT46. (Clustering) No static PAT. |
RFC 2543 |
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances. |
SKINNY (SCCP) |
TCP/2000 |
No NAT on same security interfaces. No extended PAT. No NAT64, NAT46, or NAT66. (Clustering) No static PAT. |
— |
Does not handle TFTP uploaded Cisco IP Phone configurations under certain circumstances. |
SMTP and ESMTP |
TCP/25 |
No NAT64. |
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 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
v.1 and v.2. |
STUN |
TCP/3478 UDP/3478 |
(WebRTC) Static NAT/PAT44 only. (Cisco Spark) Static NAT/PAT44 and 64; and dynamic NAT/PAT. |
RFC 5245, 5389 |
— |
Sun RPC |
TCP/111 UDP/111 |
No extended PAT. No NAT64. |
— |
— |
TFTP |
UDP/69 |
No NAT64. (Clustering) No static PAT. |
RFC 1350 |
Payload IP addresses are not translated. |
WAAS |
TCP/1- 65535 |
No extended PAT. No NAT64. |
— |
— |
XDMCP |
UDP/177 |
No extended PAT. No NAT64. (Clustering) No static PAT. |
— |
— |
VXLAN |
UDP/4789 |
Not applicable |
RFC 7348 |
Virtual Extensible Local Area Network. |
Default Inspection Policy Maps
Some inspection types use hidden default policy maps. For example, if you enable ESMTP inspection without specifying a map, _default_esmtp_map is used.
The default inspection is described in the sections that explain each inspection type. You can view these default maps using the show running-config all policy-map command; use Tools > Command Line Interface.
DNS inspection is the only one that uses an explicitly-configured default map, preset_dns_map.