Teardown TCP connection - Flow closed by inspection

[Luigi Celeste]

Good Morning.

I've a great problem with my new ASA 5515-X Configured in Active/Standby Failover.

This is a company that have 8 remote branches connected via VPN Site-to-Site with our ASAs on the main site. All the remote branches have one or two ASA (configured in Failover Active/Standby too in this case). Normal VPN traffic works fine and also the Internet connections. Problems arrive when an host starts to upload (or download) a medium sized file toward an branch office via SMB protocol, or when some database start to upload other databases in the central office. at random, the connection between hosts reset and the download/upload it stop without finish.

Debugging the ASA I saw that this message is producted:

2015-04-08 14:09:31    Local4.Info    131.1.55.55    :Apr 08 14:09:37 CEST: %ASA-session-6-302014: Teardown TCP connection 28477562 for outside:192.168.13.245/445 to inside:131.1.60.60/6962 duration 0:57:02 bytes 2206518128 Flow closed by inspection

This is the default inspection configured on ASA, and there's not others inspection.

!
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 ip-options
  inspect netbios
  inspect rsh
  inspect rtsp
  inspect skinny  
  inspect esmtp
  inspect sqlnet
  inspect sunrpc
  inspect tftp
  inspect sip  
  inspect xdmcp
  inspect waas
  inspect icmp

I really don't know how to fix this great problem.

[Andre Neethling]

Good day. For testing purposes, Can you try to remove NetBIOS from your inspection policy map?

[Luigi Celeste]

Thank's for reply!

Sure, i could, but which do you think is the behavior that causes this error leaving enabled NetBios inspection?

Also, this ASA is replacing an Old ASA 5510 (ASA Version 7.0(8) ) that in its configuration had enabled the default NetBios inspection too and everything works without problems like now.

Now I followed also the advice of enable the commands:

Sysopt connection preserve-vpn-flows

Sysopt connection reclassify-vpn

(https://supportforums.cisco.com/discussion/11860166/asa5585-ssp-20-912-flow-closed-inspection)

But in the same way I continue to have problems when downloding or uploading large files toward VPN site-to-site connections. Really don't know how to solve this problem.

I appreciate really your interest. Thank's for what you can do to solve this problem!

[Pranay Prasoon]

There is nothing like SMB inspection on ASA.

I just have  a gut feeling it is ICMP denial of service on ASA. Can you please tell your ASA software version?

https://tools.cisco.com/bugsearch/bug/CSCui77398/?reffering_site=dumpcr

[Luigi Celeste]

Thank's for the reply first!

The ASA Version is 9.1(2)

But reading the bug features, my ASA does not reload itself, but only Teardown the connection who downloading/uploading a large file, or attempting to do download/upload from a few minutes.

[Pranay Prasoon]

this version is affected by the DOS. As a TAC engineer I don't see device reloading 99% time. The condition says it "may" reload.

Please upgrade to 9.1.3 or 9.1.5 and see if it fixes the issue.

[Luigi Celeste]

I have the possibility to upgrade my ASA at the Version 9.2(2), I can download the OS from an ASA of a remote branch. Do you think this may fix my problems?

[Pranay Prasoon · Accepted solution]

Yes 9.2.2 is clean. Please upgrade and let me know the result.

[Luigi Celeste]

Great news! Tomorrow will be the first thing I'll do at work. After some testing I'll let you know immediately! Hope it will works!

Thank's for now!

Luigi Celeste

[Luigi Celeste]

Hi Pranay Prasoon,

2 days ago i've upgraded my ASA Version to the 9.2(2) in Italy and then I start a lot of testing downloading and uploading some giga of files from and to the ours remote sites. Well, I can definitely say that everything went OK!!! files are correctly transferred, VPN connection from sites never tear down!

Also, there was the problem that when VPN connections were tearing down for some seconds (5-6 seconds in average), also IPSLA (that is configured with a primary provider and a backup provider) immediately trigger and for 5-6 seconds uses the second provider, after which to come back to use the first provider. Also this correlated problem seems disappeared.

Monday I've to reconnect yet also the secondary ASA as Standby failover (because I didn't have changed yet the OS version in waiting for testing), and see if failover trigger itself for no apparent reason (that was another anomaly that occurred). When all it's tested for at least one week I can definitely say that the problem is totally solved, but in principle it's already!

Then I would to really thank you for this great support that seems to have solved a lot of network problem related to this bug!!!

Best Regards,

Luigi Celeste