Packet RESET don't pass through ASA

[javi_cesp]

Hi everybody,

I'm having a weird behavior in a connection. My connection is TCP originating from inside to outside. A few times from outside there are Reset packet coming (for this connection originated from inside) that don´t pass through the ASA generating disconnection. This behavior is not for the whole Reset Packet because a few are coming through.

I can't detect why the ASA drop this packets. I'm trying to make a correlation between the packet that dont pass the firewalls and the ASP table from the ASA (sh asp drop). But I can detect why the ASA do this.

Somebody know how can I detect the cause of this?

Best regards.

Javier

[Jouni Forss]

Hi,

In such a case I would imagine that the way to go would be to take a traffic capture and make it as specific as you can. Usually its enough to capture all TCP/UDP traffic between 2 host IP addresses.

You can capture traffic both on the ingress and egress interfaces if you want but naturally you will have to take into account the NAT.

It would help to see ALL the logs related to a connection and what you are seeing.

Only thing similiar to what you are saying has been for me a situation where host/server first teardown a TCP connection normally with TCP FIN and then there is also a TCP Reset on the connection even though the connection has already been normal closed with TCP FIN.

I would imagine that the ASA would handle this TCP Reset coming after the connection has been already closed like any other packet that might arrive and is not a SYN or part of a connection in the ASAs connection/state table. It would block it with a Syslog message that contains something like "Deny TCP (no connection)....."

The syslog ID in that case would probably be "106015"

What kind of TCP connection are we talking about? What is the actual application that uses the TCP connection?

If you want to try configuring the capture (which is really easy) you can use the below format with your information applied.

access-list INSIDE-CAP permit ip host host

access-list INSIDE-CAP permit ip host host

capture INSIDE-CAP type raw-data access-list INSIDE-CAP interface inside buffer 33500000 circular-buffer

Then you can use the below command to view if anything traffic is yet captured

show capture

You can view the capture on the CLI with the below command

show capture INSIDE-CAP

You can copy the capture to your local computer/server with TFTP with the following command

copy /pcap capture:INSIDE-CAP tftp:///INSIDE-CAP.pcap

If/when you want to remove the capture from the firewall you can use the command

no capture INSIDE-CAP

You will have to remove the actual ACL separately.

Hope this helps

- Jouni

[javi_cesp]

Hi Jouni

First at all thank for your response.

This connection is originated by a server from the inside to a PC on the outside. Because the ASA don't send this TCP reset (of the client from the outside) to the server located in the inside the socket tcp on the server is maintained until the tcp time expiration for this connection expired (half open connection). After that a  new connection is started on the server from the inside to the pc on the outside putting online again the app in the PC. So meantime the application is down till this new connections is started again.

I did the capture for both interface and I couldn't detect why the ASA drop these packets. The ASA is up from 256 days. None new configuration have been done that could cause this behavior. I'm thinking to reboot the ASA but i dont know if this will solve my problem.

Any other idea?

Best regards.

[Jouni Forss]

Hi,

Is it normal for this connection that the "outside" PC would send a TCP Reset? Or why would it reset the TCP connection?

Should the connection normally be closed by the user/client (inside PC) with TCP FIN?

Are you collecting logs from the ASA the moment? If not, I would suggest collecting logs and after this kind of situation checking the logs.

The most typical reason I see ASA dropping packets is naturally the ACL rules and theres also situations where the connections has already been closed when any more packets arriving for these connections will be dropped.

I am not sure what we could do with the ASA to correct this situation. Lately I have had to mainly configure different idle timeouts for TCP connections for some applications used in certain environments.

Theres also possibility to configure the ASA to send TCP Keepalives for a connection and if either of the endpoints doesnt reply to the TCP Keepalive, the connection is removed from the ASA. It doesnt read anywhere that this would trigger anykind of TCP Reset from the ASA itself (which would help in your situation probably) so it leads me to believe that this wouldnt really help you either

I guess you could try an ASP capture on the firewall or did you already?

capture ASP-CAP type asp-drop all

- Jouni

[Fahad Wasi]

Hello Sir,

I was reading this discussion and wanted to ask some questions, what is a packet reset?

Does packet reset means that an IP packet which is transmitted from inside network(Local Network) to internet(Outside Network), is dropped and then new IP packet is sent from the source device within a Local Network to Internet(Outside Network)?

Thanks