In my company we have a software system used to transmit thousands of files of different sizes through a WAN. Senders and receivers are in different countries or even continents, and most of the connections are established through static VPN tunnels.

The system works fine, but almost every day at some point we experience periods (from minutes to hours) in which many connections are dropped. This software can close the connections if they're idle for 3 minutes, and when this happens the action is properly logged and easily identifiable. However, in most of the cases what we see in the logs of both sides isn't a connection closed due to timeout, but that 'a connection was forcibly closed by the remote host'.. So my conclusion is that it is a network device in the middle that is actively sending a RST to both endpoints.

My question is, is this possible?. I understand that a router can drop packets but I've been told that it cannot initiate a connection closure. Is this true? If so, any idea of why the TCP stack indicates, in both sides, that it was the other side who closed the connection?

Thanks a lot!

  • 1
    Your best bet would be to sniff packets at both ends and see what the capture says. In response to your question, routers with firewall capabilities and firewalls themselves can send FIN and RST packets if they've been configured to do so.
    – OzNetNerd
    May 27, 2016 at 7:02
  • @OzNetNerd Thanks, then indeed it's possible that connections are dropped by routers or firewalls. I thought about installing wireshark but I need to restart the server, so I need sometime to plan for it.
    – Haplo
    May 27, 2016 at 7:35
  • 1
    Microsoft Message Analyzer does quite the same as WireShark but doesn't require a reboot. (at least on Windows server 2008 R2).
    – JFL
    May 27, 2016 at 7:42
  • Router with IOS software firewall could do this May 28, 2016 at 8:28
  • 1
    @Haplo depending on what network gear you have, you should be able to SPAN/port mirror the ports to a separate box that has Wireshark installed on it. Doing this will mean you can avoid rebooting your server.
    – OzNetNerd
    May 29, 2016 at 23:53

2 Answers 2


I've seen firewalls exhibit this exact behaviour in the wild when troubleshooting issues, spoofing RST packets. When running a capture on one end of the connection the RST will appear to be originating from the remote host - try the capture on the remote host and the RST will appear to come from the other end.

So to answer your question, network devices which are "TCP aware" can absolutely cause this situation.


I have seen such situation when TCP connections were going through the network load balancer on witch TCP session idle timeout was set too small.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.