About the Author

author photo

Joe Harris, CCIE No. 6200 (R&S, Security & SP) is a Systems Engineer with Cisco Systems® specializing in Security. In addition to authoring Cisco Network Security Little Black Book, Joe has also been a technical reviewer for several Cisco Press publications and written articles, white papers, and presentations on various security technologies. He also assists various Certification Partners by beta testing their newest CCIE certification workbooks and has been recognized by Cisco as an SE Wall of Fame award winner.

See All Posts by This Author

ASA with WAAS Deployment

October 25th, 2007 • Related • Filed Under

Had a partner that is evaluating an ASA 5520 with an AIP-SSM-20 (IPS module) installed in the SSM slot in a WAAS deployment scenario. They wanted to confirm the behavior of the ASA when the ‘inspect wccp’ command was enabled.

policy-map global_policy
class inspection_default
inspect waas

After enabling the command they checked the output of the ‘show service-policy ips’ command and the counter did not increase. So they concluded that the traffic processed by WAAS bypasses the AIP-SSM and they were wondering if this is the correct conclusion? And the answer to their question is yes, when traffic is compressed/optimized by WAAS, other deep packet inspection functions can’t be done and with the AIP-SSM module installed and configured, once WAAS auto-discovery is confirmed, i.e. option 33 is observed during the TCP 3-way handshake, the AIP-SSM inspection will be by-passed. All TCP based applications will be optimized by WAAS according to the configured policy. The CSC-SSM module on the other hand proxies TCP connections and thus will disable WAAS optimization so please keep in mind that the CSC-SSM module is not supported with WAAS deployment.

There Are 4 Responses So Far. »

  1. Gravatar

    Comment by Justin Lofton on 25 October 2007:

    Great article Joe! A lot of people want to know more about WAAS and its capabilities.

    Justin Lofton
    Systems Engineer
    Tredent Data Systems, Inc.
    justinl@tredent.com
    http://www.tredent.com

  2. Gravatar

    Comment by Joe Harris on 27 October 2007:

    Hi Justin,

    Wow, I never really looked at the information related to WAAS from an external distribution standpoint, like CCO. I guess I take for granted all the information we get access to internal to Cisco…I will see what information can be posted external and do a more focused job on helping the customer/partner community get a better understanding of WAAS and its operation. Of course I cannot publish anything that is marked “Internal Only” or “Cisco Confedential” ect. and I take Cisco’s Intellectual Property Rights very seriously. If nothing else maybe I could put together a few training videos and post them up using my demo equipment. I plan on doing some for MARS, ASA, CCA and a few others products anyway, so I guess I should add WAAS to the list….Anyway, great feedback an much appreciated, this is the exact purpose and reasoning behind me creating this blog. You guys keep the suggestions/comments coming!!

  3. Gravatar

    Comment by Petr Ruzicka on 31 October 2007:

    Joe, I’m wondering about the following situation.
    Let’s say I know my company does use WAAS. I want to prevent checks against my traffic, ie. to bypass IPS/deep-packets-inspection/whatever.
    If I use machine somewhere with my own stack customization baked in and use the very same parameters like WAAS (option 33) will checks against my traffic be automatically skipped ? Thanks P.

  4. Gravatar

    Comment by Joe Harris on 1 November 2007:

    Hum.. :-? … a customer asked me about this today in fact. The answer I got back was that the ASA does check for option 33 and mark such packets as WAAS traffic. However, ASA/PIX also makes other changes to the TCP segments to adhere with WAAS traffic behavior such as to allow timestamp, SACK, window scale factor of X and increase the next expected sequence number and the max acknowledged number.

    So theoretically speaking, yes, you can modify the stack and use option 33 to let such traffic bypass IPS and state check, but you’re also making other changes to the traffic which might have other unknown side effects (as mentioned above) and if these changes do not match exactly the expected changes the ASA is configured to look for, then your customization will not bypass deep packet inspection or the IPS (depending on the service policy defined) and in fact your traffic could be dropped altogether!

Post a Response