Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

TCP RESET-I Connection in ASA 5520

HI,

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.

  • Firewalling
Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
New Member

TCP RESET-I Connection in ASA 5520

Hi,

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.

14 REPLIES
Cisco Employee

Re: TCP RESET-I Connection in ASA 5520

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.

PK

Cisco Employee

Re: TCP RESET-I Connection in ASA 5520

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:

https://supportforums.cisco.com/docs/DOC-1222;jsessionid=A11197443F5D79D04565C4331EFA5806.node0

-KS

New Member

Hi guys,

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.

Thanks 

Cisco Employee

Hi Vignesh,

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:

http://www.cisco.com/c/en/us/td/docs/security/asa/asa84/asdm64/configuration_guide/asdm_64_config/protect_tools.html

Regards,

Aditya

Please rate helpful posts.

New Member

Re: TCP RESET-I Connection in ASA 5520

Gentlemen thank you for the reply

New Member

Re: TCP RESET-I Connection in ASA 5520

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.....

Cisco Employee

Re: TCP RESET-I Connection in ASA 5520

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.

Thanks,

KS

New Member

Re: TCP RESET-I Connection in ASA 5520

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.

New Member

Re: TCP RESET-I Connection in ASA 5520

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

This link gave me a trigger:

http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/conns_tcpnorm.html

- 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 :-)

87758
Views
28
Helpful
14
Replies
This widget could not be displayed.