ASA Accelerated Security Path

This post will provide a brief overview of a seldom referred to part of the ASA, the Accelerated Security Path (ASP). As we know the ASA’s Adaptive Security Algorithm is responsible for inspecting all traffic that traverses the ASA, and based on its configured security policies will either permit or deny the traffic.

As a new connection enters the ASA it is processed using the Session Management Path.

Part of the Session Management Path’s processing is to inspect and create the relevant entry in the ASA’s state/connection table, if a policies exists allowing the traffic.

Generally any further packets received for these established connections, does not require further inspection and are subsequently handled by the Fast Path. Although, there may be certain packets that would continue to use the session management path or be passed to the control plane path, such as flows requiring HTTP inspection, FTP or H.232 etc.

This is akin to Process switching and CEF switching in IOS Routers.

The Session Management Path and Fast Path combined are what make up the Accelerated Security Path.

ASP can come in handy when we want to troubleshoot traffic flows through the ASA. This is done via a suite of ASP show commands, and can also be incorporated into packet captures, using a capture type of asp-drop.

With ASP debugging we can drill down into the output to see what functions or methods are responsible for dropping the traffic on the ASA. There are two set of commands available to us, both of which have a substantial amount of optional keywords; these are, ‘show asp drop’ and show asp table’.

Starting with ‘show asp drop’ will give us a summary of packets or connections that have been denied by ASP providing an associated reason and hits on each. As we can see from the output below it is split into 2 sections; Frame Drop – which is based on packet failures; and Flow Drop – based on inspected traffic flow failures.

It gives us a brief breakdown of denies based on malformed TCP sessions, Reverse Path Forwarding violations, or simply denies based on ACL entries etc.

ASA# show asp drop
Frame drop:
Reverse-path verify failed (rpf-violated)                                 1432
Flow is denied by configured rule (acl-drop)                         100495787
First TCP packet not SYN (tcp-not-syn)                                    2234
TCP failed 3 way handshake (tcp-3whs-failed)                                20
TCP packet SEQ past window (tcp-seq-past-win)                               28
TCP replicated flow pak drop (tcp-fo-drop)                                   8
TCP RST/SYN in window (tcp-rst-syn-in-win)                                   2
TCP packet failed PAWS test (tcp-paws-fail)                                  3
Slowpath security checks failed (sp-security-failed)                         1
Expired flow (flow-expired)                                                  2
ICMP Inspect seq num not matched (inspect-icmp-seq-num-not-matched)          6
FP L2 rule drop (l2_acl)                                               7911378
Interface is down (interface-down)                                        1143
Dropped pending packets in a closed socket (np-socket-closed)               19
Last clearing: Never
Flow drop:
Inspection failure (inspect-fail)                                            2
Last clearing: Never

You can also further drill into more specific output using optional keywords, based on either frame or flow drop, such as “show asp drop frame ifc-classify” – when in virtual firewall mode shows counts for packets that failed to be classified to context; or “show asp drop flow conn-limit-exceeded” – increments when the value applied to set connection conn-max is breached.

These are just a couple of the vast amount of options available for use. Check out the ASA Command Reference document for a full listing.

A key point with the ASP drop output is when running in Multi Context Mode, the information provided is a summary for all of the virtual contexts not just the context you are currently logged into.

The other side of ASP is the “show asp table” commands. These are typically used by TAC, so contain a great deal of info on a production appliance. These tables are primarily used for debugging, so the output is prone to regular changes.

Below are the asp tables available:

ASA# show asp table ?
arp
classify    Show ASP classifier tables
interfaces  Show ASP interfaces tables
routing     Show ASP route tables
socket      Show ASP socket info

The “show asp table arp” for instance can be used to check that traffic is flowing to/from a specific host/s based on an incrementing hit count. It is important to remember that this is dynamic real time output though and will be subject to resetting.

ASA# sh asp table arp
Context: LEFT, Interface: Inside
10.1.1.66                            Active   0050.56a5.35b9 hits 15
10.1.1.65                            Active   0050.56a5.7d06 hits 0

The “show asp table routing” can give us further info into how specific nets are routed. This is provided based on two tables; an input routing table and an output routing table, each showing the routable nets and their associated interfaces.

ASA# sh asp table routing
in   	10.1.1.64   	255.255.255.192	Inside
out  	10.1.1.64   	255.255.255.192	Inside
in 	0.0.0.0		0.0.0.0			Outside
out 	0.0.0.0		0.0.0.0			via 10.1.1.254, Outside

And to finish off a quick look at the classify table. This table consists of multiple classifier domains which correspond to a specific rule action within the ASA, I.e. Inspection rules, filtering rules nat rules etc. Again check out the command reference for a list of the options.

Below is an example showing SMTP traffic is being inspected and allowed to the inside interface:

ASA# sh asp table classify domain inspect-smtp
Interface Inside:
in  id=0x1d43bbf0, priority=70, domain=inspect-smtp, deny=false
hits=89, user_data=0x1d1a18f0, cs_id=0x0, use_real_addr, flags=0x0, protocol=6
src ip=0.0.0.0, mask=0.0.0.0, port=0
dst ip=0.0.0.0, mask=0.0.0.0, port=25, dscp=0x0

The documentation for ASP is minimal, the best way forward with this is get your head into the output and retain what you feel is useful.

So the next time your caught in a troubleshooting exercise check out the ASP output and see whether combining this with your debug, captures and logs, can assist in resolving your issues!!

–
Stuart Hare
CCIE #25616 (Security), CCSP, Microsoft MCP
Sr. Support Engineer – IPexpert, Inc.
URL: http://www.ipexpert.com

ASA Accelerated Security Path, 5.0 out of 5 based on 1 rating

Tags: Accelerated Path, ASA, CCIE 3.0 Security