Recently had to use this (useful?) feature to help a customer with an asymmetric traffic flow via an ASA. The ASA would only see the out bound traffic from a host with the return traffic going via an alternative path not visible to the ASA.This simple diagram is an example of the flow and with default ASA configs in place the TCP state tracking would block tcp traffic (ICMP ect worked fine).
Green is outbound via ASA, Orange is from ASA to destination host and blue is return traffic back from destination not going via ASA. To work around this Cisco gives us this little option we can disable with a policy map TCP State Bypass Feature
Doing this we can tell the ASA not to track the TCP state between hosts we define as an ACL as usual. This probably isnt a feature to be deployed without an understanding of how it may affect other functionality with the ASA.
Define ACL to match traffic to exempt from state tracking:
access-list tcp_state_bypass extended permit tcp 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0 access-list tcp_state_bypass extended permit tcp 192.168.2.0 255.255.255.0 192.168.1.0 255.255.255.0
Define class map that matches on our ACL:
class-map tcp_bypass_class description "Helping with asymmetric flows" match access-list tcp_state_bypass
Define a policy map that does something with our class map:
policy-map tcp_bypass_policy class tcp_bypass_class set connection advanced-options tcp-state-bypass
Finally we apply this to our interfaces to make the policy live:
service-policy tcp_bypass_policy interface IN1 service-policy tcp_bypass_policy interface IN2
Now our traffic can pass through asymmetrically without the ASA dropping it AKA being a router? :) We all secretly know tracking state is a waste of time anyway? :P