This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

receiving FIN,ACK late

0

We are having a problem with our network traffic where our firewall is dropping a huge number of packets suddenly (our ISP changed network equipment at the same time as us, by an unfortunate coincidence).

We're trying to isolate the problem: We did an experiment where we made a request from within the firewall with Wireshark running on one machine, and outside the firewall with Wireshark running and tried to find exactly what packet was being rejected.

We seem to have reconstructed this chain of events - internal machine initiates communication with server on the Internet. The two servers communicate, conversation complete, everything is allowed via inbound->outbound firewall policy. After the end of the conversation, the Internet server sends one more packet (a FIN,ACK) and the firewall rejects this as part of the outbound->inbound firewall policy (since it doesn't recognize the connection any longer as an inbound->outbound)

My question is, am I misinterpreting these results? Is it normal for a FIN,ACK to be a response to a RST,ACK? Attached is a packet capture isolated to the specific exchange.

No. Time Source New Column Destination New Column Protocol Length Info New Column 1 0.000000 209.251.44.179 25452 74.125.228.74 443 TCP 66 25452 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1380 WS=256 SACK_PERM=1 1 2 0.006201 74.125.228.74 443 209.251.44.179 25452 TCP 66 https > 25452 [SYN, ACK] Seq=0 Ack=1 Win=42900 Len=0 MSS=1430 SACK_PERM=1 WS=64 2 3 0.007895 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [ACK] Seq=1 Ack=1 Win=66048 Len=0 3 4 0.010897 209.251.44.179 25452 74.125.228.74 443 TLSv1.2 278 Client Hello 4 5 0.016407 74.125.228.74 443 209.251.44.179 25452 TCP 60 https > 25452 [ACK] Seq=1 Ack=225 Win=42880 Len=0 5 6 0.017638 74.125.228.74 443 209.251.44.179 25452 TLSv1.2 1434 Server Hello 6 7 0.017815 74.125.228.74 443 209.251.44.179 25452 TCP 1434 [TCP segment of a reassembled PDU] 7 8 0.017836 74.125.228.74 443 209.251.44.179 25452 TLSv1.2 872 Certificate 8 9 0.021839 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [ACK] Seq=225 Ack=2761 Win=66048 Len=0 9 10 0.030446 209.251.44.179 25452 74.125.228.74 443 TLSv1.2 316 Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request 10 11 0.038621 74.125.228.74 443 209.251.44.179 25452 TLSv1.2 348 New Session Ticket, Change Cipher Spec, Hello Request, Hello Request 11 12 0.038840 74.125.228.74 443 209.251.44.179 25452 TLSv1.2 111 Application Data 12 13 0.038849 74.125.228.74 443 209.251.44.179 25452 TLSv1.2 99 Application Data 13 14 0.127251 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [ACK] Seq=487 Ack=3930 Win=65024 Len=0 14 15 0.320594 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [ACK] Seq=487 Ack=3975 Win=65024 Len=0 15 16 7.905897 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [FIN, ACK] Seq=487 Ack=3975 Win=65024 Len=0 16 17 7.905903 209.251.44.179 25452 74.125.228.74 443 TCP 60 25452 > https [RST, ACK] Seq=488 Ack=3975 Win=0 Len=0 17 18 7.910928 74.125.228.74 443 209.251.44.179 25452 TCP 60 https > 25452 [FIN, ACK] Seq=3975 Ack=488 Win=42880 Len=0 18

asked 30 Apr '14, 10:30

amallah's gravatar image

amallah
11112
accept rate: 0%


One Answer:

1

A reset flag must not be answered, which is a rule in place to prevent two systems telling each other to "shut up" over and over again. So no, it would be illegal to send a FIN as an answer to a reset, but I doubt that is what is happening. I guess the FIN is the answer to the other FIN, and it's just coming in late due to the RTT. You can usually verify this on the side that sends the final FIN - it will most likely not yet have seen the RST when it sent it. It's a little hard to tell without having a real trace and just looking at an ASCII dump.

answered 30 Apr '14, 10:54

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

Thanks for your reply. Does this help? https://webbmason.sharefile.com/d/s9ba2db79c1c499ca

(30 Apr '14, 11:06) amallah

The inside_capture.pcapng shows it: the RST in frame 17 is sent 65 microseconds after the FIN is sent in frame 16, which is really really impatient.

I can only guess that the application closed the TCP socket without waiting for the graceful shutdown being complete (meaning, waiting for a FIN answering the FIN being sent), and so a RST is sent.

The FIN from the other node arrives shortly after in frame 18 as seen in outside_capture.pcap, probably before the sender knew there was a RST coming in soon after.

For me the interesting thing is why the IP 192.168.193.215 sends a FIN and then a RST right away - I would investigate this further, but that has to be done on the OS and application side of that station.

(30 Apr '14, 11:29) Jasper ♦♦