is my TCP bypass working?

[tato386]

I have two private networks behind an ASA5505 that need to access the Internet and also talk to each other. Each private network hosts a couple servers with NATed/published services.  Since the ASA is not exactly the best device to use to route traffic between the two private networks, I wanted to do all I could to make sure I get the best possible performance.  I setup TCP bypass in the ASA service policy as shown in the config snippet at bottom.  The idea was to make sure private-to-private traffic is not slowed down by ASA inspection.

I thought it was working until something happend that makes me doubt my setup. A user on the 10 network had me NAT his machine so he can publish a streaming media server to the Internet.  When I did this he complained about terrible performance when streaming media to the Internet. Since this is a custom service and I wasn't too sure of the ports and protocol being used I just changed the tcp_bypass ACL to this:

!
access-list acl_TCPbypass extended permit ip object net_priv10 any log disable
access-list acl_TCPbypass extended permit ip object net_priv172 object net_priv172 log disable
access-list acl_TCPbypass extended permit ip object net_priv10 any log disable
access-list acl_TCPbypass extended permit ip object net_priv172 object net_priv10 log disable
!

The idea was to quickly try to rule out the ASA inspecting the traffic.  I figured this would have the effect of not scanning traffic sourced from the 10 network no matter where it was going.  This change had no effect at all.  Next I removed RTSP inspection from the global policy and the user confirmed all was well.

So it seems like the ACL change was not enough to bypass RTSP scanning.  Does that mean that other private-to-private is also being inspected?  How can I further test whether my TCP bypass is working?

Thanks,
Diego

!
access-list acl_TCPbypass extended permit ip object net_priv10 object net_priv10 log disable
access-list acl_TCPbypass extended permit ip object net_priv172 object net_priv172 log disable
access-list acl_TCPbypass extended permit ip object net_priv10 object net_priv172 log disable
access-list acl_TCPbypass extended permit ip object net_priv172 object net_priv10 log disable
!
!
class-map inspection_default
match default-inspection-traffic
!
class-map tcp_bypass
description TCP traffic that bypasses stateful firewall
match access-list acl_TCPbypass
!
!
policy-map type inspect dns preset_dns_map
parameters
  message-length maximum 512
!
policy-map pmap-inf_priv10
class tcp_bypass
  set connection random-sequence-number disable
  set connection advanced-options tcp-state-bypass
!
policy-map pmap-inf_priv172
class tcp_bypass
  set connection random-sequence-number disable
  set connection advanced-options tcp-state-bypass
!
policy-map global_policy
description global-class
class inspection_default
  inspect dns preset_dns_map
  inspect rsh
  inspect rtsp
  inspect esmtp
  inspect sqlnet
  inspect skinny
  inspect sunrpc
  inspect xdmcp
  inspect sip
  inspect tftp
  inspect ip-options
  inspect ftp strict
!
service-policy global_policy global
service-policy pmap-inf_priv10 interface inf_priv10
service-policy pmap-inf_priv172 interface inf_priv172

[Jouni Forss · Accepted solution]

Hi,

Generally I have not seen any need to configure TCP State Bypass between local networks at all. Usually its used if you have asymmetric routing in the network. Most typical situation I have seen this happen is when users have an ASA connected to a LAN network directly and there is also a router on the LAN network through which another network is reached. This causes problems for the ASA as it can't see the whole discussion between the hosts. Atleast in the situation where the ASA is set as the default gateway for the hosts.

You should be able to confirm if TCP State Bypass is applied to the connections by looking at the connection table. These connections will have their own Flag at the end of the connection.

You can check the Flag by using the command

show conn detail

Flags: A - awaiting inside ACK to SYN, a - awaiting outside ACK to SYN,

       B - initial SYN from outside, b - TCP state-bypass or nailed, C - CTIQBE media,

       D - DNS, d - dump, E - outside back connection, F - outside FIN, f - inside FIN,

       G - group, g - MGCP, H - H.323, h - H.225.0, I - inbound data,

       i - incomplete, J - GTP, j - GTP data, K - GTP t3-response

       k - Skinny media, M - SMTP data, m - SIP media, n - GUP

       O - outbound data, P - inside back connection, p - Phone-proxy TFTP connection,

       q - SQL*Net data, R - outside acknowledged FIN,

       R - UDP SUNRPC, r - inside acknowledged FIN, S - awaiting inside SYN,

       s - awaiting outside SYN, T - SIP, t - SIP transient, U - up,

       V - VPN orphan, W - WAAS,

       X - inspected by service module

The above mentioned Flag "b" should be the only Flag for these TCP connections.

The Command Reference for ASA states that Application Inspection would be unsupported if TCP State Bypass is used but the example in the document seems to me to refer to a situation where traffic is flowing asymmetrically through 2 different ASAs but in your situation the single ASA sees the whole connection (inbound and outbound traffic) so I am wondering if Application Inspection is still supported.

I am not really sure still if you really need to configure TCP State Bypass at all or if it provides any real benefit.

The couple of times that I have configured this for testing purposes here in CSC I think I have usually configured under the globally attached "policy-map" configuration and have not attached it to a specific interface.

- Jouni

[tato386]

Jouni:

Using the "show conn detail" command as you suggested shows my private-to-private connects with flag "b" which would indicate that TCP state bypass is working as I want it to.  I have to image that it should speed things up a bit since this traffic incurs minimal processing.

Also interesting would be to include all policies in the global servcice policy rather than interface specific policies.  If I were to try this, how would I prioritize the class maps inside the global policy to assure that private traffic is TCP bypassed before it matches the insepction rules?

Thanks,

Diego