To accommodate for asymmetric traffic in our network we had to enable TCP state bypass on the ASA Firepower. At the same time we are applying the SFR forwarding policy (configuration below).
Is this a supported setup, and would FirePOWER be able to see the respective traffic?


wka00acw1/pri/act#         sh run class-map
!
class-map alltraffic
 match any

class-map tcp-traffic
 match access-list riverbed_tcp
class-map inspection_default
 match default-inspection-traffic
!
wka00acw1/pri/act# sh run poli
wka00acw1/pri/act# sh run policy-map
!
policy-map type inspect dns preset_dns_map
 parameters
  message-length maximum client auto
  message-length maximum 512
policy-map global_policy
 class inspection_default
  inspect dns preset_dns_map
  inspect ftp
  inspect h323 h225
  inspect h323 ras
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny 
  inspect sunrpc
  inspect xdmcp
  inspect sip 
  inspect netbios
  inspect tftp
  inspect ip-options
 class alltraffic
  set connection advanced-options tcp-state-bypass
  sfr fail-open monitor-only
 class tcp-traffic
  set connection advanced-options allow-probes

When I do "show connections" the TCP connections show with a flag "b" for bypass. There is no "X" flag for "inspect". However ICMP and UDP traffic is flagged with "X" and shows in the FirePOWER logs. Also when TCP state bypass is enabled on all traffic as I showed in the config, all the FirewPOWER dashboards go blank ( i.e. the top applications seen etc). When TCP state checking is enabled everything works properly... I was expecting that symmetric traffic will still get inspected properly with the policy map I've configured but it's not the case.

Yes, with TCP state-bypass the ASA does not forward any of the TCP traffic to FirePOWER even if my policy map applies to all traffic. Even for symmetric "bypassed" traffic. It makes sense to me, I doubt we will use this in PROD as failover is impacted as well - for example if I have 5000 concurrent connections on ASA 1 ( all bypassed) and I failover to the standby ASA 2, all of these are gone. Obviously as there is no real state to maintain and these are just half open or whatever the ASA saw. Speaking with Cisco one work around would be to use the ASA clustering across data centers to avoid asymmetric issues like this. The problem is we do not have OTV or Layer 2 between DC's but that is another topic.

Thanks for pointing that out. It came up in our discussions with Cisco. Not sure if management will be willing to swallow the monthly cost for 2 x 10Gig dark fiber circuits or associated OTV routers (currently our DCI link is Layer 3, may be a hard sell unless we can get separate layer 2 just for this cluster). Do you know if QinQ tunneling is supported in the ASA cluster?

thank you