Lab Minutes Forum
Technical Discussion => Security => Topic started by: gvoden on March 24, 2016, 11:42:29 AM
-
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
-
Firepower needs to see bidirectional traffic for it to work properly. Not sure what would happen if it only see one half, traffic may or may not be blocked as expected. Even though certain feature may work but you can probably expected odd behaviors.
-
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.
-
Are you saying that even when you have bidirectional traffic passing through the same ASA, but with state-bypass enabled for all TCP, FP fails to see the traffic, in the connection log etc. If so, may be the ASA might not even redirect traffic to FP for those that are state-bypassed.
For ICMP and UDP, the behavior you saw is expected since they are connectionless. Even though they show up on the log, I doubt certain features may not work, AVC for example that requires FP to see bidirectional traffic.
-
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.
-
If you decide to cluster ASA across the DC, keep in mind that all of your asymmetric traffic will be forwarded across the DC interconnect link used for ASA cluster link. You need to make sure the link capacity and quality meet what Cisco recommend otherwise performance might be jeopardized.
-
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
-
As far as I know, ASA cluster links have very stringent requirements, BW, latency etc. You might able to get them to communicate whether with L2VPN or DC interconnect technology but who knows how reliable it will be. It will also depend on geographic separation of your two datacenter (ie. same side vs cross country. Whatever you come up with, it is certainly best to get Cisco blessing.