TCP RESET-I Connection in ASA 5520

Unanswered Question
Feb 23rd, 2010


there is a problem when a Biztalk server form the outside try to access the inside network through Cisco ASA 5520. It shows to me this Log on the Inside firewall:    6|Feb 23 2010|13:41:05|302014|Biztalk-TEST2|3060|idev4|1526|Teardown TCP connection 3176925 for Outside:Biztalk-TEST2/3060 to inside:idev4/1526 duration 0:00:00 bytes 0 TCP Reset-I

Please guide me in this issue.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.6 (6 ratings)
Panagiotis T Ka... Tue, 02/23/2010 - 14:40

Reset-I means that the host behind the higher security interface sent a RST.

So probably the idev4 sends a reset for some reason and it tears down the connection.

I hope it helps.


Kureli Sankar Tue, 02/23/2010 - 17:12

That syslogs says that the reset packet certainly came from the higher security interface. It could be the host IP listed in the syslog or some other host (ex. websense server or other content scanning devices) that lives behind the higer security interface.

Only way to verify which mac address sent the reset is by capturing on the ASA for the interesting traffic on the inside interface.

You may find that the reset came from the router on the inside in which case you can go one hop down and collect captures to see where the router may have received the reset packet.

If you have access to the host collect wireshark capture on the host itself and see if it sends a reset.

Refer this link to configure cature on the ASA:;jsessionid=A11197443F5D79D04565C4331EFA5806.node0


vignesh8291 Fri, 04/01/2016 - 01:51

Hi guys,

I am really confused about reset-i and reset-o in asa. Please anyone help me out what is exact difference or else share good document to refer.


Aditya Ganjoo Fri, 04/01/2016 - 02:19

Hi Vignesh,

Inbound Reset—Shows the interface reset setting for inbound TCP traffic, Yes or No. Enabling this setting causes the ASA to send TCP resets for all inbound TCP sessions that attempt to transit the ASA and are denied by the ASA based on access lists or AAA settings. Traffic between same security level interfaces is also affected. When this option is not enabled, the ASA silently discards denied packets.

Outbound Reset—Shows the interface reset setting for outbound TCP traffic, Yes or No. Enabling this setting causes the ASA to send TCP resets for all outbound TCP sessions that attempt to transit the ASA and are denied by the ASA based on access lists or AAA settings. Traffic between same security level interfaces is also affected. When this option is not enabled, the ASA silently discards denied packets.

Check this link:



Please rate helpful posts.

Marcel Tempelman Wed, 11/24/2010 - 05:49

Any new info on this ?

Same sort of issue but one added strangeness (or maybe not).

- (Webapplication-)Server in England

- Connection tested from

* Client Site (ASA 5510, 8.3.1)

* Our own site (ASA 5510, 8.2.2)

* a few home connections

- Tested with

* Windows OS

* Mac OS X

* Linux Ubuntu 10.10

Windows + ASA no problem

Mac OS X + ASA TCP Reset-I, lost connection stuck brower, session not usable anymore

Linux + ASA same as Mac OS X

Windows + Mac behind "$10 dollar router" from home location no problem

Haven't tested linux at home yet but don't think it will differ from Mac OS X when used from home.

I see a slight difference between a linux sessions and a windows session:

The windows sessions opens a few ports straight after eachother and and after the data is received I see teardowns and with the linux sessions it seems less "organized" and connections get a teardown when they still are waiting for data.

I was already yelling it was a Windows/ISS conspiracy ;-) but it happens to be an Apache server at the otherside.....

Kureli Sankar Wed, 11/24/2010 - 06:01

Would you pls. spin up a new thread? I hope you are not talking about the same ASA as the original poster and the same syslogs.

Pls. post the following:

- syslogs from the ASA

- ingress and egress captures

From the sound of it - you may have to open a TAC case as it might take a lot of time to review captures.



Marcel Tempelman Wed, 11/24/2010 - 06:57

Thx for the reply.

Ok I'll add another discussion. Want to add one thing:

Linux + Opera seems to be working okay. After googling it seems Firefox and Safari handle TCP Reset differently.

Thx for the reply.

Marcel Tempelman Wed, 11/24/2010 - 12:43

Sorry for adding another post but I had to share this.

This link gave me a trigger:

- Made a Policy on the WAN interface

- matching traffic from the website (added traffic to later)

- under rule actions checked TCP state bypass

Now traffic travels straight to the client. For this traffic the default handling of TCP packets of the ASA is interfering.

It seems all is working ok now but haven't tested it on-site yet but at least it's working without denies and sudden teardowns.

Now I'll shut up :-)

Is there any more information about this problem?

We have the exact same issue, with precisely the same symptoms as mtempelman.

In our case, the web app is a Python app. Running on OS X, connections sometimes get dropped with RESET-I; running on Windows, they do not. When we bypass the ASA or run it from a home network with a cheap-o router, it works.

We are able to work around the problem by applying a policy (as described above), but I would rather fix the root of the problem.

What, exactly, makes the ASA drop the connections? Does it think the traffic looks suspicious? I have enabled all the logging I can think of and do not see anything that tells me why the traffic was dropped, only the RESET-I messages.

[Cisco ASA 5505 8.4(2)8]



s.prakash Tue, 10/30/2012 - 05:05

TCP RESET-I Connection in ASA 5520


There is a problem with asa, when i try to ftp from ASA outside to inside it is given a error  "Teardown TCP connection 3176925 for Outside: to inside: duration 0:00:00 bytes 0 TCP Reset-I". but we are able to mstsc from outside to in side. and we are also apply access-list permit ip any any. But we are not able to ftp from outside to inside.

Julio Carvajal Wed, 05/08/2013 - 22:25


To all of you guys, packet captures and logs never lie,

The best way to troubleshoot this cases is by taking captures on the ASA's interfaces in place on this communication and checking the logs as much as possible,


gaurav kharbanda Mon, 11/18/2013 - 02:30


While connecting to my intranet application through Cisco VPN client, not able to connect. I checked on connection status at VPN client and found that its sending the packet but not recieving. then i checked on my Cisco Firewall 5520 logs and found the given log

14:44:40          302014          10.10.*.*          58762          10.10.*.*          8080          Teardown TCP connection 21142717 for INTERNET:10.10.*.*/58762(LOCAL\username) to SERVER-ZONE:10.10.*.*/8080 duration 0:00:21 bytes 0 TCP Reset-I (Username)

Not able to understand why it is teardown the connection. it is happning with some of the users. Please help me out in this.

jumora Mon, 11/18/2013 - 20:23

First of all, that seems like a proxy server, second, should the server be able to respond to such address, meaning do you have any restrictions on the server, does the server know how to route to the VPN client


This Discussion

Related Content