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.
asked 30 Apr '14, 10:30  amallah |
One Answer:
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 ♦♦ |
Thanks for your reply. Does this help? https://webbmason.sharefile.com/d/s9ba2db79c1c499ca
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.